fetchmail-users — User questions and discussion

Re: [Fetchmail-users] fetchmail and ssl certificates

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

Am 02.07.20 um 15:28 schrieb Ranjan Maitra:
> Hi,
>
> Here is my .fetchmailrc
>
> set daemon 301
> poll pop.gmx.com
>      protocol POP3
>      service 995
>      authenticate password
>      user "use...@gm..."
>      ssl
>      sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
> mda 'procmail -d %s'
> keep
>
> So, it worked fine till last night, but since this morning, this has not been working. Here is what I get:
>
> $ fetchmail -c
> fetchmail: pop.gmx.com fingerprints do not match!
> fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: pop.gmx.com: SSL connection failed.
> fetchmail: socket error while fetching from use...@gm...@pop.gmx.com
>
>
> Here is how I verified my fingerprint:
>
> ~$ openssl s_client -servername gmx.com -connect pop.gmx.com:995 | openssl x509 -fingerprint -noout
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
> verify return:1
> depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mout.gmx.com
> verify return:1
> SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA
>
> Any suggestions as to what I am doing wrong?
>
> I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.
>
> Many thanks,
> Ranjan

Perhaps they have corrected the issue, because I currently get this with
-cvv and the subjectAltName seems to cover their usage.

...
fetchmail: Server certificate:
fetchmail: Issuer Organization: DigiCert Inc
fetchmail: Issuer CommonName: GeoTrust RSA CA 2018
fetchmail: Subject CommonName: mout.gmx.com
fetchmail: Subject Alternative Name: mout.gmx.com
fetchmail: Subject Alternative Name: mail.gmx.com
fetchmail: Subject Alternative Name: mx00.gmx.com
fetchmail: Subject Alternative Name: mx01.gmx.com
fetchmail: Subject Alternative Name: pop.gmx.com
fetchmail: Subject Alternative Name: imap.gmx.com
fetchmail: Subject Alternative Name: smtp.gmx.com
fetchmail: pop.gmx.com key fingerprint:
A5:6D:6D:D4:2D:BE:4D:F5:0A:3A:DD:3E:A6:C2:D3:E8
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher
TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: POP3< +OK POP server ready H migmx003 1M7L3e-1jjMxZ1u5E-007l8Y
...

Re: [Fetchmail-users] build errors for fetchmail-6.4.8

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

Am 30.06.20 um 02:32 schrieb Peter Scott via Fetchmail-users:
> Hello,
>
> I'm trying to compile fetchmail version 6.4.8.
>
> Here are a few lines before it quits:
>
> /opt/openssl/include/openssl/x509v3.h:166: undefined reference to
> `OPENSSL_sk_num'
> socket.o: In function `sk_GENERAL_NAME_value':
> /opt/openssl/include/openssl/x509v3.h:166: undefined reference to
> `OPENSSL_sk_value'
> socket.o: In function `sk_GENERAL_NAME_free':
> /opt/openssl/include/openssl/x509v3.h:166: undefined reference to
> `OPENSSL_sk_free'
> socket.o: In function `SSLOpen':
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1077: undefined
> reference to `OpenSSL_version_num'
> socket.o: In function `OSSL110_proto_version_logic':
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:983: undefined
> reference to `TLS_client_method'
> socket.o: In function `SSLOpen':
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1138: undefined
> reference to `SSL_CTX_set_options'
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1206: undefined
> reference to `SSL_get0_param'
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1208: undefined
> reference to `X509_VERIFY_PARAM_set_hostflags'
> /home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1209: undefined
> reference to `X509_VERIFY_PARAM_set1_host'
>
> What should I try?

Peter,

Please show the exact configure and make command lines, and possibly
upload or paste the entire log somewhere and post the URL, and possibly
also your config.log.

It looks as though the library to OpenSSL is missing, and we need to
figure out if your system has an incomplete install or if configure[.ac]
is somewhat broken.

Regards,
Matthias

Re: [Fetchmail-users] fetchmail and ssl certificates

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

