fetchmail-users — User questions and discussion

Re: [Fetchmail-users] Some news on OAuth2?!

[Matthias A. <mat...@gm...>]

Am 01.11.23 um 23:27 schrieb Marco Gaiarin:
> Seems that Google have defined the total phase out:
>
> 	https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html
>
> seems that 'app password' still will be supported:
>
> 	https://knowledge.workspace.google.com/kb/how-to-generate-an-app-passwords-000009237?hl=en

Yeah, so use that.

> but... some news on OAuth2 support? Thanks.
>
You tell Me...

did any of the few big OAuth2 lobbyists who used to keep misleading the
world about the need
have changed their minds or their policies? If not, it's hopeless to
have something supportable anyways.

[Fetchmail-users] Some news on OAuth2?!

[Marco G. <ga...@li...>]

Seems that Google have defined the total phase out:

	https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html

seems that 'app password' still will be supported:

	https://knowledge.workspace.google.com/kb/how-to-generate-an-app-passwords-000009237?hl=en


but... some news on OAuth2 support? Thanks.

-- 
  Worrying about case in a Windows (AD) context is one of the quickest paths to
  insanity.							(Patrick Goetz)

Re: [Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

> 
> It's not in fetchmail proper yet. I am open to doing it some day, but
> that requires several other items to be done first, better tracking of
> downloaded message for IMAP, different alternative format of .fetchids,
> and similar.

Ok - if I "keep" mails on the server then I get two deliveries, one without the attachment and then later one with the attachment.

Unfortunately the first one may or may not come with a message about the ATP hold up.

-> If I get the ATP message I get no attachment in the first email and I can intercept with procmail and make this initial email go away

-> If I do not get the ATP message in the first email I get a 0 byte length attachment in the first email (correct attachment in the second email) but I haven't found a way to remove this irritation by procmail.  Any suggestions for detecting this (with a procmail recipe) gratefully received.

I still do not have a convenient way from removing all the stored emails from the server - any suggestions gratefully received.

Re: [Fetchmail-users] Behaviour if smtphost not available?

[Matthias A. <mat...@gm...>]

Am 03.08.23 um 10:06 schrieb ns...@gm...:
> Hello,
>
> what ist the behaviour of Fetchmail if it retrieved mails via IMAP from a server but cannot forward them to the configured smtphost because it is temporarly not available? Will all the mails be buffered on the Fetchmail machine and delivered as soon as the machine comes available again?

No. Fetchmail will re-download the messages until the SMTP host is
available.

Re: [Fetchmail-users] smtphost - separate MTA required?

[Matthias A. <mat...@gm...>]

Am 01.08.23 um 13:11 schrieb ns...@gm...:
> Hello,
>
> does Fetchmail need to have an MTA (e.g. Postfix) installed on the system to be able to forward received mails (parameter "smtphost" in the configuration) to an SMTP server on another host?
>
> If "yes" what will be the minimal required configuration of the MTA?
>
Yes - the minimal required configuration to listen and accept mail
locally, and forward to the other host. Depends on your chosen software.

[Fetchmail-users] Behaviour if smtphost not available?

[<ns...@gm...>]

Hello,

what ist the behaviour of Fetchmail if it retrieved mails via IMAP from a server but cannot forward them to the configured smtphost because it is temporarly not available? Will all the mails be buffered on the Fetchmail machine and delivered as soon as the machine comes available again?

Thanks.

[Fetchmail-users] smtphost - separate MTA required?

[<ns...@gm...>]

Hello,

does Fetchmail need to have an MTA (e.g. Postfix) installed on the system to be able to forward received mails (parameter "smtphost" in the configuration) to an SMTP server on another host?

If "yes" what will be the minimal required configuration of the MTA?

Thanks.

Re: [Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

On Sunday, 30 July 2023 23:47:11 BST Matthias Andree wrote:
> It's not in fetchmail proper yet. I am open to doing it some day, but
> that requires several other items to be done first, better tracking of
> downloaded message for IMAP, different alternative format of .fetchids,
> and similar.
> 

Would another possibility would be to use -keep routinely and then occasionally (say once a week) omit the --keep and let this delete the messages? I've not check the behaviour but I'd worry this wouldn't delete previously read messages.

Re: [Fetchmail-users] ATP dynamic delivery

[Matthias A. <mat...@gm...>]

Am 29.07.23 um 13:35 schrieb sup...@gm...:
> You can just see how this happened and how the language of it ("advanced threat protection" "dynamic delivery" and complicated diagrams, multiple servers, cloud based previews, a liberal smattering of technical BS) is designed to leveraging $2/month per user out of IT middle managers for a faux product which simply involves turning virus scanning into theatre. The cost for large organisation runs to $millions per year for these theatrics. The upshot for me is that turning it off (on the grounds that it doesn't work and is simply fluff) doesn't look likely because someone will have to admit they were beguiled by this nonsense. Also the idea that the email gets through instantly is also illusory - a little benchmarking shows that handling all this (scanning, stripping, previews etc) is not much faster than scanning the payload anyway.
>
> Anyway - I will try to find a practical fix - if there is a simple way to do a timed "keep" can someone let me know?

It's not in fetchmail proper yet. I am open to doing it some day, but
that requires several other items to be done first, better tracking of
downloaded message for IMAP, different alternative format of .fetchids,
and similar.

Re: [Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

You can just see how this happened and how the language of it ("advanced threat protection" "dynamic delivery" and complicated diagrams, multiple servers, cloud based previews, a liberal smattering of technical BS) is designed to leveraging $2/month per user out of IT middle managers for a faux product which simply involves turning virus scanning into theatre. The cost for large organisation runs to $millions per year for these theatrics. The upshot for me is that turning it off (on the grounds that it doesn't work and is simply fluff) doesn't look likely because someone will have to admit they were beguiled by this nonsense. Also the idea that the email gets through instantly is also illusory - a little benchmarking shows that handling all this (scanning, stripping, previews etc) is not much faster than scanning the payload anyway. 

Anyway - I will try to find a practical fix - if there is a simple way to do a timed "keep" can someone let me know?





On Saturday, 29 July 2023 10:11:34 BST Matthias Andree wrote:
> Am 29.07.23 um 10:30 schrieb sup...@gm...:
> > It is very poorly documented - it also seems a daft amount of work to make something that should be hidden from the end user visible. I cannot see any tangible benefit other than,  "useless gimic marketing bollocks".
> >
> > I will try the --keep option and observe what I get - it occurs to me that one option work simply be to "keep" for a limited time period and delete older messages.  Based on observations of the propagation delay, keeping for 1 hour would probably save 99% of attachments. However, I understand that some part of the triage of these attachments can involve a human in the loop for a small number of attachments so maybe simply keeping for 24 hours would restore full functionality without requiring maintenance.
> >
> > I think that handling the dummy email (and possible duplicates) is easily done downstream (eg I can filter the dummy email out so I never see it).
>   I was thinking more along the lines "if we can match the headers
> against a regular expression to just skip the message..."
> > Changing the server delivery policy to "replace" instead of "dynamic" appears to be the ideal solution but someone somewhere has gotten very excited by this so I'm not holding my breath.
> 
> You might think that the tenant paying Microsoft services were in
> control of that switch.
> Of course if they pay money to get rid of their own thinking, poking the
> too-lazy-to-think payer is vain endeavour. Hope I am not stepping on
> anyone's toes here, but then again such entities are usually robust
> enough to not care about outsider's opinions...
>    I understand that in larger organizations the bodies passing such
> outsourcing decisions are not necessary aware or interested in what
> individuals think and are more in a "we have the broader view and know
> better what is best" attitude. Then you are trapped between the
> proverbial rock and the hard place.
> 
> I am wondering why people would believe e-mail was real-time
> communication to make this necessary. Spam killed the real-time aspect
> decades ago, and if they take an hour to scan anything else but a zip
> bomb, something's wrong with the scanner.
> 
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 

Re: [Fetchmail-users] ATP dynamic delivery

[Matthias A. <mat...@gm...>]

Am 29.07.23 um 10:30 schrieb sup...@gm...:
> It is very poorly documented - it also seems a daft amount of work to make something that should be hidden from the end user visible. I cannot see any tangible benefit other than,  "useless gimic marketing bollocks".
>
> I will try the --keep option and observe what I get - it occurs to me that one option work simply be to "keep" for a limited time period and delete older messages.  Based on observations of the propagation delay, keeping for 1 hour would probably save 99% of attachments. However, I understand that some part of the triage of these attachments can involve a human in the loop for a small number of attachments so maybe simply keeping for 24 hours would restore full functionality without requiring maintenance.
>
> I think that handling the dummy email (and possible duplicates) is easily done downstream (eg I can filter the dummy email out so I never see it).
  I was thinking more along the lines "if we can match the headers
against a regular expression to just skip the message..."
> Changing the server delivery policy to "replace" instead of "dynamic" appears to be the ideal solution but someone somewhere has gotten very excited by this so I'm not holding my breath.

You might think that the tenant paying Microsoft services were in
control of that switch.
Of course if they pay money to get rid of their own thinking, poking the
too-lazy-to-think payer is vain endeavour. Hope I am not stepping on
anyone's toes here, but then again such entities are usually robust
enough to not care about outsider's opinions...
   I understand that in larger organizations the bodies passing such
outsourcing decisions are not necessary aware or interested in what
individuals think and are more in a "we have the broader view and know
better what is best" attitude. Then you are trapped between the
proverbial rock and the hard place.

I am wondering why people would believe e-mail was real-time
communication to make this necessary. Spam killed the real-time aspect
decades ago, and if they take an hour to scan anything else but a zip
bomb, something's wrong with the scanner.

Re: [Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

It is very poorly documented - it also seems a daft amount of work to make something that should be hidden from the end user visible. I cannot see any tangible benefit other than,  "useless gimic marketing bollocks".

I will try the --keep option and observe what I get - it occurs to me that one option work simply be to "keep" for a limited time period and delete older messages.  Based on observations of the propagation delay, keeping for 1 hour would probably save 99% of attachments. However, I understand that some part of the triage of these attachments can involve a human in the loop for a small number of attachments so maybe simply keeping for 24 hours would restore full functionality without requiring maintenance.

I think that handling the dummy email (and possible duplicates) is easily done downstream (eg I can filter the dummy email out so I never see it).

Changing the server delivery policy to "replace" instead of "dynamic" appears to be the ideal solution but someone somewhere has gotten very excited by this so I'm not holding my breath.





On Saturday, 29 July 2023 07:21:11 BST Matthias Andree wrote:
> Am 29.07.23 um 00:31 schrieb sup...@gm...:
> > ATP dynamic delivery is a MS exchange concept whereby emails are delivered without attachments but preview links instead.
> >
> > The attachments are scanned off line and then the original email is sucked back and replaced by a new version of the email with the attachment - this can take quite a while.
> >
> > If fetchmail gets the email before this process occurs the suck back and replacement with the attachment never happens, the "preview" link goes dead and the attachment never arrives.
> >
> > It is definitely a server side issue but I can't change the server side behaviour (if you can change the server side settings then simple fix is to change the "dynamic" delivery policy with "replace" delivery policy which behaves like any normal system where the email is delivered after it is scanned).
> >
> > This is not the only problem with ATP but it seems to be the biggest source of loss of attachments.
> >
> > A possible tactic would be to exclude the fetching of emails containing these preview links and defer their download until the suck back and replacement process has happened.
> 
> I have found very little documentation on this, only that people
> complain that they need to close and re-open their email client window,
> and that apparently the messages are being replaced. I have not seen any
> information how I could identify "attachments being scanned" and "full
> e-mail now available" through the IMAP or POP3 interface?
> 
> The sound way to do that would be for the server to *DELETE* the preview
> message and *ADD* the full message at the end of the mailbox as though
> it were new.
> 
> If instead they were changing an e-mail we have already downloaded, in
> place, without changing the message's UID, we will never know.
> 
> So, first try you could do is running fetchmail with --keep (as in do
> not delete), unless you are already doing that, and see if you get such
> messages twice, once as preview, once as full message. If that works,
> fine, you know the workaround and we may be able to file down some rough
> edges and possibly add a generic-enough header matcher that skips a
> message when that header is present.
> 
> Note this would be prone to abuse if they don't strip that header from
> incoming messages with all the attachments in place (after scan) because
> I could then just put that header and prevent your message download...
> 
> If that does not help and they are replacing messages in place, I need
> to know the specification - would they put up a special header to mark
> that the message is only a preview that is reliable enough to "skip" a
> message? Is there reliable technical documentation? Note: I am not going
> to research this beyond my search engine probes this morning, someone
> will have to hand me the silver plate with all information. And after
> looking through a spec, I may conclude it's too unreliable to be worth
> investing more time.
> 
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 

Re: [Fetchmail-users] ATP dynamic delivery

[Matthias A. <mat...@gm...>]

Am 29.07.23 um 00:31 schrieb sup...@gm...:
> ATP dynamic delivery is a MS exchange concept whereby emails are delivered without attachments but preview links instead.
>
> The attachments are scanned off line and then the original email is sucked back and replaced by a new version of the email with the attachment - this can take quite a while.
>
> If fetchmail gets the email before this process occurs the suck back and replacement with the attachment never happens, the "preview" link goes dead and the attachment never arrives.
>
> It is definitely a server side issue but I can't change the server side behaviour (if you can change the server side settings then simple fix is to change the "dynamic" delivery policy with "replace" delivery policy which behaves like any normal system where the email is delivered after it is scanned).
>
> This is not the only problem with ATP but it seems to be the biggest source of loss of attachments.
>
> A possible tactic would be to exclude the fetching of emails containing these preview links and defer their download until the suck back and replacement process has happened.

I have found very little documentation on this, only that people
complain that they need to close and re-open their email client window,
and that apparently the messages are being replaced. I have not seen any
information how I could identify "attachments being scanned" and "full
e-mail now available" through the IMAP or POP3 interface?

The sound way to do that would be for the server to *DELETE* the preview
message and *ADD* the full message at the end of the mailbox as though
it were new.

If instead they were changing an e-mail we have already downloaded, in
place, without changing the message's UID, we will never know.

So, first try you could do is running fetchmail with --keep (as in do
not delete), unless you are already doing that, and see if you get such
messages twice, once as preview, once as full message. If that works,
fine, you know the workaround and we may be able to file down some rough
edges and possibly add a generic-enough header matcher that skips a
message when that header is present.

Note this would be prone to abuse if they don't strip that header from
incoming messages with all the attachments in place (after scan) because
I could then just put that header and prevent your message download...

If that does not help and they are replacing messages in place, I need
to know the specification - would they put up a special header to mark
that the message is only a preview that is reliable enough to "skip" a
message? Is there reliable technical documentation? Note: I am not going
to research this beyond my search engine probes this morning, someone
will have to hand me the silver plate with all information. And after
looking through a spec, I may conclude it's too unreliable to be worth
investing more time.

Re: [Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

ATP dynamic delivery is a MS exchange concept whereby emails are delivered without attachments but preview links instead.  

The attachments are scanned off line and then the original email is sucked back and replaced by a new version of the email with the attachment - this can take quite a while.

If fetchmail gets the email before this process occurs the suck back and replacement with the attachment never happens, the "preview" link goes dead and the attachment never arrives.

It is definitely a server side issue but I can't change the server side behaviour (if you can change the server side settings then simple fix is to change the "dynamic" delivery policy with "replace" delivery policy which behaves like any normal system where the email is delivered after it is scanned).

This is not the only problem with ATP but it seems to be the biggest source of loss of attachments.

A possible tactic would be to exclude the fetching of emails containing these preview links and defer their download until the suck back and replacement process has happened.


On Friday, 28 July 2023 21:24:52 BST Matthias Andree wrote:
> Am 27.07.23 um 09:25 schrieb sup...@gm...:
> > "ATP dynamic delivery"
> 
> Whatever that means. fetchmail deals with IETF-standard protocols, and
> if on your upstream server, attachments go missing, talk to your
> provider's support. If it's a "server"-side setting on Microsoft stuff,
> same story. We can't fix server faults from the client's end.
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> 

Re: [Fetchmail-users] ATP dynamic delivery

[Matthias A. <mat...@gm...>]

Am 27.07.23 um 09:25 schrieb sup...@gm...:
> "ATP dynamic delivery"

Whatever that means. fetchmail deals with IETF-standard protocols, and
if on your upstream server, attachments go missing, talk to your
provider's support. If it's a "server"-side setting on Microsoft stuff,
same story. We can't fix server faults from the client's end.

[Fetchmail-users] ATP dynamic delivery

[<sup...@gm...>]

Anyone got any ideas about how to handle "ATP dynamic delivery"?

At present fetchmail is grabbing mail from my mail server which is implementing ATP dynamic delivery and this means large numbers of attachments are going missing. 

I don't have control of the mailserver policy so I can't simply replace "dynamic" with "replace" policies. 

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[Matthias A. <mat...@gm...>]

So... You have systemd and can use it to supervise and restart fetchmail - be sure to read up on fetchmail's --nodetach option for easier supervision.

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[<ns...@gm...>]

The plan ist to put Fetchmail between my mailserver (mailcow) and the Internet to collect mails from mailboxes without delay.
Fetchmail shall run on a Debian system.


> Gesendet: Mittwoch, den 26.07.2023 um 21:41 Uhr
> Von: "Matthias Andree" <mat...@gm...>
> An: fet...@li...
> Betreff: Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user
>
> Am 26.07.23 um 16:30 schrieb ns...@gm...:
> > I would like to have multiple Fetchmail instances running on machine. All instances shall be started directly on system start-up and running all the time until the system is shutdown.
> > Each of the instances shall hold one IMAP Idle connection.
> >
> > Is using the daemon mode the correct way or would it only be required to start/call each Fetchmail instance once in start-up and it will continue to run?
>
> Daemon mode is not a supervisor, it's a simple way to have fetchmail
> delay and re-poll at the end of a loop.
>
> > What about errors (e.g. interruptions of the IMAP connection), will fetchmal simply continue its processes or will they abort and have to be restarted?
> > How to ensure that Fetchmal runs forever and does never close a process?
>
> ... that you cannot reach with fetchmail alone, you will need use an
> external supervisor process which itself is privileged to not be killed
> by the system. fetchmail does not have supervisor code.
>
> The --daemon would apply should fetchmail fall out of the --idle in a
> more or less normal manner, but if you want robustness, an external
> supervising process is advised. You haven't mentioned about your OS, so
> we don't know what's already there and possibly suitable.
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[Matthias A. <mat...@gm...>]

Am 26.07.23 um 16:30 schrieb ns...@gm...:
> I would like to have multiple Fetchmail instances running on machine. All instances shall be started directly on system start-up and running all the time until the system is shutdown.
> Each of the instances shall hold one IMAP Idle connection.
>
> Is using the daemon mode the correct way or would it only be required to start/call each Fetchmail instance once in start-up and it will continue to run?

Daemon mode is not a supervisor, it's a simple way to have fetchmail
delay and re-poll at the end of a loop.

> What about errors (e.g. interruptions of the IMAP connection), will fetchmal simply continue its processes or will they abort and have to be restarted?
> How to ensure that Fetchmal runs forever and does never close a process?

... that you cannot reach with fetchmail alone, you will need use an
external supervisor process which itself is privileged to not be killed
by the system. fetchmail does not have supervisor code.

The --daemon would apply should fetchmail fall out of the --idle in a
more or less normal manner, but if you want robustness, an external
supervising process is advised. You haven't mentioned about your OS, so
we don't know what's already there and possibly suitable.

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[Andrew C A. <fet...@ai...>]

On Wed, 26 Jul 2023, ns...@gm... wrote:

> I would like to have multiple Fetchmail instances running on
> machine. All instances shall be started directly on system start-up
> and running all the time until the system is shutdown.  Each of the
> instances shall hold one IMAP Idle connection.

That sounds reasonable.

> Is using the daemon mode the correct way or would it only be
> required to start/call each Fetchmail instance once in start-up and
> it will continue to run?
> What about errors (e.g. interruptions of the IMAP connection), will
> fetchmal simply continue its processes or will they abort and have
> to be restarted?  How to ensure that Fetchmal runs forever and does
> never close a process?

fetchmail -idle *will* terminate on errors and closed connections;
The attached log file shows that it has stopped 52 times for me so far
this year; the error 11's were my ISP down for maintenance.

So, yes if you cannot have daemon mode and IDLE, you will need
some sort of wrapper script, daemon monitor, or cron job that checks
and restarts fetchmail when it stops.

I have a cron job which summarizes my unread mail a couple of times a day
and that reports if the pid-file is missing or there is no matching process.
I am only fetching my own mailbox and am happy to restart fetchmail
manually ...

Personally, if it were important that a service was *always* available
I would not trust the daemon providing the service to ensure that is
stayed up, but would want something else to monitor and if necessary
restart it.

>> Gesendet: Mittwoch, den 26.07.2023 um 16:10 Uhr
>> Von: "Andrew C Aitchison" <fet...@ai...>
>> An: ns...@gm...
>> Cc: fet...@li...
>> Betreff: Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user
>>
>> On Wed, 26 Jul 2023, ns...@gm... wrote:
>>
>>> is it possible to run IMAP Idle in daemon mode as non-root user? I don't get the point on how to configure the daemon interval if IMAP wants to keep the connection open for "Idle".
>>> Wouldn't the daemon interval conflict with the connection that is kept open?
>>>
>>> Could someone help me with my understanding?
>>
>> Are you using daemon mode because you want to connect to several
>> mailboxes ? In IDLE mode you can only connect to one mailbox, so I
>> think the answer is "No, you cannot run IDLE and daemon mode in the
>> same process".
>>
>> If you want to connect in IDLE mode, I would suggest a separate
>> FETCHMAILHOME directory, with its own config, and run a separate
>>            fetchmail -f <configfile>
>> process for each mailbox.
>>
>> --
>> Andrew C. Aitchison                      Kendal, UK
>>                     an...@ai...
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

-- 
Andrew C. Aitchison                      Kendal, UK
                    an...@ai...

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[Andrew C A. <fet...@ai...>]

On Wed, 26 Jul 2023, ns...@gm... wrote:

> is it possible to run IMAP Idle in daemon mode as non-root user? I don't get the point on how to configure the daemon interval if IMAP wants to keep the connection open for "Idle".
> Wouldn't the daemon interval conflict with the connection that is kept open?
>
> Could someone help me with my understanding?

Are you using daemon mode because you want to connect to several
mailboxes ? In IDLE mode you can only connect to one mailbox, so I
think the answer is "No, you cannot run IDLE and daemon mode in the
same process".

If you want to connect in IDLE mode, I would suggest a separate
FETCHMAILHOME directory, with its own config, and run a separate
           fetchmail -f <configfile>
process for each mailbox.

-- 
Andrew C. Aitchison                      Kendal, UK
                    an...@ai...

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[<ns...@gm...>]

I would like to have multiple Fetchmail instances running on machine. All instances shall be started directly on system start-up and running all the time until the system is shutdown.
Each of the instances shall hold one IMAP Idle connection.

Is using the daemon mode the correct way or would it only be required to start/call each Fetchmail instance once in start-up and it will continue to run?
What about errors (e.g. interruptions of the IMAP connection), will fetchmal simply continue its processes or will they abort and have to be restarted?
How to ensure that Fetchmal runs forever and does never close a process?



> Gesendet: Mittwoch, den 26.07.2023 um 16:10 Uhr
> Von: "Andrew C Aitchison" <fet...@ai...>
> An: ns...@gm...
> Cc: fet...@li...
> Betreff: Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user
>
> On Wed, 26 Jul 2023, ns...@gm... wrote:
>
> > is it possible to run IMAP Idle in daemon mode as non-root user? I don't get the point on how to configure the daemon interval if IMAP wants to keep the connection open for "Idle".
> > Wouldn't the daemon interval conflict with the connection that is kept open?
> >
> > Could someone help me with my understanding?
>
> Are you using daemon mode because you want to connect to several
> mailboxes ? In IDLE mode you can only connect to one mailbox, so I
> think the answer is "No, you cannot run IDLE and daemon mode in the
> same process".
>
> If you want to connect in IDLE mode, I would suggest a separate
> FETCHMAILHOME directory, with its own config, and run a separate
>            fetchmail -f <configfile>
> process for each mailbox.
>
> --
> Andrew C. Aitchison                      Kendal, UK
>                     an...@ai...

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[<ns...@gm...>]

This answers a part of my question, thanks!

But how to configure the daemon interval if IMAP wants to keep the connection open for "Idle".
Wouldn't the daemon interval conflict with the connection that is kept open (wouldn't Fetchmail try to open a new connection on each daemon intervall instead of only listening to push notifications)?


> Gesendet: Mittwoch, den 26.07.2023 um 14:25 Uhr
> Von: "Andrzej Milewski" <and...@gm...>
> An: fet...@li...
> Betreff: Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user
> 
> in file
> 
> /usr/local/bin/fetchmail-imap-idle
> you have
> fetchmailuser=fetchmail
> fetchmailgroup=nogroup
> 
> On Wed, Jul 26, 2023 at 2:20 PM <ns...@gm...> wrote:
> 
> > Hi,
> >
> > is it possible to run IMAP Idle in daemon mode as non-root user? I don't
> > get the point on how to configure the daemon interval if IMAP wants to keep
> > the connection open for "Idle".
> > Wouldn't the daemon interval conflict with the connection that is kept
> > open?
> >
> > Could someone help me with my understanding?
> >
> > Thanks a lot in ad advance.
> >
> >
> > _______________________________________________
> > Fetchmail-users mailing list
> > Fet...@li...
> > https://lists.sourceforge.net/lists/listinfo/fetchmail-users
> >
> 
> 
> -- 
> Andrzej Milewski
> and...@gm...
> tel. 0603957324
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[Andrzej M. <and...@gm...>]

in file

/usr/local/bin/fetchmail-imap-idle
you have
fetchmailuser=fetchmail
fetchmailgroup=nogroup

On Wed, Jul 26, 2023 at 2:20 PM <ns...@gm...> wrote:

> Hi,
>
> is it possible to run IMAP Idle in daemon mode as non-root user? I don't
> get the point on how to configure the daemon interval if IMAP wants to keep
> the connection open for "Idle".
> Wouldn't the daemon interval conflict with the connection that is kept
> open?
>
> Could someone help me with my understanding?
>
> Thanks a lot in ad advance.
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>


-- 
Andrzej Milewski
and...@gm...
tel. 0603957324

[Fetchmail-users] IMAP Idle in Daemon mode as non-root user

[<ns...@gm...>]

Hi,

is it possible to run IMAP Idle in daemon mode as non-root user? I don't get the point on how to configure the daemon interval if IMAP wants to keep the connection open for "Idle".
Wouldn't the daemon interval conflict with the connection that is kept open?

Could someone help me with my understanding?

Thanks a lot in ad advance.