fetchmail-users — User questions and discussion

[Fetchmail-users] Problem with GMail changing sslfingerprint

[Héctor A. <hab...@gm...>]

Hi,

I work via ssh using Mutt + Fetchmail and GMail POP3 service. I frequently stop receiving emails because the sslfingerprint is changed, and when I enter the new value in .fetchmailrc and go to GMail settings to re-enable POP3, GMail settings offers me the option of downloading all the messages again or only messages starting from that very moment; I choose the latter, so I lose in my email client all the messages from the moment the sslfingerprint was changed until the moment I adjust its value to the new one and re-enable GMail POP3 settings. This is very annoying.

My .fetchmailrc looks like this:

set daemon 600

poll "pop.gmail.com" with proto POP3 port 995 user "my_...@gm..." password "my_password"
sslfingerprint "6A:11:7A:51:A1:B1:D1:EF:ED:52:C3:0C:15:8F:A8:54"
no rewrite keep ssl nofetchall
mda "/usr/bin/maildrop"

I'm looking for a solution even if it is to stop using GMail, which I'm planning anyway. I'd like to hear about alternative services who are Fetchmail and Mutt friendly. I'm planning to use gpg for privacy, too.

Thank you in advance for any hint or help.

Regards,
-- 
Héctor A. Abreu

[Fetchmail-users] ANNOUNCE: The 6.5.0.beta2 snapshot of fetchmail is available

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

Greetings,

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

The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.beta2.tar.xz/download>

This is a deep link to the GnuPG signature:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.5/fetchmail-6.5.0.beta2.tar.xz.asc/download>

Here are the release notes:

--------------------------------------------------------------------------------
fetchmail-6.5.0 (not yet released):

## REMOVED FEATURES
* fetchmail no longer supports using an MDA as SMTP fallback. This is required 
  to make deliveries consistent.
  The --enable-fallback configure option is gone.
* fetchmail no longer supports SSLv3. --sslproto ssl3 and ssl3+ options have
  been removed and behave as though "--sslproto auto" had been given.

## INCOMPATIBLE CHANGES
* fetchmail by default only negotiates TLS v1.2 or higher. (RFC-7525)
* fetchmail can auto-negotiate TLS v1.1 through the --sslproto tls1.1+ option.
* fetchmail can auto-negotiate TLS v1.0 through the --sslproto tls1+ option.
* fetchmailconf now requires Python 3.7.0 or newer.
* 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.
  Contributed by Holger Hoffstätte.
* fetchmail sets the OPENSSL security level to 2 by default.
  Override is possible from an environment variable,
  see EXPERIMENTAL CHANGES below.

## CHANGED REQUIREMENTS
* fetchmail 6.5.0 is written in C99 and requires a SUSv3 (Single Unix
  Specification v3, a superset of POSIX.1-2001 aka. IEEE Std 1003.1-2001 with
  XSI extension) compliant system.

  In particular, older fetchmail versions had workarounds or replacement code
  for several functions standardized in the Single Unix Specification v3, these 
  have been removed. Hence:
  - The trio/ library has been removed from the distribution.
  - The libesmtp/getaddrinfo.? library has been removed from the distribution.
  - The KAME/getnameinfo.c file has been removed from the distribution.

* fetchmail 6.5.0 requires a TLSv1.3-capable version of OpenSSL,
  at a minimum OpenSSL v1.1.1.

## BUG FIXES
* fetchmail can now report mailbox sizes of 2^31 octets and beyond.
  This required C99 support (for the long long type).
  Fixes Debian Bug#873668, reported by Andreas Schmidt.
* fetchmail now defines its OpenSSL API level (1.1.1, or 10101) so
  as to compile with OpenSSL 3.0.0. (fetchmail was requesting to hide
  deprecated APIs.)

## CHANGES
* When fetchmail attempts to log out from an IMAP4 server and the server messes
  up its responses (it is supposed to send an untagged * BYE and a tagged
  A4711 OK) and sends a tagged A4711 BYE response, tolerate that, rather than
  reporting a protocol error. We don't intend to chat any more so the protocol
  violation is harmless, and we know the server cannot send more untagged
  status responses.
  Analysis and fix courtesy of Maciej S. Szmigiero, GitLab merge request !20.