On Thu, Jul 02, 2020 at 08:28:15AM -0500, Ranjan Maitra wrote:
> Hi,
> 
> Here is my .fetchmailrc
> 
> set daemon 301
> poll pop.gmx.com
>      protocol POP3
>      service 995
>      authenticate password
>      user "use...@gm..."
>      ssl
>      sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
> mda 'procmail -d %s'
> keep
> 
> So, it worked fine till last night, but since this morning, this has not been working. Here is what I get:
> 
> $ fetchmail -c
> fetchmail: pop.gmx.com fingerprints do not match!
> fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
> fetchmail: pop.gmx.com: SSL connection failed.
> fetchmail: socket error while fetching from use...@gm...@pop.gmx.com
> 
> 
> Here is how I verified my fingerprint:
> 
> ~$ openssl s_client -servername gmx.com -connect pop.gmx.com:995 | openssl x509 -fingerprint -noout
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
> verify return:1
> depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mout.gmx.com
> verify return:1
> SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA
> 
> Any suggestions as to what I am doing wrong?
> 
> I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.

It seems that gmx.com have deployed the certificates for "mout.gmx.com"
on the services that listen for connections on the addresses for
"pop.gmx.com". The "CN = mout.gmx.com" part says "this certificate has
been issued to the mout.gmx.com server", and fetchmail is (rightly)
concerned about the hostname pop.gmx.com not being the same as that.

The real solution to the problem would be to let GMX know so that they
can deploy the correct certificate. A workaround so that you may fetch
your e-mail today would be to explicitly specify

  sslcommonname mout.gmx.com

...or something similar in your fetchmail configuration, so that it
knows to expect a certificate issued to a different host than the one it
thinks it's connecting to.

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] fetchmail and ssl certificates

[Ranjan M. <ma...@em...>]

Hi,

Here is my .fetchmailrc

set daemon 301
poll pop.gmx.com
     protocol POP3
     service 995
     authenticate password
     user "use...@gm..."
     ssl
     sslfingerprint "5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA"
mda 'procmail -d %s'
keep

So, it worked fine till last night, but since this morning, this has not been working. Here is what I get:

$ fetchmail -c
fetchmail: pop.gmx.com fingerprints do not match!
fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
fetchmail: pop.gmx.com: SSL connection failed.
fetchmail: socket error while fetching from use...@gm...@pop.gmx.com


Here is how I verified my fingerprint:

~$ openssl s_client -servername gmx.com -connect pop.gmx.com:995 | openssl x509 -fingerprint -noout
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018
verify return:1
depth=0 C = DE, ST = Rheinland-Pfalz, L = Montabaur, O = 1&1 Mail & Media GmbH, CN = mout.gmx.com
verify return:1
SHA1 Fingerprint=5C:6B:60:FE:80:97:0B:13:EB:36:A3:66:48:28:7A:61:5E:B2:25:DA

Any suggestions as to what I am doing wrong?

I am on F32 (fully updated) which has fetchmail-6.4.1 and openssl-1:1.1.1g.

Many thanks,
Ranjan

[Fetchmail-users] build errors for fetchmail-6.4.8

[Peter S. <dr...@uc...>]

Hello,

I'm trying to compile fetchmail version 6.4.8.

Here are a few lines before it quits:

/opt/openssl/include/openssl/x509v3.h:166: undefined reference to
`OPENSSL_sk_num'
socket.o: In function `sk_GENERAL_NAME_value':
/opt/openssl/include/openssl/x509v3.h:166: undefined reference to
`OPENSSL_sk_value'
socket.o: In function `sk_GENERAL_NAME_free':
/opt/openssl/include/openssl/x509v3.h:166: undefined reference to
`OPENSSL_sk_free'
socket.o: In function `SSLOpen':
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1077: undefined
reference to `OpenSSL_version_num'
socket.o: In function `OSSL110_proto_version_logic':
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:983: undefined
reference to `TLS_client_method'
socket.o: In function `SSLOpen':
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1138: undefined
reference to `SSL_CTX_set_options'
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1206: undefined
reference to `SSL_get0_param'
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1208: undefined
reference to `X509_VERIFY_PARAM_set_hostflags'
/home/drip/src/fetchmail/fetchmail-6.4.8/socket.c:1209: undefined
reference to `X509_VERIFY_PARAM_set1_host'

