fetchmail-users — User questions and discussion

Re: [Fetchmail-users] MASL SASL Oauth support for Exchange Online IMAP

[David T. <da...@ya...>]

 Thanks for your reply Matthias.
    On Thursday, 29 October 2020, 10:43:37 am NZDT, Matthias Andree <mat...@gm...> wrote:  
 
 Am 28.10.20 um 21:08 schrieb David Tildesley via Fetchmail-users:
> Hi,
> Does Fetchmail support the "modern authentication" method for Exchange Online (M365)

Hi David,

Not natively - not yet. There are contrib/ features for Google, not sure
how much tweaking they need for Microsoft's Office suites, I guess the
amount of tweaking would not be nontrivial.

I however actively object to the marketeing blurb infested terms of
"less secure apps", "modern authentication" and whatnot.
I appreciate you put them into double quotes.

Sorry.

Regards,
Matthias



_______________________________________________
Fetchmail-users mailing list
Fet...@li...
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
  

Re: [Fetchmail-users] MASL SASL Oauth support for Exchange Online IMAP

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

Am 28.10.20 um 21:08 schrieb David Tildesley via Fetchmail-users:
> Hi,
> Does Fetchmail support the "modern authentication" method for Exchange Online (M365)

Hi David,

Not natively - not yet. There are contrib/ features for Google, not sure
how much tweaking they need for Microsoft's Office suites, I guess the
amount of tweaking would not be nontrivial.

I however actively object to the marketeing blurb infested terms of
"less secure apps", "modern authentication" and whatnot.
I appreciate you put them into double quotes.

Sorry.

Regards,
Matthias

[Fetchmail-users] MASL SASL Oauth support for Exchange Online IMAP

[David T. <da...@ya...>]

Hi,
Does Fetchmail support the "modern authentication" method for Exchange Online (M365)
Regards,David.

Re: [Fetchmail-users] making fetchmail delete a successfully downloaded email from dovecot

[Carlos E. R. <rob...@te...>]

On 11/10/2020 22.36, Gene Heskett wrote:
> On Sunday 11 October 2020 15:29:02 Lucio Chiappetti wrote:
> 
>> On Sun, 11 Oct 2020, Gene Heskett wrote:
>>>>>>> Shentel.net does not allow fetchmail to delete a downloaded
>>>>>>> email because their dovecot server handles imap and pop3 from
>>>>>>> the same directory and somebody might want to come in from imap.
>>
>> I cannot talk for your provider, but can tell my experience with
>> gsuite (gmail) since my institution moved to it.
> 
> Where do I send flowers of sympathy? gmail was broken the 6 months I put
> up with it
> 
> It took a wee bit of tinkering & studying of the manpage, but its now
> using imap and successfully expunging what it fetches. So until they
> fill the spam folder up too, I am a happy camper.

poll SERVER with proto imap timeout 20, and tracepolls
        user USERNAME, with password PASS, is cer here, and fetchall, expunge 20,  folders Inbox, Spam, Junk

I have not tried it with gmail.


-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [Fetchmail-users] gmail login suddenly failing

[Dennis P. <da...@be...>]

On 10/25/2020 12:09 PM, James Cloos wrote:
>>>>>> "KG" == Kevin Gehrke <kg...@co...> writes:
> KG> Check if allow less secure apps has been turned off in Gmail settings.
>
> what he wrote.  they did that to me behind my back (and w/o consent of
> course); probably did it to everyone...
>
> -JimC
Apparently, if you don't log in using it often enough, they turn it off
automatically. As far as I know they don't say what that time interval
is. I now have a cron job to do it several times per day.

Re: [Fetchmail-users] gmail login suddenly failing

[James C. <cl...@jh...>]

>>>>> "KG" == Kevin Gehrke <kg...@co...> writes:

KG> Check if allow less secure apps has been turned off in Gmail settings.

what he wrote.  they did that to me behind my back (and w/o consent of
course); probably did it to everyone...

-JimC
-- 
James Cloos <cl...@jh...>         OpenPGP: 0x997A9F17ED7DAEA6

