You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthias A. <mat...@gm...> - 2023-08-03 21:38:50
|
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. |
From: Matthias A. <mat...@gm...> - 2023-08-03 21:38:26
|
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. |
From: <ns...@gm...> - 2023-08-03 08:06:23
|
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. |
From: <ns...@gm...> - 2023-08-01 11:11:17
|
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. |
From: <sup...@gm...> - 2023-08-01 06:57:38
|
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. |
From: Matthias A. <mat...@gm...> - 2023-07-30 22:47:25
|
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. |
From: <sup...@gm...> - 2023-07-29 11:35:21
|
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 > |
From: Matthias A. <mat...@gm...> - 2023-07-29 09:11:46
|
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. |
From: <sup...@gm...> - 2023-07-29 08:30:26
|
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 > |
From: Matthias A. <mat...@gm...> - 2023-07-29 06:21:24
|
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. |
From: <sup...@gm...> - 2023-07-28 22:31:42
|
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 > |
From: Matthias A. <mat...@gm...> - 2023-07-28 20:25:07
|
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. |
From: <sup...@gm...> - 2023-07-27 07:25:23
|
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. |
From: Matthias A. <mat...@gm...> - 2023-07-27 06:29:17
|
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. |
From: <ns...@gm...> - 2023-07-27 06:10:35
|
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 |
From: Matthias A. <mat...@gm...> - 2023-07-26 19:41:28
|
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. |
From: Andrew C A. <fet...@ai...> - 2023-07-26 15:27:15
|
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... |
From: Andrew C A. <fet...@ai...> - 2023-07-26 14:44:22
|
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... |
From: <ns...@gm...> - 2023-07-26 14:30:23
|
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... |
From: <ns...@gm...> - 2023-07-26 13:01:50
|
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 |
From: Andrzej M. <and...@gm...> - 2023-07-26 12:26:17
|
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 |
From: <ns...@gm...> - 2023-07-26 12:18:58
|
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. |
From: Andrzej M. <and...@gm...> - 2023-07-25 11:56:35
|
Yes try this https://otremba.net/wiki/Fetchmail_(Debian) On Tue, Jul 25, 2023 at 1:51 PM <ns...@gm...> wrote: > Hello, > > is fetchmail able to use the mechanism of push notifications to be anle to > receive new E-Mails immeadiately from a server? > > Thanks, > > Thomas > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > -- Andrzej Milewski and...@gm... tel. 0603957324 |
From: <ns...@gm...> - 2023-07-25 11:50:14
|
Hello, is fetchmail able to use the mechanism of push notifications to be anle to receive new E-Mails immeadiately from a server? Thanks, Thomas |
From: Ede W. <li...@ne...> - 2023-07-06 14:46:55
|
auth password does indeed work, if one gets enough sleep and therefore stays clear from typos. Fixed. Am 06.07.23 um 08:18 schrieb Ede Wolf: > Hello, > > I am dealing with a buggy pop3 server, that announces cram-md5 > authentication, but in fact does not do so (any more). Confirmed by the > support. > > As I will not be able to fix the remote server, I am wondering, are > there a means to tell fetchmail to only use either plain or login? Both > are advertised as well. > > Adding "authenticate password" to fetchmailrc does not do the trick. > > The connection itself is TLS secured > > Thanks > > Ede > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users |