* The configure script now spends more effort for getting --with-ssl right, by 
  running pkg-config in the right environment, and using the AC_LIB_LINKFLAGS 
  macro to obtain run-time library path setting flags.

## EXPERIMENTAL CHANGES - these are not documented anywhere else, only here:
* fetchmail supports a FETCHMAIL_SSL_SECLEVEL environment variable that
  can be used to override the OpenSSL security level. Fetchmail by default
  raises the security level to 2 if lower. This variable can be used to lower it.
  Use with extreme caution. Note that levels 3 or higher will frequently cause
  incompabilities with servers because server-side data sizes are often too low.
  Valid range: 0 to 5 for OpenSSL 1.1.1 and 3.0.0-alpha4.
* fetchmail supports a FETCHMAIL_SSL_CIPHERS environment variable that
  sets the cipher string (through two different OpenSSL functions) for SSL and
  TLS versions up to TLSv1.2.
  If setting the ciphers fails, fetchmail will not connect.
  If not given, defaults to Postfix's "medium" list, 
  "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH".
* fetchmail supports a FETCHMAIL_TLS13_CIPHERSUITES environment variable
  that sets the ciphersuites (a colon-separated list, without + ! -) for
  TLSv1.3. If not given, defaults to OpenSSL's built-in list. If setting the 
  ciphersuites fails, fetchmail refuses to connect.
* NOTE the features above are simplistic. For instance, even though you 
  configure --sslproto tls1.3, a failure to set tls1.2 ciphers could cause
  a connection abort.

# KNOWN BUGS AND WORKAROUNDS
  (This section usually floats upwards through the NEWS file so it stays with 
  the current release information)
* Fetchmail does not handle messages without Message-ID header well
* Fetchmail currently uses 31-bit signed integers in several places
  where unsigned and/or wider types should have been used.
* 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-users] ANNOUNCE: The 6.4.15 release of fetchmail is available (bug fixes)

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

Greetings,

and a happy new year 2021!

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

It contains a few bug fixes that were contributed via Gitlab.

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

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

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.15.tar.lz)= 6f56d0c08278f190de840ae4d1affa767a2545b056e1993b8d3f80294bbf7ad3
SHA256(fetchmail-6.4.15.tar.xz)= 735b217474937e13cfcdea2d42a346bf68487e0d61efebe4d0d9eddcb3a26b96

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.15 (released 2021-01-03, 27614 LoC):

# BUG FIXES
* Fix a typo in the manual page reported by David McKelvie.
* Fix cross-compilation with openssl, by Fabrice Fontaine. Merge request !23.
* Fix truncation of SMTP PLAIN AUTH with ^ in credentials, by Earl Chew.
  Gitlab issue #23, merge request !25.

# 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.
---------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] EE certificate key too weak error from fetchmail

[David M. <dm...@in...>]

Matthias; thanks for answering my question and sharing the links, most
helpful. I think Ive got enough information now to sort myself out.

Best, David

Re: [Fetchmail-users] EE certificate key too weak error from fetchmail

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

Am 15.12.20 um 17:32 schrieb David McKelvie:
> I have a Ubuntu computer at home. My email gets delivered to a Centos 7 server.
>
> To get my email, I open an ssh tunnel from my home computer to the server
> connecting my port 7110 to the server port 110. Then I point fetchmail at local
> port 7110 to fetch my email.
>
> This worked just fine on Ubuntu 18.04 LTS (and previous versions). However, I
> recently updated to Ubuntu 20.04, and the fetchmail stopped working. The Centos
> server has'nt been updated, so it must be due to the change from Ubuntu 18.04 to
> 20.04. Some change to fetchmail and/or openssl?

David,

I haven't checked Ubuntu 20.04 beyond "compiles and passes smoke test".
Looking at your description, chances are Ubuntu 20.04 (relative to
18.04) inherited OpenSSL configuration from Debian, a higher default
SECLEVEL in particular.

Please see
https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1