[Fetchmail-users] ANNOUNCE: The 6.4.13 release of fetchmail is available (lock file/pidfile bug fixes)

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

Greetings,

Fetchmail 6.4.13 has been released and is now available at the usual location,
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

Please test it and report back. I'll send it off to the translation project in parallel.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13.tar.lz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13.tar.lz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.13.tar.lz)= 326dcea5b001ef11e1bf0e3e53da9a4dcb4069120772480fc16b8fa7683672b6
SHA256(fetchmail-6.4.13.tar.xz)= 7d28cf060b06b9c8ec72267be7edc9a99b70f61d7d32d8b609458dcedfa74be1

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.13 (released 2020-10-25, 27608 LoC):

# BUG FIXES:
* Errors about lock file (= pidfile) creation could be lost in daemon 
  configurations (-d option, or set daemon) when using syslog. Now they are also 
  logged to syslog.  Found verifying a pidfile creation issue on 6.4.12 that was 
  previously reported by Alex Hall of Automatic Distributors.
* If the lock file cannot be removed (no write permission on directory), try
  to truncate it, and if that fails, report error.
* If the pidfile was non-default, fetchmail -q or --quit would malfunction and
  claim no other fetchmail were running, because it did not read the 
  configuration files or merge the command line options, thus it would look for 
  the PID in the wrong file.

# CHANGES:
* Lockfile (= pidfile) creation errors are now logged with filename and reason.

# TRANSLATION UPDATES were made by these fine people:
* cs:    Petr Pisar [Czech]
* ja:    Takeshi Hamasaki [Japanese]
* sq:    Besnik Bleta [Albanian]
* zh_CN: Boyuan Yang [Chinese (simplified)]
* sv:    Göran Uddeborg [Swedish]
* pl:    Jakub Bogusz [Polish]
* fr:    Frédéric Marchal [French]
* eo:    Keith Bowes [Esperanto]
* de:    [German - by current maintainer]
---------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] gmail login suddenly failing

[Dennis P. <da...@be...>]

Arrgghhhh! I hate when they do that. Thanks for the reply.

On 10/24/2020 7:24 PM, Kevin Gehrke wrote:
> Check if allow less secure apps has been turned off in Gmail settings.
>
> On 10/24/2020 12:13 PM, Dennis Putnam wrote:
>> fetchmail: POP3< SASL PLAIN XOAUTH2 OAUTHBEARER
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] gmail login suddenly failing

[Kevin G. <kg...@co...>]

Check if allow less secure apps has been turned off in Gmail settings.

On 10/24/2020 12:13 PM, Dennis Putnam wrote:
> fetchmail: POP3< SASL PLAIN XOAUTH2 OAUTHBEARER

[Fetchmail-users] gmail login suddenly failing

[Dennis P. <da...@be...>]

*I've been using fetchmail ( 6.3.24) for some time with my gmail
accounts. Recently the login has started failing. The credentials work
when logging in from a browser. Here is my sanitized fetchmailrc:*

set logfile "/var/log/maillog"
set postmaster "mailman"
set bouncemail
set no spambounce
set properties ""
defaults:
        timeout 240
poll pop.gmail.com
        proto POP3
        user "myu...@gm..."
        is mylocalmailbox
        password 'mypassword'
        preconnect "echo `date '+%b %d %H:%M:%S'` mylocalmailbox"
        ssl
        nokeep
        fetchall

*Here is the sanitized fetchmail log:*