What should I try?

Thanks for any suggestions.

     -- Peter

Re: [Fetchmail-users] Internationalized (EAI) mail in fetchmail?

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

Am 22.06.20 um 03:17 schrieb John Levine:
> In article <325...@gm...> you write:
>> Am 20.06.20 um 03:27 schrieb John Levine:
>>> Looking at the source code I can see there's no EAI support in Fetchmail ...
>> fetchmail isn't EAI ready yet.
> Uh, right.

Well, I should have written "nor is it supposed to be, yet".

I want this to change for fetchmail 7.x (which is a longer while out,
and lives on the next branch in Git) and I am tracking this in a Gitlab
issue so it doesn't get lost:
https://gitlab.com/fetchmail/fetchmail/-/issues/14

Feel free to add your technical/testing/known-implementations comments
there, or if you don't want to bother with creating an account there, I
can do it for you.

>> I'm not sure if fetchmail should care because the known protocol and
>> system breachers you named the "big gorillas" do it. They disregard lots
>> of other standards...
> I've looked at Gmail and and am looking at Outlook/Hotmail and their EAI
> implementations seem pretty standard conformant to me.

I don't dispute that, but I've had a small share of idiosyncrasies of
Outlook and GMail already.

Especially Google's mailbox and recent: models and workarounds are
strange, and the push towards OAuth2 that runs entirely counter to a
small console-based mail-fetching application...

> You might look at Coremail in China and XGenPlus in India, both of
> which have good EAI support.

I guess we'd need to have those tested by fetchmail users.

Re: [Fetchmail-users] Internationalized (EAI) mail in fetchmail?

[John L. <jo...@ta...>]

In article <325...@gm...> you write:
>Am 20.06.20 um 03:27 schrieb John Levine:
>> Looking at the source code I can see there's no EAI support in Fetchmail ...

>fetchmail isn't EAI ready yet.

Uh, right.

>I'm not sure if fetchmail should care because the known protocol and
>system breachers you named the "big gorillas" do it. They disregard lots
>of other standards...

I've looked at Gmail and and am looking at Outlook/Hotmail and their EAI
implementations seem pretty standard conformant to me.

You might look at Coremail in China and XGenPlus in India, both of
which have good EAI support.

Re: [Fetchmail-users] Internationalized (EAI) mail in fetchmail?

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

Am 20.06.20 um 03:27 schrieb John Levine:
> I'm working on a project to see how popular mail software supports
> EAI, internationalized mail with Unicode most places that ASCII is
> allowed such as e-mail addresses, IMAP folder names, and account names
> and passwords.
>
> Looking at the source code I can see there's no EAI support in
> Fetchmail but I'm wondering if anyone had looked at it. I'd think it'd
> affect the code that picks up mail from POP or IMAP servers, and that
> resubmits fetched mail locally by SMTP.

John,

fetchmail isn't EAI ready yet.

I'd briefly looked at it after I got reports of strange behaviour that I
could reproduce when using Courier-IMAP 5.0 or newer as server with
internationalized mail, and have the relevant RFCs on my reading list,
but it's not a priority ATM.

EAI would affect transfer code to some lesser extent, and to a bigger
extent, the necessary protocol negotiations on all fronts would have to
be written.

> In past years there was no point since there was hardly anyone who
> supported EAI, but now a lot of popular open source mail software such
> as Postfix and Exim now have EAI support as do big gorillas Gmail and
> Hotmail/Outlook and a fair number of regional mail providers in Asia.

I'm not sure if fetchmail should care because the known protocol and
system breachers you named the "big gorillas" do it. They disregard lots
of other standards...