and also comment #5 of
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1864689 appears
to be relevant.

This might cause similar errors as you are seeing, and would hint that
checking the server-side certificate for bit lengths and algorithms
could be a good next step.

> Fetchmail version is release 6.4.2+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.
>
> The error from fetchmail is:
>
> fetchmail: Server certificate verification error: EE certificate key too weak
> fetchmail: OpenSSL reported: error:1416F086:
>      SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: localhost: upgrade to TLS failed.
>
> I can still ssh to the server and open the ssh tunnel.

The SSH keys and certificates will usually not be the same as the ones
that the mail server uses, so that doesn't bear relevance here.

> Can anyone inform me what the right thing to do is, Do I need extra options on
> fetchmail, do I need to update a certificate, or modify my ssh config, or
> something else?
fetchmail in your configuration pulls up its own TLS layer (the server
offers STARTTLS and fetchmail uses it, possibly opportunistically)
underneath SSH, so you have SSH as the outer and then TLS on the inner
layer. I think longer keys and corresponding mail-server-side
certificates might help.

--
Matthias Andree

[Fetchmail-users] EE certificate key too weak error from fetchmail

[David M. <dm...@in...>]

I have a Ubuntu computer at home. My email gets delivered to a Centos 7 server.

To get my email, I open an ssh tunnel from my home computer to the server
connecting my port 7110 to the server port 110. Then I point fetchmail at local
port 7110 to fetch my email.

This worked just fine on Ubuntu 18.04 LTS (and previous versions). However, I
recently updated to Ubuntu 20.04, and the fetchmail stopped working. The Centos
server has'nt been updated, so it must be due to the change from Ubuntu 18.04 to
20.04. Some change to fetchmail and/or openssl?

Fetchmail version is release 6.4.2+GSS+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5.

The error from fetchmail is:

fetchmail: Server certificate verification error: EE certificate key too weak
fetchmail: OpenSSL reported: error:1416F086:
    SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: localhost: upgrade to TLS failed.

I can still ssh to the server and open the ssh tunnel.

I can even get round the error by adding '--nosslcertck' to the fetchmail call,
but this sounds a bit hacky (the man page says 'this is a disouraged option'
(sic)).

Can anyone inform me what the right thing to do is, Do I need extra options on
fetchmail, do I need to update a certificate, or modify my ssh config, or
something else?

Any hints very welcome.

Best, David McKelvie

Re: [Fetchmail-users] ssl error

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

Am 02.12.20 um 23:57 schrieb Joe Acquisto-j4:
>> Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4:
>>> fetchmail: 6.3.26  Now gettting this error:
>>>
>>> fetchmail: OpenSSL reported: error:1416F086:SSL
>> routines:tls_process_server_certificate:certificate verify failed
>>> fetchmail: mail.xxxhost.com: SSL connection failed.
>>> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com
>>> fetchmail: Query status=2 (SOCKET)
>>>
>>> Cert on my end appears valid.
>> Oh, and in case mail.xxxhost.com is the true name, I offer my apologies
>> for assuming it were made up, then the operator of mail.xxxhost.com
>> needs to fix the certificate and/or configuration, or you need to
>> configure to poll from an alternative hostname that is vacares.com or
>> ends in .vacares.com.
>>
>> . . .
> It was an obfuscated name,  out of habit.
>
> gnutls seems to like the cert, though it would not connect on 993, resorted to 443.

Well, 993 is for IMAP under TLS wrapper, and 995 for POP3 under TLS
wrapper, or you tell that tool to do starttls and use 110 (POP3) or 143
(IMAP).

Resorting to HTTP may or may not work - there may be transparent
proxies, different certificate configuration for web vs. mail service,
so the results may not transfer.

> I can post the output if you think it of any value.
995 might be POP3, or you could run gnutls or openssl such that they try
starttls.
> It appears to be an intermittent problem, I suspect maybe the other end is doing some
> load sharing or updating.
>
> In any event I will try to update soon as I can.

OK, so if problems persist, please provide the log, per
https://www.fetchmail.info/fetchmail-FAQ.html#G3

Regards,
Matthias