fetchmail: 6.3.24 querying pop.gmail.com (protocol POP3) at Sat 24 Oct
2020 02:38:39 PM EDT: poll started
Oct 24 14:38:39 myusername
Trying to connect to 2607:f8b0:4002:c02::6d/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: GlobalSign
fetchmail: Issuer CommonName: GlobalSign
fetchmail: Subject CommonName: GlobalSign
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GlobalSign
fetchmail: Issuer CommonName: GlobalSign
fetchmail: Subject CommonName: GTS CA 1O1
fetchmail: Server certificate:
fetchmail: Issuer Organization: Google Trust Services
fetchmail: Issuer CommonName: GTS CA 1O1
fetchmail: Subject CommonName: pop.gmail.com
fetchmail: Subject Alternative Name: pop.gmail.com
fetchmail: pop.gmail.com key fingerprint:
47:D5:17:41:EC:FA:3D:C6:10:5B:F0:CB:10:D0:F2:CD
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher
ECDHE-RSA-AES128-GCM-SHA256, 128/128 secret/processed bits
fetchmail: POP3< +OK Gpop ready for requests from
2600:1702:1a40:d5a0::48 h205mb28732228qke
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< USER
fetchmail: POP3< RESP-CODES
fetchmail: POP3< EXPIRE 0
fetchmail: POP3< LOGIN-DELAY 300
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< X-GOOGLE-RICO
fetchmail: POP3< SASL PLAIN XOAUTH2 OAUTHBEARER
fetchmail: POP3< .
fetchmail: POP3> USER myu...@gm...
fetchmail: POP3< +OK send PASS
fetchmail: POP3> PASS *
fetchmail: POP3< -ERR [AUTH] Username and password not accepted.
fetchmail: [AUTH] Username and password not accepted.
fetchmail: Authorization failure on myu...@gm...@pop.gmail.com
fetchmail: For help, see http://www.fetchmail.info/fetchmail-FAQ.html#R15
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Bye h205mb28732228qke

*Has gmail changed the protocol for POP3? Can someone tell me what I
need to change to restore operation? TIA.*

Re: [Fetchmail-users] (jmm) Fetchmail failed to fetch

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

Am 22.10.20 um 19:56 schrieb James Moe via Fetchmail-users:
> On 10/22/20 10:28 AM, James Moe via Fetchmail-users wrote:
>
>>   Fetchmail had trouble with this one message. Both fetchmail and the local mail
>> server blamed each other for the failure.
>>   The message is a trojan with a tainted XLS file; about 126KB.
>>
>   Well. I got that one way wrong. I forgot about the Spam proxy between
> fetchmail and the server.
>   I updated the log file with the proxy's log. It makes sense that the mail
> server logged a broken connection, because that is what happened: the proxy
> flagged the mail as spam and dropped the connection.
>   However, the proxy also returned a 554 message to fetchmail that was ignored,
> repeatedly.
>   The first log section of the proxy is normal. The following two are the proxy
> wondering was is wrong with fetchmail.

well, the connection appears to be broken by the proxy before the 554
can be properly received. T

here's some equivocation in the error path, so the information of what
exactly failed isn't available in the place that traps and reports the
error.

There's also not much debugging either that could be enabled, but you
might be able to use truss, strace or ktrace on fetchmail to figure what
fetchmail did and which syscall broke.

To me, it looks as though a socket send or pipe write to an MDA failed
from the proxy breaking the connection, and even if the proxy attempted
to write the 554 before fetchmail has completed sending the body, if the
proxy then jams the connection, that 554 may not arrive because
fetchmail receives the TCP RST packet before having sent all of its
data, the next write fails due to the closed socket or broken pipe, and
in that situation, fetchmail itself also breaks the connection.
Fetchmail will only try to read an error code after sending the SMTP
"DATA" and the CRLF.CRLF completely, because well-behaved servers will
not reply sooner.

Re: [Fetchmail-users] (jmm) Fetchmail failed to fetch

[James M. <ji...@so...>]

On 10/22/20 10:56 AM, Matthias Andree wrote:

> is there any middleware, malware filter, spam filter, firewall, whatever
> involved that might deliberately break the connection "from the outside"
> the moment when it detected the malware on the SMTP connection?
>
  Ah. You missed my second message.
  Yes, there is a spam proxy in between the two mail processors.

-- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.

Re: [Fetchmail-users] (jmm) Fetchmail failed to fetch

[James M. <ji...@so...>]

On 10/22/20 10:28 AM, James Moe via Fetchmail-users wrote:

