Re: Not usable email content encoding

[Florian Weimer <fw@deneb.enyo.de>]

* Frank Ch. Eigler:

> Hi -
>
>> > The key here is to realize that the raw message is not what you get
>> > back from the mailing list reflector, and also not the raw message
>> > that was sent by the sender.  In this day of mta intermediaries,
>> > proxies, reflectors, it may be time to revisit that suggestion.
>> 
>> But these largely are new problems.  It used to work flawlessly.
>
> I understand that's frustrating.  But these workflows were counting on
> literally unspecified behaviours not changing, or outright standards
> violations continuing.

Delivery of each individual message is unspecified as well, but we
still count it to happen.  I'm sorry, but I think this argument sounds
a bit vacuous.  With our own infrastructure, we should be able to get
it to behave in the way we need.

>> Patch reencoding problems go back to the redhat.com changes last
>> November (I understand the responsible vendor is working on a fix,
>> but I'm not up-to-date on the current developments).
>
> This one is a standards-compliant reencoding.  Even if mimecast (?)
> stops doing it, we can't be sure nothing else will.

But it's rather unusual in the RFC 822 world, especially with the
decline of sendmail and its peculiar 8BITMIME handling.  I understand
that you get a lot of this in the corporate mail world originally
influenced by X.400, but such messages are rarely handled by
sourceware these days, probably because people rather use Gmail than
wrestle with their inadequate corporate email.

>> Since the sourceware.org Mailman migration, the From: header is being
>> rewritten, without any compelling reason.  I certainly do not do any
>> DMARC checking here, so the rewriting does not benefit me.
>
> It benefits you because more and more email services are rejecting or
> interfering with mail that is not clean enough.  If you want to
> receive mail reliably, or send and have confidence that it is
> received, clean mail benefits you.

It's definitely not cleaner after Mailman has applied its destructive
header rewriting.  It just replaces one address spoofing with another.

What are the plans for Mailman on sourceware?  Will it be replaced
soon with something else, given that the software stack it runs on is
effectively EOL?

It should not be too hard to add a configuration option where
subscribers can opt out of header rewriting, but with Mailman's
upstream status, I'm not sure if that's a worthwhile effort.