Re: [Fetchmail-users] ssl error

[Joe Acquisto-j. <jo...@j4...>]

> Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4:
>> fetchmail: 6.3.26  Now gettting this error:
>>
>> fetchmail: OpenSSL reported: error:1416F086:SSL 
> routines:tls_process_server_certificate:certificate verify failed
>> fetchmail: mail.xxxhost.com: SSL connection failed.
>> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com
>> fetchmail: Query status=2 (SOCKET)
>>
>> Cert on my end appears valid.
> 
> Oh, and in case mail.xxxhost.com is the true name, I offer my apologies
> for assuming it were made up, then the operator of mail.xxxhost.com
> needs to fix the certificate and/or configuration, or you need to
> configure to poll from an alternative hostname that is vacares.com or
> ends in .vacares.com.
> 
>. . . 

It was an obfuscated name,  out of habit.  

gnutls seems to like the cert, though it would not connect on 993, resorted to 443.
I can post the output if you think it of any value.

It appears to be an intermittent problem, I suspect maybe the other end is doing some 
load sharing or updating.  

In any event I will try to update soon as I can.

Thanks for the assistance.

joe a.

Re: [Fetchmail-users] ssl error

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

Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4:
> fetchmail: 6.3.26  Now gettting this error:
>
> fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: mail.xxxhost.com: SSL connection failed.
> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com
> fetchmail: Query status=2 (SOCKET)
>
> Cert on my end appears valid.

Oh, and in case mail.xxxhost.com is the true name, I offer my apologies
for assuming it were made up, then the operator of mail.xxxhost.com
needs to fix the certificate and/or configuration, or you need to
configure to poll from an alternative hostname that is vacares.com or
ends in .vacares.com.

Running a recent fetchmail reveals it's a server-side configuration error:

> $ FETCHMAILHOME=/tmp VCS-mine/fetchmail-64.git/_build-asan/fetchmail
> --user johndoe mail.xxxhost.com --ssl -ppop3 --auth external
> fetchmail: Server CommonName mismatch: *.vacares.com != mail.xxxhost.com
> fetchmail: Server certificate verification error: Hostname mismatch
> fetchmail: OpenSSL reported: error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed
> fetchmail: mail.xxxhost.com: SSL connection failed.
> fetchmail: socket error while fetching from jo...@ma...
> fetchmail: Query status=2 (SOCKET)
Adding -v to fetchmail's command line (verbose mode) reveals some more
(you could add a second -v, not shown here, left as an exercise for the
reader):

> $ FETCHMAILHOME=/tmp VCS-mine/fetchmail-64.git/_build-asan/fetchmail
> -v --user johndoe mail.xxxhost.com --ssl -ppop3 --auth external
> fetchmail: 6.4.14 querying mail.xxxhost.com (protocol POP3) at Mi 02
> Dez 2020 23:18:39 CET: poll started
> Trying to connect to 84.247.2.168/995...connected.
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: Sectigo Limited
> fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure
> Server CA
> fetchmail: Subject CommonName: *.vacares.com
> fetchmail: Subject Alternative Name: *.vacares.com
> fetchmail: Subject Alternative Name: vacares.com
> fetchmail: Server CommonName mismatch: *.vacares.com != mail.xxxhost.com
> fetchmail: mail.xxxhost.com key fingerprint:
> 96:0F:21:78:99:7C:29:98:A6:2B:1F:B8:8D:51:4A:68
> fetchmail: Server certificate verification error: Hostname mismatch
> fetchmail: OpenSSL reported: error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed
> fetchmail: mail.xxxhost.com: SSL connection failed.
> fetchmail: socket error while fetching from jo...@ma...
> fetchmail: 6.4.14 querying mail.xxxhost.com (protocol POP3) at Mi 02
> Dez 2020 23:18:39 CET: poll completed
> fetchmail: Query status=2 (SOCKET)
> fetchmail: normal termination, status 2

Similar outcome with gnutls-cli (see Status near the end):