That is to say, I find the reason "regional mail providers in [some
non-English-dominated region]" much more convincing because that
promises more of a user benefit than accomodating priorities of some
corporations that try to force browsers onto the world with incomplete
OAUTH2 implementations on their ends.

[Fetchmail-users] Internationalized (EAI) mail in fetchmail?

[John L. <jo...@ta...>]

I'm working on a project to see how popular mail software supports
EAI, internationalized mail with Unicode most places that ASCII is
allowed such as e-mail addresses, IMAP folder names, and account names
and passwords.

Looking at the source code I can see there's no EAI support in
Fetchmail but I'm wondering if anyone had looked at it. I'd think it'd
affect the code that picks up mail from POP or IMAP servers, and that
resubmits fetched mail locally by SMTP.

In past years there was no point since there was hardly anyone who
supported EAI, but now a lot of popular open source mail software such
as Postfix and Exim now have EAI support as do big gorillas Gmail and
Hotmail/Outlook and a fair number of regional mail providers in Asia.

Regards,
John Levine, jo...@ta..., Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.8 is now available (new translation for Serbian, courtesy of Miroslav Nikolić)

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

Greetings,

The 6.4.8 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.8.tar.xz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4//fetchmail-6.4.8.tar.lz>

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

SHA256 hash values:
SHA256(fetchmail-6.4.8.tar.lz)= d8e03112a4067e0bf930cba7da20de82d970ad657efa1aeb7fe4e35229cb0ce1
SHA256(fetchmail-6.4.8.tar.xz)= 26cd936ece146e056cdf79a676a33738b4eab0a5ae2edf3fce5ba034721b09bd

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.8 (released 2020-06-14, 27596 LoC):

## NEW TRANSLATION, with thanks to the translator:
* sr:    Мирослав Николић (Miroslav Nikolić) [Serbian]
- Sorry, this was missed earlier because my translation scripts did not properly
  report new translations.

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

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.7 is now available (translation update for Swedish)

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

Greetings,

The 6.4.7 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 in two compressed formats at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.7.tar.xz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.7.tar.lz>

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

SHA256 hash values:
SHA256(fetchmail-6.4.7.tar.lz)= d6e9918240f2ddc07aa91a478f8a6359279d41de287eb5b27e1fe6ee28b1b81e
SHA256(fetchmail-6.4.7.tar.xz)= c4c8d1b7356f82f2ec62e55abe1f266acaa808a7398ad79a9211644a7a905c62

Here are the release notes:

--------------------------------------------------------------------------------
fetchmail-6.4.7 (released 2020-06-14, 27596 LoC):

## TRANSLATION UPDATE, with thanks to the translator:
* sv:    Göran Uddeborg [Swedish]

# 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

[Fetchmail-users] ANNOUNCE: fetchmail 6.4.6 is now available (translation update for Esperanto)

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

Greetings,

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

This fixes a regression on older operating systems that can print this error:
fetchmail: Cannot find absolute path for user's home directory

== 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 in two formats at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.6.tar.xz>
<https://downloads.sourceforge.net/project/fetchmail/branch_6.4/fetchmail-6.4.6.tar.lz>

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

SHA256 hash values:
SHA256(fetchmail-6.4.6.tar.lz)= 7bc1e126d159e0a2e977104ab262935ff6c1e5d341d271fd07a2d669ed475aff
SHA256(fetchmail-6.4.6.tar.xz)= 16efec4b6019b4d2b6e43ed1d4f523dee019ac86754de856d0cf34d503d66011

Here are the release notes:

--------------------------------------------------------------------------------
fetchmail-6.4.6 (released 2020-05-29, 27596 LoC):

## TRANSLATION UPDATE, with thanks to the translator:
* eo:    Felipe Castro [Esperanto]
--------------------------------------------------------------------------------

Happy fetches,
Matthias

Re: [Fetchmail-users] Procmail filtering question

[Gerard E. S. <ger...@ou...>]