>   Fetchmail had trouble with this one message. Both fetchmail and the local mail
> server blamed each other for the failure.
>   The message is a trojan with a tainted XLS file; about 126KB.
>
  Well. I got that one way wrong. I forgot about the Spam proxy between
fetchmail and the server.
  I updated the log file with the proxy's log. It makes sense that the mail
server logged a broken connection, because that is what happened: the proxy
flagged the mail as spam and dropped the connection.
  However, the proxy also returned a 554 message to fetchmail that was ignored,
repeatedly.
  The first log section of the proxy is normal. The following two are the proxy
wondering was is wrong with fetchmail.

-- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.

Re: [Fetchmail-users] (jmm) Fetchmail failed to fetch

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

Am 22.10.20 um 19:28 schrieb James Moe via Fetchmail-users:
> fetchmail 6.4.11
> opensuse LEAP 15.2
>
>   Fetchmail had trouble with this one message. Both fetchmail and the local mail
> server blamed each other for the failure.
>   The message is a trojan with a tainted XLS file; about 126KB.
>   The log has the mail server's log of the transaction; it is the first part of
> the log file (see below). The server was waiting (for not many bytes!?) when it
> logged the connection as closed by fetchmail.
>   Fetchmail sent the message header, then complained that the server broke the
> connection. And proceeded to download the body anyway. And did not bother with
> any of the other messages.
>
>   My query: What happened?
>
> Log file: https://www.dropbox.com/s/5nj3wh8jlnfxv79/fetchmail.log?dl=0
>
James,

is there any middleware, malware filter, spam filter, firewall, whatever
involved that might deliberately break the connection "from the outside"
the moment when it detected the malware on the SMTP connection?

I've checked the fetchmail 6.4.13-rc1 code path (unchanged from 6.4.11),
and indeed when the output fails, fetchmail aborts the fetch, so "did
not bother with
any of the other messages." is what the code intends. All fetchmail
releases I've made in fact behave this way, and Eric Raymond's 6.2.5
also did. I can only surmise the assumption was that if we fail shipping
one message due to a hard error (lost connection), shipping more
messages in the same run doesn't make sense.

I see from the log that you are using an "MDA" to deliver mail, so can
you show your configuration? See
https://www.fetchmail.info/fetchmail-FAQ.html#G3, item #5, for instructions.

Regards,
Matthias

[Fetchmail-users] (jmm) Fetchmail failed to fetch

[James M. <ji...@so...>]

fetchmail 6.4.11
opensuse LEAP 15.2

  Fetchmail had trouble with this one message. Both fetchmail and the local mail
server blamed each other for the failure.
  The message is a trojan with a tainted XLS file; about 126KB.
  The log has the mail server's log of the transaction; it is the first part of
the log file (see below). The server was waiting (for not many bytes!?) when it
logged the connection as closed by fetchmail.
  Fetchmail sent the message header, then complained that the server broke the
connection. And proceeded to download the body anyway. And did not bother with
any of the other messages.

  My query: What happened?

Log file: https://www.dropbox.com/s/5nj3wh8jlnfxv79/fetchmail.log?dl=0

-- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.

Re: [Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[Carlos E. R. <rob...@te...>]

On 18/10/2020 00.30, mario chiari wrote:
> On Sat, 2020-10-17 at 21:23 +0200, Carlos E. R. wrote:
>> On 17/10/2020 20.27, mario chiari wrote:
>>> ....
>>
>> The limit may be imposed by the receiving mail server.
>>
> 
> Thanks for your help.
> 
> how do I check?

Your log in the other post confirms it:


fetchmail: about to deliver with: /usr/lib/courier/bin/sendmail  -i -f 'posta@<domain>' 
523 Message length (10485808 bytes) exceeds administrative limit(10485760).
sendmail: Unable to submit message.
fetchmail: MDA returned nonzero status 67
fetchmail: not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Logging out.

It is your sendmail (the receiving mail server) who imposes a limit of 10485760 bytes.
I have not touched sendmail in perhaps two decades, I have forgotten how to do that.

Or perhaps it is courier limited version of sendmail, which I have never handled.

Sorry, I can only point at the cause, not help you to solve it :-}

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[mario c. <ml...@ma...>]