> $ gnutls-cli -p 993 mail.xxxhost.com
> Processed 147 CA certificate(s).
> Resolving 'mail.xxxhost.com:993'...
> Connecting to '84.247.2.168:993'...
> - Certificate type: X.509
> - Got a certificate list of 4 certificates.
> - Certificate[0] info:
>  - subject `CN=*.vacares.com', issuer `CN=Sectigo RSA Domain
> Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater
> Manchester,C=GB', serial 0x008dfe7795c6d801c5326f05a13b5c3e2a, RSA key
> 4096 bits, signed using RSA-SHA256, activated `2020-06-05 00:00:00
> UTC', expires `2021-06-05 23:59:59 UTC',
> pin-sha256="MfW9RHMXODSXNfNRy0f4k8v253Lb/ySWrSo3wfzDTkg="
>     Public Key ID:
>         sha1:28e3271a15a526f38e813f7cff6a9164e34cfb46
>       
>  sha256:31f5bd44731738349735f351cb47f893cbf6e772dbff2496ad2a37c1fcc34e48
>     Public Key PIN:
>         pin-sha256:MfW9RHMXODSXNfNRy0f4k8v253Lb/ySWrSo3wfzDTkg=
>
> - Certificate[1] info:
>  - subject `CN=Sectigo RSA Domain Validation Secure Server
> CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', issuer
> `CN=USERTrust RSA Certification Authority,O=The USERTRUST
> Network,L=Jersey City,ST=New Jersey,C=US', serial
> 0x7d5b5126b476ba11db74160bbc530da7, RSA key 2048 bits, signed using
> RSA-SHA384, activated `2018-11-02 00:00:00 UTC', expires `2030-12-31
> 23:59:59 UTC', pin-sha256="4a6cPehI7OG6cuDZka5NDZ7FR8a60d3auda+sKfg4Ng="
> - Certificate[2] info:
>  - subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST
> Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AAA Certificate
> Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB',
> serial 0x3972443af922b751d7d36c10dd313595, RSA key 4096 bits, signed
> using RSA-SHA384, activated `2019-03-12 00:00:00 UTC', expires
> `2028-12-31 23:59:59 UTC',
> pin-sha256="x4QzPSC810K5/cMjb05Qm4k3Bw5zBn4lTdO/nEW/Td4="
> - Certificate[3] info:
>  - subject `CN=AAA Certificate Services,O=Comodo CA
> Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=AAA
> Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater
> Manchester,C=GB', serial 0x01, RSA key 2048 bits, signed using
> RSA-SHA1, activated `2004-01-01 00:00:00 UTC', expires `2028-12-31
> 23:59:59 UTC', pin-sha256="vRU+17BDT2iGsXvOi76E7TQMcTLXAqj0+jGPdW7L1vM="
> - Status: The certificate is NOT trusted. The name in the certificate
> does not match the expected.
> *** PKI verification of server certificate failed...
> *** Fatal error: Error in the certificate.
HTH
Matthias

Re: [Fetchmail-users] ssl error

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

Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4:
> fetchmail: 6.3.26  Now gettting this error:
>
> fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: mail.xxxhost.com: SSL connection failed.
> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com
> fetchmail: Query status=2 (SOCKET)
>
> Cert on my end appears valid.

Hi Joe,

you may have noticed that the current version is now 6.4.14, and 6.4.X
brought several SSL/TLS and logging fixes. 6.3.26 is some seven years
old now, and I don't support it any longer.