On Thu, 28 May 2020 19:59:37 +0200, Carlos E. R. stated:
>On 28/05/2020 16.57, Matthias Andree wrote:
>> Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:  
>
>...
>
>> 
>> This has been a normal format since 1993 or so (RFC 1522, now RFC
>> 2047).
>> 
>> Everyone just stop using that unmaintained (for almost 20 years)
>> pile of design garbage called procmail.  
>
>And use what, then?

I use 'sieve' with dovecot. It is way more powerful than procmail ever
hoped to be, and in my opinion, easier to configure.

-- 
Gerard

Re: [Fetchmail-users] Procmail filtering question

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

On 28/05/2020 22.54, Matthias Andree wrote:
> Am 28.05.20 um 21:32 schrieb Carlos E. R.:
>> On 28/05/2020 21.19, Peter Pentchev wrote:
>>> On Thu, May 28, 2020 at 07:59:37PM +0200, Carlos E. R. wrote:
>>>> On 28/05/2020 16.57, Matthias Andree wrote:
>>>>> Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:
>>>>
>>>> ...
>>>>
>>>>>
>>>>> This has been a normal format since 1993 or so (RFC 1522, now RFC
>>>>> 2047).
>>>>>
>>>>> Everyone just stop using that unmaintained (for almost 20 years)
>>>>> pile of
>>>>> design garbage called procmail.
>>>>
>>>> And use what, then?
>>>
>>> maildrop? (possibly courier-maildrop)
>>
>> I considered that once, but in my distribution of choice it meant
>> installing the entire courier thing, and that was problematic (I use
>> dovecot). I did not find out how to replace procmail with maildrop.
> 
> Dovecot has Sieve and dovecot-lda or however it's called these days,

The man page of dovecot-lda doesn't explain how to do filtering. I have 
used dovecot-lda called from inside procmail, to do the delivery, but 
after some years I reverted it, because it deletes flags such as "read" 
or "replied".

Sieve I have not tried.


-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Procmail filtering question

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

Am 28.05.20 um 21:32 schrieb Carlos E. R.:
> On 28/05/2020 21.19, Peter Pentchev wrote:
>> On Thu, May 28, 2020 at 07:59:37PM +0200, Carlos E. R. wrote:
>>> On 28/05/2020 16.57, Matthias Andree wrote:
>>>> Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:
>>>
>>> ...
>>>
>>>>
>>>> This has been a normal format since 1993 or so (RFC 1522, now RFC
>>>> 2047).
>>>>
>>>> Everyone just stop using that unmaintained (for almost 20 years)
>>>> pile of
>>>> design garbage called procmail.
>>>
>>> And use what, then?
>>
>> maildrop? (possibly courier-maildrop)
>
> I considered that once, but in my distribution of choice it meant
> installing the entire courier thing, and that was problematic (I use
> dovecot). I did not find out how to replace procmail with maildrop.

Dovecot has Sieve and dovecot-lda or however it's called these days, and
on my distros, maildrop is also available without the full courier rig -
and maildrop has been my recommendation for a while.

There may be other options, and I wonder if Claws doesn't have built-in
filters, but I haven't used it in over a decade.

Re: [Fetchmail-users] Procmail filtering question

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

On 28/05/2020 21.19, Peter Pentchev wrote:
> On Thu, May 28, 2020 at 07:59:37PM +0200, Carlos E. R. wrote:
>> On 28/05/2020 16.57, Matthias Andree wrote:
>>> Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:
>>
>> ...
>>
>>>
>>> This has been a normal format since 1993 or so (RFC 1522, now RFC 2047).
>>>
>>> Everyone just stop using that unmaintained (for almost 20 years) pile of
>>> design garbage called procmail.
>>
>> And use what, then?
> 
> maildrop? (possibly courier-maildrop)

I considered that once, but in my distribution of choice it meant 
installing the entire courier thing, and that was problematic (I use 
dovecot). I did not find out how to replace procmail with maildrop.


-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Procmail filtering question

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

