fetchmail-users — User questions and discussion

Re: [Fetchmail-users] somehow broke fetchmail trying to fix outgoing email :(

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

On 02/10/2020 08.05, Abe Stone via Fetchmail-users wrote:
> Hi,
> 
> When I got up this morning I found that my outgoing mail
> wasn't working. Of course that had nothing to do with
> fetchmail, and I was still able to retrieve my mail from
> gmail using POP3 as usual. I spent most of the day getting
> the outgoing mail to work again. But now I find that
> fetchmail can't deliver the incoming mail locally anymore. I
> get "smtp listener protocol error."

Try to send an email from a local user to another local user using 
command "mail".

-- 
Cheers / Saludos,

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

[Fetchmail-users] somehow broke fetchmail trying to fix outgoing email :(

[Abe S. <abe...@uc...>]

Hi,

When I got up this morning I found that my outgoing mail
wasn't working. Of course that had nothing to do with
fetchmail, and I was still able to retrieve my mail from
gmail using POP3 as usual. I spent most of the day getting
the outgoing mail to work again. But now I find that
fetchmail can't deliver the incoming mail locally anymore. I
get "smtp listener protocol error."

The weird thing is, even when I change main.cf back to what
it was before (which would break my outgoing mail again, but
never mind that), the problem persists.

I'm running fetchmail 6.4.4 on Mac OS 10.13.6 (High Sierra).

The verbose fetchmail log looks like this (as you can see,
everything works fine until it tries to deliver locally):

fetchmail: 6.4.4 querying pop.gmail.com (protocol POP3) at Thu, 01 Oct 2020 21:50:34 -0700 (PDT): poll started
fetchmail: Trying to connect to 108.177.98.108/995...connected.
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: 80:74:2A:92:40:2C:6E:B2:82:95:8F:EF:E5:74:61:BD
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK Gpop ready for requests from 135.180.12.77 t18mb74240021ioi
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 abe...@gm...
fetchmail: POP3< +OK send PASS
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Welcome.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 59 2750128
fetchmail: 59 messages for abe...@gm... at pop.gmail.com (2750128 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 35221
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK message follows
fetchmail: reading message abe...@gm...@pop.gmail.com:1 of 59 (35221 octets)Trying to connect to 127.0.0.1/25...connected.
fetchmail: smtp listener protocol error
fetchmail: Trying to connect to 127.0.0.1/25...connected.
fetchmail: smtp listener protocol error
fetchmail: SMTP connect to localhost failed
fetchmail: POP3> QUIT
fetchmail: POP3< --Mjk5MjIxMDM3OTAzNjQ2MDg
fetchmail: SMTP transaction error while fetching from abe...@gm...@pop.gmail.com and delivering to SMTP host localhost
fetchmail: 6.4.4 querying pop.gmail.com (protocol POP3) at Thu, 01 Oct 2020 22:00:35 -0700 (PDT): poll completed
fetchmail: Query status=10 (SMTP)
fetchmail: normal termination, status 10

The verbose log from smtpd looks like this:

2020-10-01 21:50:35.514198-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:50:35.514284-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: client_address
2020-10-01 21:50:35.514358-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 127.0.0.1
2020-10-01 21:50:35.514407-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:50:35.514451-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: client_port
2020-10-01 21:50:35.514491-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 50368
2020-10-01 21:50:35.514531-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:50:35.514569-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: server_address
2020-10-01 21:50:35.514605-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 127.0.0.1
2020-10-01 21:50:35.514644-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:50:35.514681-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: server_port
2020-10-01 21:50:35.514718-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 25
2020-10-01 21:50:35.514799-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:50:35.514876-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: (end)
2020-10-01 21:50:35.515437-0700 0x72ee     Info        0x0                  1414   smtp: connection established
2020-10-01 21:50:35.515588-0700 0x72ee     Info        0x0                  1414   smtp: master_notify: status 0
2020-10-01 21:50:35.515790-0700 0x72ee     Info        0x0                  1414   smtp: deliver_request_initial: send initial status
2020-10-01 21:50:35.515918-0700 0x72ee     Info        0x0                  1414   smtp: send attr status = 0
2020-10-01 21:55:35.535124-0700 0x72ee     Info        0x0                  1414   smtp: master_notify: status 1
2020-10-01 21:55:35.535214-0700 0x72ee     Info        0x0                  1414   smtp: connection closed
2020-10-01 21:55:35.608088-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:55:35.608128-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: client_address
2020-10-01 21:55:35.608156-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 127.0.0.1
2020-10-01 21:55:35.608198-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:55:35.608260-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: client_port
2020-10-01 21:55:35.608309-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 50664
2020-10-01 21:55:35.608358-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:55:35.608407-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: server_address
2020-10-01 21:55:35.608453-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 127.0.0.1
2020-10-01 21:55:35.608525-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:55:35.608572-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: server_port
2020-10-01 21:55:35.608616-0700 0x72ee     Info        0x0                  1414   smtp: input attribute value: 25
2020-10-01 21:55:35.608661-0700 0x72ee     Info        0x0                  1414   smtp: unknown_stream: wanted attribute: (any attribute name or list terminator)
2020-10-01 21:55:35.608705-0700 0x72ee     Info        0x0                  1414   smtp: input attribute name: (end)
2020-10-01 21:55:35.608915-0700 0x72ee     Info        0x0                  1414   smtp: connection established
2020-10-01 21:55:35.608986-0700 0x72ee     Info        0x0                  1414   smtp: master_notify: status 0
2020-10-01 21:55:35.609031-0700 0x72ee     Info        0x0                  1414   smtp: deliver_request_initial: send initial status
2020-10-01 21:55:35.609075-0700 0x72ee     Info        0x0                  1414   smtp: send attr status = 0
2020-10-01 22:00:35.554329-0700 0x72ee     Info        0x0                  1414   smtp: master_notify: status 1
2020-10-01 22:00:35.554409-0700 0x72ee     Info        0x0                  1414   smtp: connection closed
2020-10-01 22:02:15.557521-0700 0x72ee     Info        0x0                  1414   smtp: idle timeout -- exiting

The lines I changed in main.cf were relayhost (switched from
smtp.gmail.com to my ISP's smtp server) and the stuff about
TLS, SASL, etc. The old one had:

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = plain
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_security_level = encrypt

The new one has:

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_tls_security_level = encrypt
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_mechanism_filter = login
smtp_sasl_security_options = 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_wrappermode = yes

But, as I said, even when I change back to the old main.cf,
fetchmail still doesn't work. (The above logs were generated
using the *old* main.cf.)

I have reloaded postfix many times and even rebooted.

Any help would be appreciated.

Thank you,
-- 
 Abe Stone
 abe...@uc...

Re: [Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

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

Chris,

I've taken this into FreeBSD, too:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249860

Regards,
Matthias

Re: [Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

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

Am 21.09.20 um 03:56 schrieb Chris James:
> Hi,
>
> I’ve been having issues (potential bug) with the polling interval using fetchmail-6.4.8
>
> I’m running FreeBSD 11.3 inside an iocage jail. The package was pulled from the ‘quarterly’ repository, and is the latest currently available from that source. I’ve checked the bug tracker and see nothing related, nor any fix in releases 6-4-9 >> 6-4-12.
>
> My mail stack is comprised of:
>
> - fetchmail
> - postfix
> - rspamd
> - dovecot
>
> The full stack has been operating for months with no issues.
>
> Fetchmail is running in daemon mode, with the config file located at:
>
> /usr/local/etc/fetchmailrc
>
> … and (redacted) contains:
>
> set daemon 180
>
> set postmaster root
> set invisible
> set no bouncemail
>
> set no spambounce
> set no softbounce # permanently delete undeliverable mail - use only when tested
>
> set logfile /var/log/fetchmail.log
> set idfile /var/mail/uid.list
>
> # server section - XXXXXXXX.net <http://xxxxxxxx.net/>
>
>   poll XXXXXXXX.net <http://xxxxxxxx.net/> aka {IP} protocol POP3 options uidl timeout 30
>
>    user “XXX...@XX... <mailto:ch...@XX...>" with pass “XXX-password-redacted-XXX" is “XXX-user-XXX" here sslproto '' fetchall nokeep norewrite preconnect "date >> /var/log/fetchmail.log”
>
> This adds a time stamp to the log file for every fetch. There are other mailboxes that pull from the same server using essentially the same config (sans the ‘preconnect’ assertion).
>
>>>> BEHAVIOUR >>> Changing the value of “set daemon” in /usr/local/etc/fetchmailrc has no effect - fetchmail continues to poll every 900 seconds, irrespective of the value set here. I have made repeated changes to the interval (300 seconds, 180 seconds, 120 seconds, 60 seconds) with service fetchmail restart issued after each change, but the polling interval remains at 900 seconds.
> However, editing the file: /usr/local/etc/rc.d/fetchmail
> … and changing 
>
> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
> : ${fetchmail_polling_interval=“900"}
>
> … to
>
> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
> : ${fetchmail_polling_interval="300"}
>
> … causes the polling interval to change to 300 seconds, irrespective of the value specified in the /usr/local/etc/fetchmailrc settings file. Thus, it appears that when the daemon starts, it correctly loads the configuration from the fetchmailrc file (since it pulls emails according to the config) but subsequently overrides the polling interval with the setting in /rc.d/fetchmail.
>
> Incidentally, I now get entries in my daily security report:
>
> Checking for packages with mismatched checksums:
> fetchmail-6.4.8: /usr/local/etc/rc.d/fetchmail
>
> … which is to be expected following the change to /usr/local/etc/rc.d/fetchmail
>
> From the (redacted, annotated) /var/log/fetchmail.log:
>
> Thu Sep 17 11:52:49 AEST 2020
> Thu Sep 17 12:07:59 AEST 2020
> Thu Sep 17 12:23:08 AEST 2020 ### polling interval every 15 minutes, despite ’set daemon 300'
> Thu Sep 17 12:38:17 AEST 2020
> Thu Sep 17 12:53:26 AEST 2020
> Thu Sep 17 13:08:35 AEST 2020
> Thu Sep 17 13:23:44 AEST 2020
> Thu Sep 17 13:38:54 AEST 2020
> fetchmail: 1 message for XXX...@XX... <mailto:ch...@XX...> at XXXXXXXX.net <http://xxxxxxxx.net/> (72268 octets).
> fetchmail: reading message XXX...@XX... <mailto:ch...@XX...>@XXXXXXXX.net:1 of 1 (72268 octets) flushed ### successful fetch
>
> fetchmail: terminated with signal 15 ### edited fetchmailrc to ‘set daemon 180’; service fetchmail restart issued
> fetchmail: starting fetchmail 6.4.8 daemon
> Thu Sep 17 13:47:20 AEST 2020
> Thu Sep 17 13:47:21 AEST 2020
> Thu Sep 17 14:02:34 AEST 2020 ### polling interval still at every 15 minutes, despite ’set daemon 180'
>
> fetchmail: terminated with signal 15 ### edited rc.d/fetchmail to ‘${fetchmail_polling_interval="300"}’; service fetchmail restart issued 
> fetchmail: starting fetchmail 6.4.8 daemon
> Thu Sep 17 14:11:18 AEST 2020
> Thu Sep 17 14:11:19 AEST 2020
> fetchmail: 1 message for XXX...@XX... <mailto:ch...@XX...> at XXXXXXXX.net <http://xxxxxxxx.net/> (80421 octets).
> fetchmail: reading message XXX...@XX... <mailto:ch...@XX...>@XXXXXXXX.net:1 of 1 (80421 octets) flushed ### successful fetch
> Thu Sep 17 14:16:36 AEST 2020
> Thu Sep 17 14:21:45 AEST 2020 ### polling interval now at every 5 minutes, after editing /usr/local/etc/rc.d/fetchmail despite ’set daemon 180'
> Thu Sep 17 14:27:02 AEST 2020
> Thu Sep 17 14:32:20 AEST 2020
>
> Let me know if you need any further information, or if I’m overlooking something obvious.

So just to make the explanation explicit and perhaps reword what Peter
Pentchev was already stating,

* the FreeBSD rcfile (rc.conf and thereabouts) indeed overrides the
daemon interval you're setting in fetchmailrc.

* the shell syntax in : ${fetchmail_polling_interval=“900"} may not be
obvious but is well-formed Bourne shell. It follows sourcing the
rc.conf* like files, and this shell line means that the
fetchmail_polling_interval variable will be set to 900 if unset, meaning
that you can add a line fetchmail_polling_interval=180 to, say,
/etc/rc.conf.local and then FreeBSD's .../etc/rc.d/fetchmail will
continue with that instead. There is usually no need to modify FreeBSD's
rc.d/* scripts.

HTH
Matthias

Re: [Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

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

Am 21.09.20 um 11:55 schrieb Peter Pentchev:
>
> That's what I refered to in my first e-mail. Apparently, the current
> version of the service file from the FreeBSD port of fetchmail does not
> depend on there being a "daemon" option in the fetchmail configuration
> file and says "we need to make sure that fetchmail runs in daemon mode,
> so we need to pass it a -d option ourselves, we cannot depend on the
> sysadmin having put that option in the fetchmail configuration file;
> but, well, the -d option requires an argument, so we must specify
> the polling interval ourselves now, so we take it from a
> fetchmail_polling_interval setting in /etc/rc.conf and, if one has not
> been specified there, we default to 900".

I haven't been following the entire discussion and won't catch up for
the next few days, so let me just pick this out.

For FreeBSD, there is extensive documentation at the top of the rcfile,
usually found in /usr/local/etc/rc.d/fetchmail, which see, and unless
overriden by one of the rc.conf* locations normally sourced,
fetchmail_polling_interval will fall back to 900 (s). If that's
undesired, set to 0 but then you may want to set up a cron job or
similar, or only poll manually.

So bottom line, fetchmail_polling_interval=300 in /etc/rc.conf or
thereabouts (to see the locations: man 5 rc.conf) can modify the
interval, 0 turns it off. The .../rc.d/fetchmail file is still useful to
read because the documentation and defaults are nicely readable.

HTH for now.

Re: [Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

[Peter P. <ro...@ri...>]

On Mon, Sep 21, 2020 at 06:57:52PM +1000, Chris James wrote:
> Hi Peter,
> 
> Apologies if it went directly to you ... I just “replied” via iPhone mail. Further comment below ...

OK, bringing the list back in CC. Further replies inline (top-posting
considered harmful anyway :)

> > On 21 Sep 2020, at 17:37, Peter Pentchev <ro...@ri...> wrote:
> > 
> > On Mon, Sep 21, 2020 at 05:00:28PM +1000, Chris James wrote:
> >> 
> >>>> On 21 Sep 2020, at 16:01, Peter Pentchev <ro...@ri...> wrote:
> >>> 
> >>> On Mon, Sep 21, 2020 at 11:56:43AM +1000, Chris James wrote:
> >>>> Hi,
> >>>> 
> >>>> I’ve been having issues (potential bug) with the polling interval using fetchmail-6.4.8
> >>>> 
> >>>> I’m running FreeBSD 11.3 inside an iocage jail. The package was pulled from the ‘quarterly’ repository, and is the latest currently available from that source. I’ve checked the bug tracker and see nothing related, nor any fix in releases 6-4-9 >> 6-4-12.
> >>>> 
> >>>> My mail stack is comprised of:
> >>>> 
> >>>> - fetchmail
> >>>> - postfix
> >>>> - rspamd
> >>>> - dovecot
> >>>> 
> >>>> The full stack has been operating for months with no issues.
> >>>> 
> >>>> Fetchmail is running in daemon mode, with the config file located at:
> >>>> 
> >>>> /usr/local/etc/fetchmailrc
> >>>> 
> >>>> … and (redacted) contains:
> >>>> 
> >>>> set daemon 180
> >>> [snip]
> >>>> 
> >>>> This adds a time stamp to the log file for every fetch. There are other mailboxes that pull from the same server using essentially the same config (sans the ‘preconnect’ assertion).
> >>>> 
> >>>>>>> BEHAVIOUR >>> Changing the value of “set daemon” in /usr/local/etc/fetchmailrc has no effect - fetchmail continues to poll every 900 seconds, irrespective of the value set here. I have made repeated changes to the interval (300 seconds, 180 seconds, 120 seconds, 60 seconds) with service fetchmail restart issued after each change, but the polling interval remains at 900 seconds.
> >>>> 
> >>>> However, editing the file: /usr/local/etc/rc.d/fetchmail
> >>>> … and changing 
> >>>> 
> >>>> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
> >>>> ${fetchmail_polling_interval=“900"}
> >>>> 
> >>>> … to
> >>>> 
> >>>> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
> >>>> : ${fetchmail_polling_interval="300"}
> >>>> 
> >>>> … causes the polling interval to change to 300 seconds, irrespective of the value specified in the /usr/local/etc/fetchmailrc settings file. Thus, it appears that when the daemon starts, it correctly loads the configuration from the fetchmailrc file (since it pulls emails according to the config) but subsequently overrides the polling interval with the setting in /rc.d/fetchmail.
> >>> 
> >>> The fetchmail manual page states that command-line options override
> >>> configuration file defaults. The startup script for the fetchmail
> >>> service must pass -d to make sure that fetchmail starts in daemon mode,
> >>> and since -d requires an argument, the startup script must pass one -
> >>> and it uses the value from its own config file. Thus, whatever you put
> >>> in the fetchmail config file will be silently ignored
> >>> G'luck,
> >>> Peter
> >> 
> >> Hi Peter,
> >> 
> >> The FreeBSD manual implies otherwise. Given that fetchmail is started at boot without command line options (fetchmail_enable=“YES” in /etc/rc.conf), it should refer to the daemon poll setting in the fetchmailrc file ... yet that seems to be overridden by a hard-coded default elsewhere.
> >> 
> >> https://www.freebsd.org/cgi/man.cgi?fetchmail
> >> Starting the daemon mode
> >> There are several ways to make fetchmail work in    daemon mode. ... 
> >> It is also possible to set a polling interval in your fetchmailrc file by saying 'set daemon <interval>', where <interval> is an integer number of seconds. If you do this, fetchmail will always start in daemon mode unless you override it with the command-line option --daemon 0 or -d0.
> > 
> > Hi,
> > 
> > You are quoting the manual page for the fetchmail program, not the
> > fetchmail service. The same manual page ought to also have a sentence
> > saying something like:
> > 
> >  Command-line options override ~/.fetchmailrc declarations.
> > 
> Understood. But without command line declarations, it should pull from the fetchmailrc config, yes? 

That's what I refered to in my first e-mail. Apparently, the current
version of the service file from the FreeBSD port of fetchmail does not
depend on there being a "daemon" option in the fetchmail configuration
file and says "we need to make sure that fetchmail runs in daemon mode,
so we need to pass it a -d option ourselves, we cannot depend on the
sysadmin having put that option in the fetchmail configuration file;
but, well, the -d option requires an argument, so we must specify
the polling interval ourselves now, so we take it from a
fetchmail_polling_interval setting in /etc/rc.conf and, if one has not
been specified there, we default to 900".

The fetchmail service (that comes from the FreeBSD port) passes the -d
option to the fetchmail program when starting it.

> > What I am saying is that the FreeBSD port of fetchmail installs the
> > fetchmail program and the fetchmail manual page, but it also installs a
> > FreeBSD-specific rc service that starts fetchmail at boot time if so
> > configured. This service is started by the file that you edit:
> > /usr/local/etc/rc.d/fetchmail - it is a shell script that reads its own
> > configuration file (or the global configuration settings in
> > /etc/rc.conf) and then, if enabled, starts fetchmail in daemon mode
> > using the options from the service configuration file, not the fetchmail
> > one.
> > So the line that you changed, the one containing 900 that you changed to
> > 300 - it actually checks whether a "fetchmail_polling_interval" variable
> > has been defined somewhere. I think that if you define
> > fetchmail_polling_interval in /etc/rc.conf, the service will pick it up
> > and use it instead of its default of 900, so I think that - specifically
> > for the FreeBSD port of fetchmail - you should set the polling interval
> > in /etc/rc.conf and not in the fetchmail configuration file.
> > 
> I’m still ... puzzled, I guess - since /usr/local/etc/rc.d/fetchmail is essentially not “user-editable” - by which I mean that next time there’s a pkg upgrade any change will be overwritten - logically any user specified options should be in the fetchmailrc file ... and they are with respect to every other config except - from what you’re saying - the polling interval that would require a separate environment variable added to rc.conf?

The FreeBSD service files are configured via /etc/rc.conf. Any options
that need to control the service behavior *before* it starts the program
that it needs to start, or that control any arguments that the service
needs to pass to the program, should be placed in /etc/rc.conf (or,
well, in a service-specific configuration file; see
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcd.html
and also
https://www.freebsd.org/cgi/man.cgi?query=rc.conf&sektion=5&manpath=freebsd-release-ports
for more information).

So since the FreeBSD service now wants to pass the -d option, it needs
to provide an argument to that - and that argument should be taken from
the service configuration.

> I will add that in previous versions of fetchmail (likely from a year or two ago) I’ve been able to exactly what I’d expect - adjust fetchmailrc with “set daemon XXX” and achieve the polling interval I desire.

Hmm, that's quite strange, since the fetchmail_polling_interval handling
seems to have been part of the service script in the FreeBSD for at
least the past ten years... Unfortunately, I myself have not used
FreeBSD for more than ten years now, so all the information that I am
giving to you now is from looking at the port's source files at
the FreeBSD SVNWeb site; I have not had actual practical experience with
the FreeBSD port of fetchmail for, well, more than ten years now.

It seems that Matthias Andree himself helps maintain the FreeBSD port;
maybe he should be able to clarify this part.

> > Hope that helps, and sorry if my first message was a bit brief.
> > 
> > BTW is there a reason why you only replied to me personally and not to
> > the whole list? (if it was by accident, and if you decide to send
> > a follow-up message to the list, you may quote this message as you wish)

(you replied to this part in the top-posted sentence above)

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

[Peter P. <ro...@ri...>]

On Mon, Sep 21, 2020 at 11:56:43AM +1000, Chris James wrote:
> Hi,
> 
> I’ve been having issues (potential bug) with the polling interval using fetchmail-6.4.8
> 
> I’m running FreeBSD 11.3 inside an iocage jail. The package was pulled from the ‘quarterly’ repository, and is the latest currently available from that source. I’ve checked the bug tracker and see nothing related, nor any fix in releases 6-4-9 >> 6-4-12.
> 
> My mail stack is comprised of:
> 
> - fetchmail
> - postfix
> - rspamd
> - dovecot
> 
> The full stack has been operating for months with no issues.
> 
> Fetchmail is running in daemon mode, with the config file located at:
> 
> /usr/local/etc/fetchmailrc
> 
> … and (redacted) contains:
> 
> set daemon 180
[snip]
> 
> This adds a time stamp to the log file for every fetch. There are other mailboxes that pull from the same server using essentially the same config (sans the ‘preconnect’ assertion).
> 
> >>> BEHAVIOUR >>> Changing the value of “set daemon” in /usr/local/etc/fetchmailrc has no effect - fetchmail continues to poll every 900 seconds, irrespective of the value set here. I have made repeated changes to the interval (300 seconds, 180 seconds, 120 seconds, 60 seconds) with service fetchmail restart issued after each change, but the polling interval remains at 900 seconds.
> 
> However, editing the file: /usr/local/etc/rc.d/fetchmail
> … and changing 
> 
> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
>  ${fetchmail_polling_interval=“900"}
> 
> … to
> 
> : ${fetchmail_config="/usr/local/etc/fetchmailrc"}
> : ${fetchmail_polling_interval="300"}
> 
> … causes the polling interval to change to 300 seconds, irrespective of the value specified in the /usr/local/etc/fetchmailrc settings file. Thus, it appears that when the daemon starts, it correctly loads the configuration from the fetchmailrc file (since it pulls emails according to the config) but subsequently overrides the polling interval with the setting in /rc.d/fetchmail.

The fetchmail manual page states that command-line options override
configuration file defaults. The startup script for the fetchmail
service must pass -d to make sure that fetchmail starts in daemon mode,
and since -d requires an argument, the startup script must pass one -
and it uses the value from its own config file. Thus, whatever you put
in the fetchmail config file will be silently ignored.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Fetchmail-users] Polling interval: fetchmailrc 'set daemon 180' not being honoured

[Chris J. <mrc...@gm...>]

Hi,

I’ve been having issues (potential bug) with the polling interval using fetchmail-6.4.8

I’m running FreeBSD 11.3 inside an iocage jail. The package was pulled from the ‘quarterly’ repository, and is the latest currently available from that source. I’ve checked the bug tracker and see nothing related, nor any fix in releases 6-4-9 >> 6-4-12.

My mail stack is comprised of:

- fetchmail
- postfix
- rspamd
- dovecot

The full stack has been operating for months with no issues.

Fetchmail is running in daemon mode, with the config file located at:

/usr/local/etc/fetchmailrc

… and (redacted) contains:

set daemon 180

set postmaster root
set invisible
set no bouncemail

set no spambounce
set no softbounce # permanently delete undeliverable mail - use only when tested

set logfile /var/log/fetchmail.log
set idfile /var/mail/uid.list

# server section - XXXXXXXX.net <http://xxxxxxxx.net/>

  poll XXXXXXXX.net <http://xxxxxxxx.net/> aka {IP} protocol POP3 options uidl timeout 30

   user “XXX...@XX... <mailto:ch...@XX...>" with pass “XXX-password-redacted-XXX" is “XXX-user-XXX" here sslproto '' fetchall nokeep norewrite preconnect "date >> /var/log/fetchmail.log”

This adds a time stamp to the log file for every fetch. There are other mailboxes that pull from the same server using essentially the same config (sans the ‘preconnect’ assertion).

>>> BEHAVIOUR >>> Changing the value of “set daemon” in /usr/local/etc/fetchmailrc has no effect - fetchmail continues to poll every 900 seconds, irrespective of the value set here. I have made repeated changes to the interval (300 seconds, 180 seconds, 120 seconds, 60 seconds) with service fetchmail restart issued after each change, but the polling interval remains at 900 seconds.

However, editing the file: /usr/local/etc/rc.d/fetchmail
… and changing 

: ${fetchmail_config="/usr/local/etc/fetchmailrc"}
 ${fetchmail_polling_interval=“900"}

… to

: ${fetchmail_config="/usr/local/etc/fetchmailrc"}
: ${fetchmail_polling_interval="300"}

… causes the polling interval to change to 300 seconds, irrespective of the value specified in the /usr/local/etc/fetchmailrc settings file. Thus, it appears that when the daemon starts, it correctly loads the configuration from the fetchmailrc file (since it pulls emails according to the config) but subsequently overrides the polling interval with the setting in /rc.d/fetchmail.

Incidentally, I now get entries in my daily security report:

Checking for packages with mismatched checksums:
fetchmail-6.4.8: /usr/local/etc/rc.d/fetchmail

… which is to be expected following the change to /usr/local/etc/rc.d/fetchmail

From the (redacted, annotated) /var/log/fetchmail.log:

Thu Sep 17 11:52:49 AEST 2020
Thu Sep 17 12:07:59 AEST 2020
Thu Sep 17 12:23:08 AEST 2020 ### polling interval every 15 minutes, despite ’set daemon 300'
Thu Sep 17 12:38:17 AEST 2020
Thu Sep 17 12:53:26 AEST 2020
Thu Sep 17 13:08:35 AEST 2020
Thu Sep 17 13:23:44 AEST 2020
Thu Sep 17 13:38:54 AEST 2020
fetchmail: 1 message for XXX...@XX... <mailto:ch...@XX...> at XXXXXXXX.net <http://xxxxxxxx.net/> (72268 octets).
fetchmail: reading message XXX...@XX... <mailto:ch...@XX...>@XXXXXXXX.net:1 of 1 (72268 octets) flushed ### successful fetch

fetchmail: terminated with signal 15 ### edited fetchmailrc to ‘set daemon 180’; service fetchmail restart issued
fetchmail: starting fetchmail 6.4.8 daemon
Thu Sep 17 13:47:20 AEST 2020
Thu Sep 17 13:47:21 AEST 2020
Thu Sep 17 14:02:34 AEST 2020 ### polling interval still at every 15 minutes, despite ’set daemon 180'

fetchmail: terminated with signal 15 ### edited rc.d/fetchmail to ‘${fetchmail_polling_interval="300"}’; service fetchmail restart issued 
fetchmail: starting fetchmail 6.4.8 daemon
Thu Sep 17 14:11:18 AEST 2020
Thu Sep 17 14:11:19 AEST 2020
fetchmail: 1 message for XXX...@XX... <mailto:ch...@XX...> at XXXXXXXX.net <http://xxxxxxxx.net/> (80421 octets).
fetchmail: reading message XXX...@XX... <mailto:ch...@XX...>@XXXXXXXX.net:1 of 1 (80421 octets) flushed ### successful fetch
Thu Sep 17 14:16:36 AEST 2020
Thu Sep 17 14:21:45 AEST 2020 ### polling interval now at every 5 minutes, after editing /usr/local/etc/rc.d/fetchmail despite ’set daemon 180'
Thu Sep 17 14:27:02 AEST 2020
Thu Sep 17 14:32:20 AEST 2020

Let me know if you need any further information, or if I’m overlooking something obvious.

Many thanks for your attention.

CJ

Re: [Fetchmail-users] Adding timestamp to maillog

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

Am 12.09.20 um 01:34 schrieb grarpamp:
>> * fetchmail, with --logfile, now logs time stamps into the file, in
>> localtime
>>   and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized
>> through
>>   the environment variables LC_TIME (or LC_ALL) and TZ.
> Applications, especially logging functions aka: not human
> GUI apps... should generally at least first consider using
> the unambiguous, universal, programmatic, parseable,
> sortable, human readable, locality independent, international
> exchange friendly, timezone clear, international standard
> iso8601 format timestamps. The standard was created for that.
> strftime(3) format can then be easily modified by user
> to whatever their nonstandard local or personal preference
> or legacy systems need by a configuration setting or
> environment variable, including any formats beyond
> those in LC_TIME.

Ah well. What a nuisance. There is always someone you haven't pleased.

If you print ISO8601 format, you see people nag about the embedded T,
about the unusual ordering and whatnot, someone will want the time zone
offset printed, the next person won't. We've had that story with daemon
mode and "sleeping at" and "awakened at". Some people want that in the
logs, others don't. As if there were no grep, no logrotate, no nothing.

Add free-form customization and people will complain that first setup is
hard...

If you don't like the traditional format, then patch the strftime().
That's one reason what you have the source code, you know...

In the end if you make it customizable and documentation takes up an
order of magnitude more room than the actual code... Option parser,
report back, configuration plausibility checking, code to parse, man
page entry and it all boils down to keep people dependent.

I don't really know why we need logfile with all the related management
code when we have standard I/O and syslog options already. It's been
there when we took over post-6.2.5 code ages ago, and that's why it's
still in 6.x.y. Perhaps I should put --logfile it on the deprecated
option list for 7.x to avoid any further discussion.

Re: [Fetchmail-users] Adding timestamp to maillog

[grarpamp <gra...@gm...>]

On 9/12/20, Ralph Corderoy <ra...@in...> wrote:
>> https://en.wikipedia.org/wiki/ISO_8601
>> 2020-09-11T23:12:34+00:00
>
> It's disliked because the ‘T’ makes the start of the time hard to grok
> by eyeball.

In the end it's a log, not an app GUI, and as with
most logs one that's hard to grok by either eye
or machine. Is there a project to prettyprint
and GUI-ify it for those who don't grok spaces
or T's or consider reasons for iso8601?

> Using the environment allows the user to control the format, including
> producing ISO 8601 if preferred.
>     $ date
>     2020-09-12 10:55:15 +0100 Sat

As users may wish to do either, how should they
set their environment to produce such iso8601
and "personally-ized" outputs respectively?
ie: What is your LC_TIME?

You could add / refer it into man page.

Re: [Fetchmail-users] Adding timestamp to maillog

[Ralph C. <ra...@in...>]

Hi grarpamp,

> > It will be localized through the environment variables LC_TIME (or
> > LC_ALL) and TZ.
>
> https://en.wikipedia.org/wiki/ISO_8601
> 2020-09-11T23:12:34+00:00

It's disliked because the ‘T’ makes the start of the time hard to grok
by eyeball.

Using the environment allows the user to control the format, including
producing ISO 8601 if preferred.

Personally,

    $ date
    2020-09-12 10:55:15 +0100 Sat

-- 
Cheers, Ralph.

Re: [Fetchmail-users] Adding timestamp to maillog

[grarpamp <gra...@gm...>]

> * fetchmail, with --logfile, now logs time stamps into the file, in
> localtime
>   and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized
> through
>   the environment variables LC_TIME (or LC_ALL) and TZ.

Applications, especially logging functions aka: not human
GUI apps... should generally at least first consider using
the unambiguous, universal, programmatic, parseable,
sortable, human readable, locality independent, international
exchange friendly, timezone clear, international standard
iso8601 format timestamps. The standard was created for that.
strftime(3) format can then be easily modified by user
to whatever their nonstandard local or personal preference
or legacy systems need by a configuration setting or
environment variable, including any formats beyond
those in LC_TIME.

https://en.wikipedia.org/wiki/ISO_8601

2020-09-11T23:12:34+00:00

Re: [Fetchmail-users] Adding timestamp to maillog

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

On 9/10/2020 4:43 PM, James Moe via Fetchmail-users wrote:
> On 9/10/20 10:36 AM, Dennis Putnam wrote:
>
>> Has anyone figured out how to add a timestamp on the fetchmail log
>> messages to the maillog? TIA
>>
>   Not that I ever found.
>   My configuration file has these entries as a workaround:
>
> set logfile "/path/to/fetchmail.log"
> poll example.com interval 1
>   protocol imap username "account_name_of_interest" password "secret"
>   preconnect "echo `date +%Y-%m-%dT%H:%M:%S` <account_name_of_interest> >>
> /path/to/fetchmail.log
>   ... other stuff ...
>
>   It does result in an entry for every time fetchmail connects to a server to
> check for mail even if no mail is available.
>
Thanks for everyone that replied. I was not aware of  'preconnect'. This
is the solution I prefer.

Re: [Fetchmail-users] Adding timestamp to maillog

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

Am 11.09.20 um 02:19 schrieb Carlos E. R.:
> On 10/09/2020 19.36, Dennis Putnam wrote:
>> Has anyone figured out how to add a timestamp on the fetchmail log
>> messages to the maillog? TIA
>
> Yes, use syslog. 

Syslog is an option we've always had,
I have also received and merged a contribution from Holger Hoffstätte to
add timestamps to the log.

I have merged it onto the legacy_6x branch in Git, it's been part of the
6.5.0-beta1 preview release (snapshot) in July 2020, see its NEWS file.

* fetchmail, with --logfile, now logs time stamps into the file, in
localtime
  and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized
through
  the environment variables LC_TIME (or LC_ALL) and TZ.

Download: https://sourceforge.net/projects/fetchmail/files/branch_6.5/
(you may need lzip to unpack, https://www.nongnu.org/lzip/lzip.html )

https://gitlab.com/fetchmail/fetchmail/-/merge_requests/21
https://gitlab.com/fetchmail/fetchmail/-/merge_requests/21/diffs

https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_6x
https://sourceforge.net/p/fetchmail/git/ci/legacy_6x/tree/

Re: [Fetchmail-users] Adding timestamp to maillog

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

On 10/09/2020 19.36, Dennis Putnam wrote:
> Has anyone figured out how to add a timestamp on the fetchmail log
> messages to the maillog? TIA

Yes, use syslog.

-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Adding timestamp to maillog

[Peter P. <ro...@ri...>]

On Thu, Sep 10, 2020 at 01:43:36PM -0700, James Moe via Fetchmail-users wrote:
> On 9/10/20 10:36 AM, Dennis Putnam wrote:
> 
> > Has anyone figured out how to add a timestamp on the fetchmail log
> > messages to the maillog? TIA
> >
>   Not that I ever found.
>   My configuration file has these entries as a workaround:
> 
> set logfile "/path/to/fetchmail.log"
> poll example.com interval 1
>   protocol imap username "account_name_of_interest" password "secret"
>   preconnect "echo `date +%Y-%m-%dT%H:%M:%S` <account_name_of_interest> >>
> /path/to/fetchmail.log
>   ... other stuff ...
> 
>   It does result in an entry for every time fetchmail connects to a server to
> check for mail even if no mail is available.

Huh... I guess I never thought I'd need that, since I've always run
fetchmail in daemon mode with the -v option, and (at least for a long
time, maybe always) it outputs lines like:

fetchmail: 6.4.8 querying mail.example.com (protocol IMAP) at 11.09.2020 (пт)  0:46:26: poll started
...
fetchmail: 6.4.8 querying mail.example.com (protocol IMAP) at 11.09.2020 (пт)  0:48:26: poll completed
fetchmail: sleeping at 11.09.2020 (пт)  0:48:26 for 120 seconds

(the "пт" part is the Bulgarian abbreviation for "Friday")

Other than that, I'd suggest somehow running a combination of fetchmail
and one of the logging tools like Prof. Bernstein's "multilog", but that
would require a reliable mechanism of starting both processes and making
sure both of them keep running, and there are not so many ways of doing
that if not using a service supervision framework like daemontools,
runit, s6, or similar. Of course, one could always write a simple Perl /
Python / Ruby / Rust / maybe even C program that starts two processes
and kills them both if anything bad happens, but that's not what I'd
consider an easy general solution.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] Adding timestamp to maillog

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

On 9/10/20 10:36 AM, Dennis Putnam wrote:

> Has anyone figured out how to add a timestamp on the fetchmail log
> messages to the maillog? TIA
>
  Not that I ever found.
  My configuration file has these entries as a workaround:

set logfile "/path/to/fetchmail.log"
poll example.com interval 1
  protocol imap username "account_name_of_interest" password "secret"
  preconnect "echo `date +%Y-%m-%dT%H:%M:%S` <account_name_of_interest> >>
/path/to/fetchmail.log
  ... other stuff ...

  It does result in an entry for every time fetchmail connects to a server to
check for mail even if no mail is available.

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

[Fetchmail-users] Adding timestamp to maillog

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

Has anyone figured out how to add a timestamp on the fetchmail log
messages to the maillog? TIA

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.12 is now available (regression fixes + README, + new translation for Romanian by Florentina Mușat)

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

Greetings,

The 6.4.12 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

Reviewing remarks of the FreeBSD packager WRT 6.4.11, I have found a bug in
the makerelease.pl script that caused corruption the README file. It
did contain a NEWS fragment in the past few releases instead of
the README file from the repository. (FreeBSD Bugzilla #249009 comment #2)

This bug might have affected release tarballs back to 6.4.2
(failure inducing change c82cca7831bd8e9bc65f860b38a847bb5056b5f6).

6.4.12 was built with a fixed script and now has the right README file.

Sorry about the quick release sequence.

== NOTE ==
Fetchmail 6.4.x does not receive functional changes, and new
6.4.x are not planned, except if regressions, critical fixes, or new
translations or important documentation fixes appear and 6.5.0 is too far out.

Fetchmail 6.4.x is the last branch that will tolerate OpenSSL 1.0.2 and C89
compilers, and support Python 2.7.x (for newer x) for fetchmailconf.

== EXCURSION ---------
The direction for the near future is to do some bugfixing and possibly minor
features on the Git branch 'legacy_6x', for now called 6.5.0.dev*, it is a
branch that will require newer operating systems, toolchains, library, for
instance, OpenSSL 1.1.1 with TLSv1.3 support, C99 (for long long support) or
possibly C11 (TBD) and possibly newer IEEE Std 1003.1 compliance.
== END EXCURSION -----


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

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

SHA256 hash values:
SHA256(fetchmail-6.4.12.tar.lz)= 9bf4d6cd8ff3d0b3d48fb639645d674ffac3d9d9337cfb8bda35e14f67431758
SHA256(fetchmail-6.4.12.tar.xz)= 2b84e0971dbf683ec7edd313f9218adbc7dc51c1de9825b3b549bf619c1a4887

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.12 (released 2020-09-04, 27596 LoC):

# BUG FIXES:
* The README file is now the one from Git again. The makerelease.pl script
  used to roll and upload the tarball sometimes clobbered the README file and
  replaced its contents by a part of the NEWS file.

# KNOWN BUGS AND WORKAROUNDS
  (This section floats upwards through the NEWS file so it stays with the
  current release information)
* Fetchmail does not handle messages without Message-ID header well
  (See sourceforge.net bug #780933)
* Fetchmail currently uses 31-bit signed integers in several places
  where unsigned and/or wider types should have been used, for instance,
  for mailbox sizes, and misreports sizes of 2 GibiB and beyond. 
  Fixing this requires C89 compatibility to be relinquished.
* BSMTP is mostly untested and errors can cause corrupt output.
* Fetchmail does not track pending deletes across crashes.
* The command line interface is sometimes a bit stubborn, for instance,
  fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
  no or no global IPv6 addresses are configured.
  (No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
  messages. This will not be fixed, because the maintainer has no Kerberos 5
  server to test against. Use GSSAPI.

---------------------------------------------------------------------------------
fetchmail-6.4.11 (released 2020-08-28, 27596 LoC):

# REGRESSION FIX:
* configure: fetchmail 6.4.9 and 6.4.10 would miss checking for TLS v1.2 and
  TLS v1.3 support if AC_LIB_LINKFLAGS came up with something such as
  /path/to/libssl.so, rather than -lssl. (For instance on FreeBSD)

---------------------------------------------------------------------------------
fetchmail-6.4.10 (released 2020-08-27, 27596 LoC):

# REGRESSION FIX:
* configure: fetchmail 6.4.9's configure was unable to pick up OpenSSL
  if it wasn't announced by pkg-config, for instance, on FreeBSD.

---------------------------------------------------------------------------------
fetchmail-6.4.9: (not announced by e-mail, withdrawn)

## DOCUMENTATION UPDATE:
* manpage: mention that the SSL/TLS certificate fingerprint uses an MD5 hash.

## CHANGES:
* configure: try to use AC_LIB_LINKFLAGS to obtain proper link flags for 
  libcrypto and libssl if pkg-config failed.
  This is an attempt to fix borderline issues when users building on systems 
  with obsolete OpenSSL try to use a local newer OpenSSL from a separate 
  directory.

## NEW TRANSLATION, with thanks to the translator:
* ro:    Florentina Mușat [Romanian]

---------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.11 is now available (regression fixes, + new translation for Romanian by Florentina Mușat)

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

Greetings,

The 6.4.11 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

== NOTE ==
I intend this to be the last 6.4.x version with functional changes, and new
6.4.x are not planned, except if regressions, critical fixes, or new
translations or important documentation fixes appear and 6.5.0 is too far out.

Fetchmail 6.4.x is the last branch that will tolerate OpenSSL 1.0.2 and C89
compilers, and support Python 2.7.x (for newer x) for fetchmailconf.

== EXCURSION ---------
The direction for the near future is to do some bugfixing and possibly minor
features on the Git branch 'legacy_6x', for now called 6.5.0.dev*, it is a
branch that will require newer operating systems, toolchains, library, for
instance, OpenSSL 1.1.1 with TLSv1.3 support, C99 (for long long support) or
possibly C11 (TBD) and possibly newer IEEE Std 1003.1 compliance.
== END EXCURSION -----


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

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

SHA256 hash values:
SHA256(fetchmail-6.4.11.tar.lz)= cc7ca0899e93b77a2c248dd2f2ac84d5451b73a393b1d601699bcad8ef5e79cb
SHA256(fetchmail-6.4.11.tar.xz)= 3e481dd869907c3786b486fd8a7bb4b24e60889b1ac449b786ec0a059b39e29c

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.11 (released 2020-08-28, 27596 LoC):

# REGRESSION FIX:
* configure: fetchmail 6.4.9 and 6.4.10 would miss checking for TLS v1.2 and
  TLS v1.3 support if AC_LIB_LINKFLAGS came up with something such as
  /path/to/libssl.so, rather than -lssl. (For instance on FreeBSD)

---------------------------------------------------------------------------------
fetchmail-6.4.10 (released 2020-08-27, 27596 LoC):

# REGRESSION FIX:
* configure: fetchmail 6.4.9's configure was unable to pick up OpenSSL
  if it wasn't announced by pkg-config, for instance, on FreeBSD.

---------------------------------------------------------------------------------
fetchmail-6.4.9: (not announced by e-mail, withdrawn)

## DOCUMENTATION UPDATE:
* manpage: mention that the SSL/TLS certificate fingerprint uses an MD5 hash.

## CHANGES:
* configure: try to use AC_LIB_LINKFLAGS to obtain proper link flags for 
  libcrypto and libssl if pkg-config failed.
  This is an attempt to fix borderline issues when users building on systems 
  with obsolete OpenSSL try to use a local newer OpenSSL from a separate 
  directory.

## NEW TRANSLATION, with thanks to the translator:
* ro:    Florentina Mușat [Romanian]

---------------------------------------------------------------------------------

Happy fetches,
Matthias

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.10 is now available (new translation for Romanian, courtesy of Florentina Mușat)

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

Greetings,

The 6.4.10 release of fetchmail is now available at the usual locations,
including <https://downloads.sourceforge.net/project/fetchmail/branch_6.4/>.

== NOTE ==
I intend this to be the last 6.4.x version with functional changes, and new
6.4.x are not planned, except if regressions, critical fixes, or new
translations or important documentation fixes appear and 6.5.0 is too far out.

Fetchmail 6.4.x is the last branch that will tolerate OpenSSL 1.0.2 and C89
compilers, and support Python 2.7.x (for newer x) for fetchmailconf.

== EXCURSION ---------
The direction for the near future is to do some bugfixing and possibly minor
features on the Git branch 'legacy_6x', for now called 6.5.0.dev*, it is a
branch that will require newer operating systems, toolchains, library, for
instance, OpenSSL 1.1.1 with TLSv1.3 support, C99 (for long long support) or
possibly C11 (TBD) and possibly newer IEEE Std 1003.1 compliance.
== END EXCURSION -----


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

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

SHA256 hash values:
SHA256(fetchmail-6.4.10.tar.lz)= 702d815684c1899b586e6d2549b8fcc23c372ae57537e15cd81e5c2ff5059c37
SHA256(fetchmail-6.4.10.tar.xz)= dbbefd43b8a8ac0517b817fdb63629d321e53fd63143b92d117bbd7d91d7b25e

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.10 (released 2020-08-27, 27596 LoC):

# REGRESSION FIX:
* configure: fetchmail 6.4.9's configure was unable to pick up OpenSSL
  if it wasn't announced by pkg-config, for instance, on FreeBSD.

---------------------------------------------------------------------------------
fetchmail-6.4.9: (not announced by e-mail, withdrawn)

## DOCUMENTATION UPDATE:
* manpage: mention that the SSL/TLS certificate fingerprint uses an MD5 hash.

## CHANGES:
* configure: try to use AC_LIB_LINKFLAGS to obtain proper link flags for 
  libcrypto and libssl if pkg-config failed.
  This is an attempt to fix borderline issues when users building on systems 
  with obsolete OpenSSL try to use a local newer OpenSSL from a separate 
  directory.

## NEW TRANSLATION, with thanks to the translator:
* ro:    Florentina Mușat [Romanian]

--------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] UID lists

[Bob T. <rdt...@gm...>]

I've re-started sendmail on my system and now all is well.

Bob T.


On Wed, Aug 12, 2020 at 3:36 PM Matthias Andree <mat...@gm...>
wrote:

> Am 12.08.20 um 20:08 schrieb Bob Tennent:
> > All I wanted was an explanation of what
> >
> >   fetchmail: Old UID list from innovate.cs.queensu.ca:
> >    <empty>
> >
> >   fetchmail: Scratch list of UIDs:
> >    <empty>
>
> Bob,
>
> this just means that there haven't been UIDs stored from previous
> fetches (default file: ~/.fetchids), which is debug information and
> "normal" for IMAP setups.
>
> For fetchmail 6.4.x and older and with IMAP, those <empty> are expected
> and will not change, these fetchmail versions only store UIDs when
> fetching from POP3 servers that support the UIDL command and you keep
> messages on the server.
>
> But you were writing "fetchmail isn't working". This is not supported by
> the log you have posted - you've aborted the run before fetchmail could
> download and forward the first message.
>
> So currently I am confused as to whether your setup around fetchmail is
> working, or it is not and you want further support.
>
> Regards,
> Matthias
>
>
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users
>

Re: [Fetchmail-users] UID lists

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

Am 12.08.20 um 22:12 schrieb Bob Tennent:
>
>
> On Wed, Aug 12, 2020 at 3:36 PM Matthias Andree
> <mat...@gm... <mailto:mat...@gm...>> wrote:
>
>     Am 12.08.20 um 20:08 schrieb Bob Tennent:
>     > All I wanted was an explanation of what
>     >
>     >   fetchmail: Old UID list from innovate.cs.queensu.ca
>     <http://innovate.cs.queensu.ca>:
>     >    <empty>
>     >
>     >   fetchmail: Scratch list of UIDs:
>     >    <empty>
>
> So the UID lists is a red herring.   
>
>
>     But you were writing "fetchmail isn't working". This is not
>     supported by
>     the log you have posted - you've aborted the run before fetchmail
>     could
>     download and forward the first message.
>
>     So currently I am confused as to whether your setup around
>     fetchmail is
>     working, or it is not and you want further support.
>
> As far as I can tell fetchmail /is/ working but the mail is
> disappearing on my system.  Here's what I get from calling systemctl
> status sendmail:
Is it disappearing? It looks more like being rejected, and fetchmail
should retry later after temporary failures.
>
>       sendmail.service - Sendmail Mail Transport Agent
>        Loaded: loaded (/usr/lib/systemd/system/sendmail.service;
>     enabled; vendor preset: disabled)
>        Active: active (running) since Mon 2020-08-10 15:28:07 EDT; 2
>     days ago
>      Main PID: 30452 (sendmail)
>         Tasks: 1
>        CGroup: /system.slice/sendmail.service
>                `-30452 sendmail: accepting connections
>
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTD007339: ruleset=check_mail,
>     arg1=<rdt...@gm... <mailto:rdt...@gm...>>,
>     relay=localhost [127.0.0.1], reject=451 4.1.8 Domain of sender
>     address rdt...@gm... <mailto:rdt...@gm...> does not
>     resolve
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTD007339: from=<rdt...@gm...
>     <mailto:rdt...@gm...>>, size=11081, class=0, nrcpts=0,
>     proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTE007339: ruleset=check_mail,
>     arg1=<texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, relay=localhost [127.0.0.1],
>     reject=451 4.1.8 Domain of sender address
>     texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...> does not resolve
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTE007339:
>     from=<texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, size=4702, class=0, nrcpts=0,
>     proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTF007339: ruleset=check_mail,
>     arg1=<pe...@ct... <mailto:pe...@ct...>>, relay=localhost
>     [127.0.0.1], reject=451 4.1.8 Domain of sender address
>     pe...@ct... <mailto:pe...@ct...> does not resolve
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTF007339: from=<pe...@ct...
>     <mailto:pe...@ct...>>, size=2921, class=0, nrcpts=0,
>     bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=localhost
>     [127.0.0.1]
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTG007339: ruleset=check_mail,
>     arg1=<texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, relay=localhost [127.0.0.1],
>     reject=451 4.1.8 Domain of sender address
>     texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...> does not resolve
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTG007339:
>     from=<texhax-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, size=3971, class=0, nrcpts=0,
>     proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTH007339: ruleset=check_mail,
>     arg1=<tex-live-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, relay=localhost [127.0.0.1],
>     reject=451 4.1.8 Domain of sender address
>     tex-live-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...> does not resolve
>     Aug 12 15:57:49 jimmy.tennent.ca <http://jimmy.tennent.ca>
>     sendmail[7339]: 07CJvnTH007339:
>     from=<tex-live-bounces+rdt=cs....@tu...
>     <mailto:cs....@tu...>>, size=8916, class=0, nrcpts=0,
>     bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
>
>
> I don't understand the "Domain of sender address ... does not resolve"
> messages. 

Sendmail somehow cannot resolve sender addresses via DNS. I've left
sendmail behind more than 20 years ago, and cannot help with that. I've
been using Postfix on UNIX-like systems, and Exim on Cygwin when I
needed an MTA on Windows (but that's also more than 10 years past). I am
not sure how, when, why sendmail reads resolver configuration
(/etc/nsswitch.conf, /etc/host.conf, /etc/resolv.conf, resolv.conf
configuration editors such as resolvconf or systemd)... wrong order of
initialization (meaning DNS unavailable when sendmail started) are
generic considerations for such situations.

<Rant> There's a lot of resolver auto-configuration going on on typical
distributions in the past decade, and that doesn't mix well with
services that are used to constant configuration. </Rant>

Re: [Fetchmail-users] UID lists

[Bob T. <rdt...@gm...>]

On Wed, Aug 12, 2020 at 3:36 PM Matthias Andree <mat...@gm...>
wrote:

> Am 12.08.20 um 20:08 schrieb Bob Tennent:
> > All I wanted was an explanation of what
> >
> >   fetchmail: Old UID list from innovate.cs.queensu.ca:
> >    <empty>
> >
> >   fetchmail: Scratch list of UIDs:
> >    <empty>
>
> So the UID lists is a red herring.

>
> But you were writing "fetchmail isn't working". This is not supported by
> the log you have posted - you've aborted the run before fetchmail could
> download and forward the first message.
>
> So currently I am confused as to whether your setup around fetchmail is
> working, or it is not and you want further support.
>
> As far as I can tell fetchmail *is* working but the mail is disappearing
on my system.  Here's what I get from calling systemctl status sendmail:

  sendmail.service - Sendmail Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/sendmail.service; enabled;
vendor preset: disabled)
   Active: active (running) since Mon 2020-08-10 15:28:07 EDT; 2 days ago
 Main PID: 30452 (sendmail)
    Tasks: 1
   CGroup: /system.slice/sendmail.service
           `-30452 sendmail: accepting connections

Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTD007339:
ruleset=check_mail, arg1=<rdt...@gm...>, relay=localhost
[127.0.0.1], reject=451 4.1.8 Domain of sender address rdt...@gm...
does not resolve
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTD007339: from=<
rdt...@gm...>, size=11081, class=0, nrcpts=0, proto=ESMTP,
daemon=MTA, relay=localhost [127.0.0.1]
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTE007339:
ruleset=check_mail, arg1=<texhax-bounces+rdt=cs....@tu...>,
relay=localhost [127.0.0.1], reject=451 4.1.8 Domain of sender address
texhax-bounces+rdt=cs....@tu... does not resolve
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTE007339:
from=<texhax-bounces+rdt=cs....@tu...>, size=4702, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTF007339:
ruleset=check_mail, arg1=<pe...@ct...>, relay=localhost [127.0.0.1],
reject=451 4.1.8 Domain of sender address pe...@ct... does not resolve
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTF007339: from=<
pe...@ct...>, size=2921, class=0, nrcpts=0, bodytype=8BITMIME,
proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTG007339:
ruleset=check_mail, arg1=<texhax-bounces+rdt=cs....@tu...>,
relay=localhost [127.0.0.1], reject=451 4.1.8 Domain of sender address
texhax-bounces+rdt=cs....@tu... does not resolve
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTG007339:
from=<texhax-bounces+rdt=cs....@tu...>, size=3971, class=0,
nrcpts=0, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTH007339:
ruleset=check_mail, arg1=<tex-live-bounces+rdt=cs....@tu...>,
relay=localhost [127.0.0.1], reject=451 4.1.8 Domain of sender address
tex-live-bounces+rdt=cs....@tu... does not resolve
Aug 12 15:57:49 jimmy.tennent.ca sendmail[7339]: 07CJvnTH007339:
from=<tex-live-bounces+rdt=cs....@tu...>, size=8916, class=0,
nrcpts=0, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost
[127.0.0.1]


I don't understand the "Domain of sender address ... does not resolve"
messages.

Bob T.

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

Re: [Fetchmail-users] UID lists

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

Am 12.08.20 um 20:08 schrieb Bob Tennent:
> All I wanted was an explanation of what 
>
>   fetchmail: Old UID list from innovate.cs.queensu.ca:
>    <empty>
>
>   fetchmail: Scratch list of UIDs:
>    <empty>

Bob,

this just means that there haven't been UIDs stored from previous
fetches (default file: ~/.fetchids), which is debug information and
"normal" for IMAP setups.

For fetchmail 6.4.x and older and with IMAP, those <empty> are expected
and will not change, these fetchmail versions only store UIDs when
fetching from POP3 servers that support the UIDL command and you keep
messages on the server.

But you were writing "fetchmail isn't working". This is not supported by
the log you have posted - you've aborted the run before fetchmail could
download and forward the first message.

So currently I am confused as to whether your setup around fetchmail is
working, or it is not and you want further support.

Regards,
Matthias