If you still see the same issues with a halfway recent 6.4.X release
(I'm not too picky), please provide the information listed as needed in
https://www.fetchmail.info/fetchmail-FAQ.html#G3 and share it, and
please don't make up the server's name so we can actually use gnutls-cli
or openssl or similar tools to look at the server.

What distribution and version are you running fetchmail on?

What is your OpenSSL version that fetchmail links against?

Regards
Matthias

[Fetchmail-users] ssl error

[Joe Acquisto-j. <jo...@j4...>]

fetchmail: 6.3.26  Now gettting this error:

fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: mail.xxxhost.com: SSL connection failed.
fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com
fetchmail: Query status=2 (SOCKET)

Cert on my end appears valid. 

joe a.

Re: [Fetchmail-users] incorrect message count

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

Am 29.11.20 um 15:25 schrieb rus...@gm...:
> 	gmail reports total messages, fetchmail (sendmail?) is
> rejecting those from domains with no MX record:
>
> 	fetchmail: reading message bil...@po...:1 of 6 (3726 octets) (log message incomplete)
> 	fetchmail: SMTP error: 553 5.1.8 <bil...@nu...>... Domain of sender address bil...@nu... does not exist

Russell,

The "SMTP error" is what your server (sendmail?) reports back, and
fetchmail just transports that 553 5.1.8.... message.

And let me ask you again, if you stay on the same topic, please do NOT
compose a new message, but instead use the "Reply" button and edit the
quoting. This helps organizing messages into threads by topic. Thank you.

Regards,
Matthias

[Fetchmail-users] incorrect message count

[<rus...@gm...>]

	gmail reports total messages, fetchmail (sendmail?) is
rejecting those from domains with no MX record:

	fetchmail: reading message bil...@po...:1 of 6 (3726 octets) (log message incomplete)
	fetchmail: SMTP error: 553 5.1.8 <bil...@nu...>... Domain of sender address bil...@nu... does not exist

I should have inspected my log more thoroughly before asking.  Thanks
for your forbearance.

russell bell

Re: [Fetchmail-users] incorrect message count

[Gene H. <ghe...@sh...>]

On Saturday 28 November 2020 10:14:08 rus...@gm... wrote:

> 	It seems gmail mis-reports:
>
> 	fetchmail: POP3> LIST 2
> 	fetchmail: POP3< +OK 2 69962
> 	fetchmail: POP3> TOP 2 99999999
> 	fetchmail: POP3< +OK message follows
> 	reading message bil...@po...:2 of 2 (69962 octets)
> 	.
> 	.
> 	.
>
> 	fetchmail: POP3> DELE 2
> 	fetchmail: POP3< +OK marked for deletion
> 	fetchmail: POP3> QUIT
> 	fetchmail: POP3< +OK Farewell.
>
> but there's only 1 message; the octet count is right; accessing it via
> browser shows only 1 message.
>
> 	Of course I inspected /var/spool/mail/billybomb first.  I
> hadn't known about the different protocols for mbox; that wasn't
> relevant to my situation.
>
> 	Apologies for bothering you.  Thanks for your help.
>
> russell bell
>
I don't know about gmail as I bailed out of that years ago due to their 
non-compliance with the RFC's that supposedly govern email. Wasn't worth 
the headaches it causes.

But my ISP's current mail server, dovecot, which serves up the email for 
both pop3 and imap from the same directory, dishonors a pop3 DELE 
because some customers use both, but does honor an IMAP DELE, so I 
switched my fetchmail to use the imap protocol, so now I don't have to 
log in with a browser and sit here killing messages 100 at a time for 
half an hour a month just to keep my mailbox from being such a spam 
source and target. Sweet. Someone should try it with scroowgle and see 
if it works.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [Fetchmail-users] incorrect message count

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

Am 28.11.20 um 16:14 schrieb rus...@gm...:
> 	It seems gmail mis-reports:
>
> 	fetchmail: POP3> LIST 2
> 	fetchmail: POP3< +OK 2 69962
> 	fetchmail: POP3> TOP 2 99999999
> 	fetchmail: POP3< +OK message follows
> 	reading message bil...@po...:2 of 2 (69962 octets)
> 	.
> 	.
> 	.
>
> 	fetchmail: POP3> DELE 2
> 	fetchmail: POP3< +OK marked for deletion
> 	fetchmail: POP3> QUIT
> 	fetchmail: POP3< +OK Farewell.
>
> but there's only 1 message; the octet count is right; accessing it via
> browser shows only 1 message.

Russell,

1. I think I need to investigate this, and I must ask again for the
logs, because POP3 should not skip message #1 and if it does there
should be relevant logging (note a difference between "retained" and
"kept" and "skipped") - with one exception that would typically *not*
apply to Google's mail services but only to specific server software
that appears to be dying out as species.
<https://www.fetchmail.info/fetchmail-FAQ.html#O15>

=> Please send a **FULL** verbose log per
<https://www.fetchmail.info/fetchmail-FAQ.html#G3>. If you feel you need
to make systematic edits for privacy as, use something blatantly obvious
such as XXXXXXXXXXXXx, YYYYYYYYYYY or similar. Be sure to use the same
replacement everywhere, i. e. make all joe into XXXXXX and all karla
into YYYYYY, and use search&replace.

2. Please use "Reply to List" (or "Reply to all") and do NOT start new
threads when you are replying.

Thank you in advance.

Regards,
Matthias

[Fetchmail-users] incorrect message count

[<rus...@gm...>]

	It seems gmail mis-reports:
	
	fetchmail: POP3> LIST 2	
	fetchmail: POP3< +OK 2 69962	
	fetchmail: POP3> TOP 2 99999999	
	fetchmail: POP3< +OK message follows	
	reading message bil...@po...:2 of 2 (69962 octets) 
	.	
	.	
	.	
		
	fetchmail: POP3> DELE 2	
	fetchmail: POP3< +OK marked for deletion	
	fetchmail: POP3> QUIT	
	fetchmail: POP3< +OK Farewell.	
	
but there's only 1 message; the octet count is right; accessing it via
browser shows only 1 message.
	
	Of course I inspected /var/spool/mail/billybomb first.  I
hadn't known about the different protocols for mbox; that wasn't
relevant to my situation.

	Apologies for bothering you.  Thanks for your help.

russell bell

Re: [Fetchmail-users] incorrect message count

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

Hi russell,

> > In fact it is your POP3 or IMAP server that counts messages, and
> > fetchmail asks it.
>
> Okay.  I'm surprised that gmail doesn't get it right.

I think you're missing the probably problem.

- Gmail correctly tells fetchmail there are five messages when it asks
  over POP3 or IMAP.
- Gmail passes each of those five to fetchmail as it asks for them.
- fetchmail has probably been told to store all five in a single mbox
  file, of which there are several various formats.
  https://en.wikipedia.org/wiki/Mbox
- Whatever is reading the mbox file, e.g. mail(1), is not seeing five
  emails and instead is treating some emails as part of an earlier one.
- Examining the mbox file and comparing it against the documented format
  and the emails mail(1) presents might help spot the cause.

-- 
Cheers, Ralph.

Re: [Fetchmail-users] incorrect message count

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

Am 27.11.20 um 13:36 schrieb rus...@gm...:
> 	fetchmail: reading message bil...@po...:5 of 5 (3096 octets) flushed
>
> when there are only 2 messages.

OK, get me the logs... see https://www.fetchmail.info/fetchmail-FAQ.html#G3

[Fetchmail-users] incorrect message count

[<rus...@gm...>]

	Asks Matthias Andree:

	'why do you believe it were fetchmail that is counting the 5
messages?'
	Because fetchmail's log reads:

	fetchmail: reading message bil...@po...:5 of 5 (3096 octets) flushed

when there are only 2 messages.

	'Is mail configured to show unread mail as well?'
	No.

	'In fact it is your POP3 or IMAP server that counts messages,
and fetchmail asks it.'
	Okay.  I'm surprised that gmail doesn't get it right.  Thanks
for telling me.

russell bell

[Fetchmail-users] ANNOUNCE: The 6.4.14 release of fetchmail is available (update for Serbian translation)

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

Greetings,

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

It updates the Serbian translation and also the FAQ.

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

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

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.14.tar.lz)= b84dba26e64b526515256a8ae705eb2bc5338b7fa1455c4c08410df20cc28ae6
SHA256(fetchmail-6.4.14.tar.xz)= 424707390f7cdc6d16db4887931117f2242873846b28cc1d0ae1c0ecf158bdcb

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.14 (released 2020-11-26):

