Ed Greshko writes:
Yes. For some reason I can't fathom it seems the mailing list
software turns every Content-Transfer-Encoding to base64
It's just "old fashioned stupidity" far beyond the ken of today's
users inexperienced with the details of the global mail system. Let
Mailman needs to decode text/* parts of the message body to check for
administrivia directed to the list, to decorate it (mostly to add a
footer), and to manipulate MIME structure (quarantining .exes and the
like). When it forwards to the MTA, it normally chooses the Content-
Transfer-Encoding from the RFC-mandated ASCII and BASE64 otherwise. I
am not familiar with the rules used by Mailman 3, offhand.
Mailman is not an MTA to negotiate SMTP options like 8BIT and UTF8,
and doesn't know what any of the MTAs are, not even its own. It needs
to be compatible with them all, and there may be thousands of
instances of dozens of programs involved. So Mailman uses the least-
common-denominator standard that can handle all messages, which is RFC
5322 and RFCs 2045-2049. (Fortunately it doesn't mess with addresses
at all, so it doesn't need to know about IDNA and friends.) If the
MTA wants to be smarter than that fine by us, but we have to handle
everything the world spews out, so we reduce to the most compatible
protocols we know.
There remains mail software in active use, such as fetchmail, which is
still not RFC 6531-conforming.
Weird. If it were something on the mailing list side you'd
that everyone would see the same issue.
Agreed 100%. If messages were personalized (eg, a personal link to
Postorius in the footer), I'd only be 99% confident (it's possible
there are weird interactions between the charset of personalized
material and that of the main text). But users@ doesn't personalize,
and the footer is pure ASCII AFAICS, so that isn't it. Another
possibility would be if the mail had text/html content type: Mailman
delegates conversion to plain text to external software such as Lynx.
But all the example messages were text/plain, so that's not it.
I'm 99% sure that this is not a Mailman issue, but rather a problem
with MUAs that don't format the message correctly or don't interpret
it correctly, or MTAs that translate inaccurately when converting
(this might include spam or virus checkers, especially the latter
which frequently modify message bodies). Nevertheless, "when the
impossible is eliminated, what's left, however improbable, must be the
truth." Feel free to contact mailman-developers(a)mail.python.org if
it begins to seem more likely that Mailman is causing the problem
somehow, maybe somebody's heard of something like this.