On Thu, May 28, 2020 at 07:59:37PM +0200, Carlos E. R. wrote:
> On 28/05/2020 16.57, Matthias Andree wrote:
> > Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:
> 
> ...
> 
> > 
> > This has been a normal format since 1993 or so (RFC 1522, now RFC 2047).
> > 
> > Everyone just stop using that unmaintained (for almost 20 years) pile of
> > design garbage called procmail.
> 
> And use what, then?

maildrop? (possibly courier-maildrop)

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] Procmail filtering question

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

On 28/05/2020 16.57, Matthias Andree wrote:
> Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:

...

> 
> This has been a normal format since 1993 or so (RFC 1522, now RFC 2047).
> 
> Everyone just stop using that unmaintained (for almost 20 years) pile of
> design garbage called procmail.

And use what, then?


-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Procmail filtering question

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

Am 26.05.20 um 12:36 schrieb Richard Kimber via Fetchmail-users:
> I'm running fetchmail -> procmail -> local directories read by Claws on
> Ubuntu 20.04
>
> I'm having some problems filtering email messages by Subject using
> procmail
>
> "Normal" text Subjects of the form:
> Subject: News on Coronavirus
> are no problem. But there are a lot of messages nowadays that are
> displayed in Claws as:
>
> Subject: Update from GOV.UK – Coronavirus Statutory Sick Pay ... etc
>
> but where the subject in the message itself is actually in the form:
>
> Subject:
> =?UTF-8?Q?Update_from_GOV.UK_=E2=80=93_Coronavirus_Statutory_Sick_P?=
> =?UTF-8?Q?ay_Rebate_Scheme:_service_availability_and_issues?= 
> (the above is all one line)
>
> Does anyone know if there is some generic way of ensuring that messages
> are passed to procmail in the "normal" format so that I may reliably and
> straightforwardly construct procmail matching rules (i.e. without
> having to inspect the message source each time)?

This has been a normal format since 1993 or so (RFC 1522, now RFC 2047).

Everyone just stop using that unmaintained (for almost 20 years) pile of
design garbage called procmail.
Procmail wasn't palatable in 1990, and isn't in 2020.

reformime (part of maildrop) can help with decoding, but I do not know
if it would do character set conversions into the current locale.

Also someone tell Ubuntu to update fetchmail to at least 6.4.4 everywhere...

Re: [Fetchmail-users] Procmail filtering question

[Chris P. <cpo...@em...>]

On Tue, 2020-05-26 at 11:36 +0100, Richard Kimber via Fetchmail-users
wrote:
> I'm running fetchmail -> procmail -> local directories read by Claws
> on
> Ubuntu 20.04
> 
> I'm having some problems filtering email messages by Subject using
> procmail
> 
> "Normal" text Subjects of the form:
> Subject: News on Coronavirus
> are no problem. But there are a lot of messages nowadays that are
> displayed in Claws as:
> 
> Subject: Update from GOV.UK – Coronavirus Statutory Sick Pay ... etc
> 
> but where the subject in the message itself is actually in the form:
> 
> Subject:
> =?UTF-8?Q?Update_from_GOV.UK_=E2=80=93_Coronavirus_Statutory_Sick_P?=
> =?UTF-8?Q?ay_Rebate_Scheme:_service_availability_and_issues?= 
> (the above is all one line)
> 
> Does anyone know if there is some generic way of ensuring that
> messages
> are passed to procmail in the "normal" format so that I may reliably
> and
> straightforwardly construct procmail matching rules (i.e. without
> having to inspect the message source each time)?
> 
> - Richard.

Are any of these helpful?


https://stackoverflow.com/questions/29715013/decode-the-utf8-to-iso-8859-1-mail-subject-to-text-in-procmailrc-file

https://www.mhonarc.org/archive/html/procmail/2015-10/msg00003.html


-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
09:37:29 up 22:36, 1 user, load average: 0.83, 0.72, 0.74
Description:	Ubuntu 18.04.4 LTS, kernel 5.3.0-53-generic

Re: [Fetchmail-users] Procmail filtering question

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