# TRANSLATION UPDATES were made by these fine people:
* sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]

# 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.

---------------------------------------------------------------------------------
By popular demand, diffs from the previous release have been omitted.

Happy fetches,
Matthias

Re: [Fetchmail-users] Exchange internal emails and multidrop.

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

Am 26.11.20 um 06:54 schrieb David Tildesley via Fetchmail-users:
>  Sorry. False alarm. It is working fine from internal email accounts - just a little quirk with Exchange and email alias.
> Fetchmail is a great product.

Hi David,

glad it is working for you,
note however that multidrop is generally quirky.

Also I am wondering... this "false alarm" mail reached GMANE but not the
list, hence I am quoting the message in full.

>     On Thursday, 26 November 2020, 08:09:21 am NZDT, David Tildesley via Fetchmail-users <fet...@li...> wrote:
>
>  Hi,Exchange2016 IMAP. Latest fetchmail from Redhat repo.
> We are using fetchmail multidrop for the first time successfully apart from emails sent from internal email accounts. Works fine from external origin email.
> Has anyone else come across this?
> Just a quick sanity check before deep dive analysis with verbose logging etc.
> Regards,David.
> Sent from Yahoo Mail on Android

Re: [Fetchmail-users] Exchange internal emails and multidrop.

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

 Sorry. False alarm. It is working fine from internal email accounts - just a little quirk with Exchange and email alias.