On Sat, 2020-10-17 at 21:23 +0200, Carlos E. R. wrote:
> On 17/10/2020 20.27, mario chiari wrote:
> > ....
> 
> The limit may be imposed by the receiving mail server.
> 

Thanks for your help.

how do I check? 
m. 

Re: [Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[mario c. <ml...@ma...>]

Hi

thanks for your help, but nope.

I get:

.....

fetchmail: about to deliver with: /usr/lib/courier/bin/sendmail  -i -f
'posta@<domain>' 
523 Message length (10485808 bytes) exceeds administrative
limit(10485760).
sendmail: Unable to submit message.
fetchmail: MDA returned nonzero status 67
fetchmail: not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Logging out.

.....

any other idea?
m. 



On Sat, 2020-10-17 at 18:50 +0000, ಚಿರಾಗ್ ನಟರಾಜ್ wrote:
> Maybe use --limit=0?
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[Carlos E. R. <rob...@te...>]

On 17/10/2020 20.27, mario chiari wrote:
> Hi,
> 
> I am not able to download a mail with a large attached file; log shows
> 
> 	523 Message length (10485808 bytes) exceeds administrative
> limit(10485760).
> 
> 
> I use to download mails from a remote server by the following line
> command
> 
>> fetchmail --sslcertck --sslcommonname remote.domain
> 
> Is there a way to pass a parameter as to download my large mail?

The limit may be imposed by the receiving mail server.


-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.1 x86_64 at Telcontar)

Re: [Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[ಚಿರಾಗ್ ನ. <mai...@ch...>]

Maybe use --limit=0?
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Pronouns: he/him/his

17/10/20 20:27 ನಲ್ಲಿ, mario chiari <ml...@ma...> ಬರೆದರು:
> 
> Hi,
> 
> I am not able to download a mail with a large attached file; log shows
> 
> 	523 Message length (10485808 bytes) exceeds administrative
> limit(10485760).
> 
> 
> I use to download mails from a remote server by the following line
> command
> 
> > fetchmail --sslcertck --sslcommonname remote.domain
> 
> Is there a way to pass a parameter as to download my large mail?
> 
> thanks regards
> mario
> 
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

[Fetchmail-users] 523 Message length (10485808 bytes) exceeds administrative limit(10485760).

[mario c. <ml...@ma...>]

Hi,

I am not able to download a mail with a large attached file; log shows 

	523 Message length (10485808 bytes) exceeds administrative
limit(10485760).


I use to download mails from a remote server by the following line
command

> fetchmail --sslcertck --sslcommonname remote.domain

Is there a way to pass a parameter as to download my large mail? 

thanks regards
mario 

[Fetchmail-users] ANNOUNCE: (URLS corrected) fetchmail 6.4.13 release candidate #2 is now available (translation updates, one error message fixed since -rc1)

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

[URLs corrected for downloads and GnuPG signatures]

Greetings,

Fetchmail's 6.4.13 release CANDIDATE #2 is now available at the usual location,
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

Please test it and report back. I'll send it off to the translation project in parallel.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13-rc2.tar.xz/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13-rc2.tar.lz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13-rc2.tar.xz.asc/download>
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.13-rc2.tar.lz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.13-rc2.tar.lz)= 045b6ce950423e7b76c8797555ccb8e0fa6ccf513aefeb2ddbbea98843487a97
SHA256(fetchmail-6.4.13-rc2.tar.xz)= 54f582b5b6034e681ca602120b2c865f8efb00768f0672998f3e6bcbe4a988d9

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.13 (work in progress):

# BUG FIXES:
* Errors about lock file (= pidfile) creation could be lost in daemon 
  configurations (-d option, or set daemon) when using syslog. Now they are also 
  logged to syslog.  Found verifying a pidfile creation issue on 6.4.12 that was 
  previously reported by Alex Hall of Automatic Distributors.