On Wed, May 27, 2020 at 12:39:57PM +0100, Richard Kimber via Fetchmail-users wrote:
> On Wed, 27 May 2020 14:33:40 +0300
> Peter Pentchev <ro...@ri...> wrote:
> 
> > ...but the whole point is that this encoding means that the subject
> > contains non-ASCII characters. There is no way to convert them to
> > ASCII.
> 
> But if it's utf-8 can't you use something like:
> konwert utf8-ascii

Even if you do something like this, even if you manage to figure out
a way to deal with characters that *do not exist* in the US-ASCII
character set (yeah, I can see that konwert may have some limited
capabilities of approximating them, but that sounds quite weird to me);
even if you manage to do that, you will not have the original message.
If you feed the modified message to procmail and it stashes it into some
mailbox/folder/whatever or passes it to another program, you will *not*
have the message that the sender wanted you to have. In some cases this
might not be so bad ("I don't care if a spam message has an extra quote
or not"), but in others, like verifying OpenPGP or S/MIME signatures,
it might be, how do I put it, bad :)

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] Procmail filtering question

[Richard K. <ric...@bt...>]

On Wed, 27 May 2020 14:33:40 +0300
Peter Pentchev <ro...@ri...> wrote:

> ...but the whole point is that this encoding means that the subject
> contains non-ASCII characters. There is no way to convert them to
> ASCII.

But if it's utf-8 can't you use something like:
konwert utf8-ascii

- Richard
-- 
Richard Kimber

Re: [Fetchmail-users] Procmail filtering question

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

On Wed, May 27, 2020 at 11:53:07AM +0100, Richard Kimber wrote:
> On Tue, 26 May 2020 16:39:04 +0300
> Peter Pentchev <ro...@ri...> wrote:
> 
> > Unfortunately, this is the most "normal" of the formats that you are
> > going to get with e-mail. Since none of the software that generates or
> > reformats e-mail messages along the way has any idea what other
> > software will be used to accept, transfer, or process the message,
> > none of it can rely on anything else being able to process anything
> > other than "simple" plain text with all characters being in the
> > US-ASCII character set. Thus, if somebody wants to include, say, a
> > pretty long dash or chevrons, the only way to do that is to use a
> > special format for encoding them, a special format for saying "this
> > here is a character that is outside the US-ASCII character set, I'll
> > tell you how it is represented in UTF-8, but since its UTF-8
> > representation itself depends on bytes that are outside the US-ASCII
> > character set, here's a marker that says that the next couple of
> > characters are base64-encoded representations of UTF-8 encoded
> > characters".
> > 
> > Anything that wants to process e-mail messages the way they are to be
> > displayed to the end-user should be able to decode MIME-encoded
> > content, including MIME-encoded header fields. And... unfortunately,
> > here we come once again to the "procmail is kind of outdated, it does
> > not really support a couple of things that are sort of essential in
> > the current world, is there any way you might switch to other
> > message-filtering software?" For example, it looks like at least
> > courier-maildrop may be configured to parse MIME-encoded headers:
> > http://courier-mail-server.10983.n7.nabble.com/Filtering-mails-with-UTF-8-headers-td18177.html
> > (and yes, I know that switching the mail filtering program is not
> > trivial at all, but procmail also has other problems, some of which
> > people have become accustomed to working around for decades...)
> 
> Thanks.
> 
> I was wondering, though, whether one could do something like
> mda '/usr/bin/formail -s <program that converts to ascii> | procmail'
> in the .fetchmailrc file.

...but the whole point is that this encoding means that the subject
contains non-ASCII characters. There is no way to convert them to
ASCII.

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] Procmail filtering question

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