Fetchmail is a great product.
    On Thursday, 26 November 2020, 08:09:21 am NZDT, David Tildesley via Fetchmail-users <fet...@li...> wrote:  
 
 Hi,Exchange2016 IMAP. Latest fetchmail from Redhat repo.
We are using fetchmail multidrop for the first time successfully apart from emails sent from internal email accounts. Works fine from external origin email.
Has anyone else come across this?
Just a quick sanity check before deep dive analysis with verbose logging etc.
Regards,David.
Sent from Yahoo Mail on Android
_______________________________________________
Fetchmail-users mailing list
Fet...@li...
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
  

[Fetchmail-users] Exchange internal emails and multidrop.

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

Hi,Exchange2016 IMAP. Latest fetchmail from Redhat repo.
We are using fetchmail multidrop for the first time successfully apart from emails sent from internal email accounts. Works fine from external origin email.
Has anyone else come across this?
Just a quick sanity check before deep dive analysis with verbose logging etc.
Regards,David.
Sent from Yahoo Mail on Android

Re: [Fetchmail-users] incorrect message count

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

Am 25.11.20 um 13:14 schrieb rus...@gm...:
> 	fetchmail reports:
>
> 	fetchmail: reading message bil...@po...:5 of 5 (32117 octets) flushed
>
> 	mail returns:
>
> 	mailx version v14.9.19.  Type `?' for help
> 	/var/spool/mail/billybomb: 1 message 1 new
> 	>N  1 Kosair Charities               2020-11-24  432/31949 We're thankful for you
>
> 	I notice that the message has 5 instances of 'From ', but only
> 1 at the beginning of a line.  This is consistent with fetchmail
> counting all instances rather than just the ones at the beginning of a
> line.  This happens for most of my fetched messages.  On a subsequent
> mail spool file, the number corresponded to the instances of "From "
> and "From: ", but was case-sensitive.
>
> russell bell

Russell,

why do you believe it were fetchmail that is counting the 5 messages? Is
mail configured to show unread mail as well?

In fact it is your POP3 or IMAP server that counts messages, and
fetchmail asks it.

Please see https://www.fetchmail.info/fetchmail-FAQ.html#G3 for the
troubleshooting instructions and logs to provide.

Thank you.

Regards,
Matthias Andree

[Fetchmail-users] incorrect message count

[<rus...@gm...>]

	fetchmail reports:

	fetchmail: reading message bil...@po...:5 of 5 (32117 octets) flushed

	mail returns:

	mailx version v14.9.19.  Type `?' for help
	/var/spool/mail/billybomb: 1 message 1 new
	>N  1 Kosair Charities               2020-11-24  432/31949 We're thankful for you

	I notice that the message has 5 instances of 'From ', but only
1 at the beginning of a line.  This is consistent with fetchmail
counting all instances rather than just the ones at the beginning of a
line.  This happens for most of my fetched messages.  On a subsequent
mail spool file, the number corresponded to the instances of "From "
and "From: ", but was case-sensitive.

russell bell