* If the lock file cannot be removed (no write permission on directory), try
  to truncate it, and if that fails, report error.
* If the pidfile was non-default, fetchmail -q or --quit would malfunction and
  claim no other fetchmail were running, because it did not read the 
  configuration files or merge the command line options, thus it would look for 
  the PID in the wrong file.

# CHANGES:
* Lockfile (= pidfile) creation errors are now logged with filename and reason.

# TRANSLATION UPDATES were made by these fine people (German was also updated):
* cs:    Petr Pisar [Czech]
* ja:    Takeshi Hamasaki [Japanese]
* sq:    Besnik Bleta [Albanian]
* zh_CN: Boyuan Yang [Chinese (simplified)]
* sv:    Göran Uddeborg [Swedish]
* pl:    Jakub Bogusz [Polish]
* de:    [German - by current maintainer]
---------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.13 release candidate #2 is now available (translation updates, one error message fixed since -rc1)

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

Greetings,

Fetchmail's 6.4.13 release CANDIDATE #2 is now available at the usual location,
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

Please test it and report back. I'll send it off to the translation project in parallel.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc2.tar.xz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc2.tar.lz>

Detached GnuPG signatures for the respective tarballs are at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc2.tar.xz.asc>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc2.tar.lz.asc>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.13-rc2.tar.lz)= 045b6ce950423e7b76c8797555ccb8e0fa6ccf513aefeb2ddbbea98843487a97
SHA256(fetchmail-6.4.13-rc2.tar.xz)= 54f582b5b6034e681ca602120b2c865f8efb00768f0672998f3e6bcbe4a988d9

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.13 (work in progress):

# BUG FIXES:
* Errors about lock file (= pidfile) creation could be lost in daemon 
  configurations (-d option, or set daemon) when using syslog. Now they are also 
  logged to syslog.  Found verifying a pidfile creation issue on 6.4.12 that was 
  previously reported by Alex Hall of Automatic Distributors.
* If the lock file cannot be removed (no write permission on directory), try
  to truncate it, and if that fails, report error.
* If the pidfile was non-default, fetchmail -q or --quit would malfunction and
  claim no other fetchmail were running, because it did not read the 
  configuration files or merge the command line options, thus it would look for 
  the PID in the wrong file.

# CHANGES:
* Lockfile (= pidfile) creation errors are now logged with filename and reason.

# TRANSLATION UPDATES were made by these fine people (German was also updated):
* cs:    Petr Pisar [Czech]
* ja:    Takeshi Hamasaki [Japanese]
* sq:    Besnik Bleta [Albanian]
* zh_CN: Boyuan Yang [Chinese (simplified)]
* sv:    Göran Uddeborg [Swedish]
* pl:    Jakub Bogusz [Polish]
* de:    [German - by current maintainer]
---------------------------------------------------------------------------------
By popular demand, diffs from the previous release have been omitted.
---------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.13 release candidate #1 is now available (lock file fixes)

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

Greetings,

Fetchmail's 6.4.13 release CANDIDATE is now available at the usual location,
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

Please test it and report back. I'll send it off to the translation project in parallel.

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc1.tar.xz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc1.tar.lz>

Detached GnuPG signatures for the respective tarballs are at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc1.tar.xz.asc>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.13.rc1.tar.lz.asc>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.13.rc1.tar.lz)= ff9c11c806570ae0f21f78c6e33a9ef434b277454eb1b24043f73b774d579a35
SHA256(fetchmail-6.4.13.rc1.tar.xz)= fc74e83b71c2ad7129db288fe511d4e4f6de94cfcda189705cf61402cd811389

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.13 (work in progress):

# BUG FIXES:
* Errors about lock file (= pidfile) creation could be lost in daemon 
  configurations (-d option, or set daemon) when using syslog. Now they are also 
  logged to syslog.  Found verifying a pidfile creation issue on 6.4.12 that was 
  previously reported by Alex Hall of Automatic Distributors.
* If the lock file cannot be removed (no write permission on directory), try
  to truncate it, and if that fails, report error.