On 27/05/2020 13.15, Richard Kimber via Fetchmail-users wrote:
> On Tue, 26 May 2020 16:39:04 +0300
> Peter Pentchev <ro...@ri...> wrote:
> 
>> Unfortunately, this is the most "normal" of the formats that you are
>> going to get with e-mail. Since none of the software that generates or
>> reformats e-mail messages along the way has any idea what other
>> software will be used to accept, transfer, or process the message,
>> none of it can rely on anything else being able to process anything
>> other than "simple" plain text with all characters being in the
>> US-ASCII character set. Thus, if somebody wants to include, say, a
>> pretty long dash or chevrons, the only way to do that is to use a
>> special format for encoding them, a special format for saying "this
>> here is a character that is outside the US-ASCII character set, I'll
>> tell you how it is represented in UTF-8, but since its UTF-8
>> representation itself depends on bytes that are outside the US-ASCII
>> character set, here's a marker that says that the next couple of
>> characters are base64-encoded representations of UTF-8 encoded
>> characters".
>>
>> Anything that wants to process e-mail messages the way they are to be
>> displayed to the end-user should be able to decode MIME-encoded
>> content, including MIME-encoded header fields. And... unfortunately,
>> here we come once again to the "procmail is kind of outdated, it does
>> not really support a couple of things that are sort of essential in
>> the current world, is there any way you might switch to other
>> message-filtering software?" For example, it looks like at least
>> courier-maildrop may be configured to parse MIME-encoded headers:
>> http://courier-mail-server.10983.n7.nabble.com/Filtering-mails-with-UTF-8-headers-td18177.html
>> (and yes, I know that switching the mail filtering program is not
>> trivial at all, but procmail also has other problems, some of which
>> people have become accustomed to working around for decades...)
> 
> Thanks.
> 
> I was wondering, though, whether one could do something like
> mda '/usr/bin/formail -s <program that converts to ascii> | procmail'
> in the .fetchmailrc file.

It is not that simple. The mail itself is already ascii, you would have 
to convert to utf8 to see a complete rendering of the headers. But 
procmail can't handle that.

If you force conversion to ascii of the headers, so to speak, how do you 
handle the characters in the headers that do not have an ascii 
equivalent? You have to replace with '*'.


The only thing would be grep patterns in procmail that would handle the 
headers as they come without conversion. I don't remember if procmail 
handles grep.


-- 
Cheers / Saludos,

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

Re: [Fetchmail-users] Procmail filtering question

[Richard K. <ric...@bt...>]

On Tue, 26 May 2020 16:39:04 +0300
Peter Pentchev <ro...@ri...> wrote:

> Unfortunately, this is the most "normal" of the formats that you are
> going to get with e-mail. Since none of the software that generates or
> reformats e-mail messages along the way has any idea what other
> software will be used to accept, transfer, or process the message,
> none of it can rely on anything else being able to process anything
> other than "simple" plain text with all characters being in the
> US-ASCII character set. Thus, if somebody wants to include, say, a
> pretty long dash or chevrons, the only way to do that is to use a
> special format for encoding them, a special format for saying "this
> here is a character that is outside the US-ASCII character set, I'll
> tell you how it is represented in UTF-8, but since its UTF-8
> representation itself depends on bytes that are outside the US-ASCII
> character set, here's a marker that says that the next couple of
> characters are base64-encoded representations of UTF-8 encoded
> characters".
> 
> Anything that wants to process e-mail messages the way they are to be
> displayed to the end-user should be able to decode MIME-encoded
> content, including MIME-encoded header fields. And... unfortunately,
> here we come once again to the "procmail is kind of outdated, it does
> not really support a couple of things that are sort of essential in
> the current world, is there any way you might switch to other
> message-filtering software?" For example, it looks like at least
> courier-maildrop may be configured to parse MIME-encoded headers:
> http://courier-mail-server.10983.n7.nabble.com/Filtering-mails-with-UTF-8-headers-td18177.html
> (and yes, I know that switching the mail filtering program is not
> trivial at all, but procmail also has other problems, some of which
> people have become accustomed to working around for decades...)

Thanks.

I was wondering, though, whether one could do something like
mda '/usr/bin/formail -s <program that converts to ascii> | procmail'
in the .fetchmailrc file.

- Richard.
-- 
Richard Kimber