* If the pidfile was non-default, fetchmail -q or --quit would malfunction and
  claim no other fetchmail were running, because it did not read the 
  configuration files or merge the command line options, thus it would look for 
  the PID in the wrong file.

# CHANGES:
* Lockfile (= pidfile) creation errors are now logged with filename and reason.
---------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] Fetchmail seems to silently fail when I use the --pidfile option

[Alex H. <ah...@au...>]

I solved this with a very helpful suggestion from Matthias. See below.

On 10/12/2020 17:04, Alex Hall wrote:
> Hello,
> I've used fetchmail for a couple years, as a way of pulling emails 
> into the Request Tracker ticket system I set up for my work. I'm 
> trying to better automate it, by setting it up with Monit. To do that, 
> I want to use the --pidfile option when starting or quitting 
> fetchmail, which I've not tried before.
>
> First, the details. I'm on Debian 8, with fetchmail 6.3.26. I 
> installed this from Debian's package manager; I didn't compile any 
> source. I know Debian 8 is outdated, but we're stuck on this server 
> for a while for various reasons. The server reports that this is the 
> most recent version of fetchmail it can find.
>
> In the past, I'd start fetchmail manually (this is part of what I want 
> to automate with Monit). I use this command:
> sudo -u rt-user fetchmail -f /path/rt4/fetchmailrc
>
> To let Monit have a known pid file to monitor, I tried this command:
> sudo -u rt-user fetchmail -f /path/rt4/fetchmailrc --pidfile 
> /var/run/rt_fetchmail.pid
>
> When I run that command in the terminal, nothing at all happens. I get 
> no output, /var/run/rt_fetchmail.pid is not created, and fetchmail 
> doesn't seem to run. I should say here that the fetchmailrc file being 
> used commands fetchmail to start as a daemon. If I leave off the 
> --pidfile bit, the daemon starts as expected. I can then
> sudo -u rt-user fetchmail --quit
> to kill it. Running that quit command after using the --pidfile 
> variant produces no output.
>
> It seems like the --pidfile option causes a silent failure, but I 
> can't figure out what's going on. The log only shows normal mail 
> managing stuff, with no errors that I've found, and the terminal has 
> no output whatsoever.
>
> I've found nothing online about this problem, so am not sure where 
> else to turn. If anyone on this list has ideas, I'd love to hear them. 
> If I've left out any important information, let me know. Thanks for 
> any help.


First, I was getting no output, so let's fix that:

cd ~

touch fetchmail.log

chown rt-user fetchmail.log

sudo -u rt-user fetchmail -f /path/fetchmailrc --nosyslog -d0 --logfile 
/home/my_user/fetchmail.log


Note that you can try --logfile /dev/stderr, but rt-user couldn't write 
to that, so I had to use a file instead. Anyway, when I checked 
fetchmail.log, the problem was right there: rt-user had no permission to 
write to /var/run. This seems glaringly obvious in retrospect.


Fortunately, there's a simple fix:

sudo mkdir -p /var/run/rt_fetchmail

sudo chown rt-user /var/run/rt_fetchmail


Now, amend the original command to use the new subfolder, and we're golden:

sudo -u rt-user fetchmail -f /path/fetchmailrc --pidfile 
/var/run/rt_fetchmail/rt_fetchmail.pid


This, and a --quit command using the same pid file, let Monit control 
fetchmail just fine. I had to add the creation and ownership change for 
/var/run/rt_fetchmail to my server's startup (I used a cron job entry 
with @reboot), but that was the only other step. So far, things are 
working well.


Remember: users can't create pid files in /var/run, you have to use 
subdirectories which you have to set to the right owner first. Also, if 
fetchmail is giving no output at all, use -d0 to disable any daemon 
directives in fetchmailrc (or just skip the rc file completely if you 
know the problem is before anything in that file), --nosyslog to stop 
fetchmail's messages going to the syslog, and --logfile to redirect 
those messages to somewhere you can more easily review them.

>
> --
>
> Alex Hall
>
> ah...@au...
>
>