Michael Niedermayer via ffmpeg-devel (HE12025-10-16): > As we all certainly know, this ML since a few months rewrites > all "From:" headers to "X Y via ffmpeg-devel <[email protected]>" > We changed this because neither me nor timo nor rather unhelpfull AI > could fix the bounce & dmarc issue
Hi. I do not know about mailman's configuration, but in the recent months I have been trying to find a solution to the problem of forwarding mail to former users, and I can share what I understand of the issues at hand. (Spoiler: there is no solution, monopolists have effectively broken unconditional forwarding addresses. People being able to use their resources without showing it in their address, people being able to leave by just changing the target of the forwarding address, that was not what the monopolists had ordered.) Emails have to pieces of information that indicate who sent them. There is the “From:” field in the header of the mail data, called without originality the “header from”: it is presented to the user and used to send replies (unless there is a reply-to header). And there is the sender passed through the MAIL FROM command of the SMTP protocol, called “envelope from”: it is used to report errors through the infamous “mailer daemon” mails. When forwarding an email, a system can alter anything in its data. It can also pass the envelop from as is to the next hop or replace it by an address of its own (any other option being absurd). Usually, one will keep the envelop from when forwarding to a single person, so that an error on the destination is reported to the author of the mail, and one will replace it when forwarding to multiple persons. Mailing-lists do that: Sympa uses $listname-owner, Mailman seems to use $listname-bounces. All this used to be open-bar: any server could send with any envelope or header from. That was a feast for spammers. Over the years, various anti-spam measures were added, and are being enacted by large operators, which makes it necessary to comply with their constraints if we want our email to reach the customers of these operators. SPF uses the DNS to publish a list of IP addresses allowed to send mail for a certain domain. It controls the envelop from. It can encode a more-or-less strict policy, up to the instruction to reject mails coming from an IP not listed. Mailing-lists take ownership of the envelope from, they are not affected by SPF provided their own server is properly configured. For individual redirections, there is a scheme, Sender Rewriting Scheme (SRS), where the envelop from is replaced with one from the local system using a reversible transform of the address, and messages arriving back are forwarded back by reversing the transform. DKIM uses cryptography to authenticate the body and part of the header of the mail by putting a big signature in the header. The signature indicates which domain is signing the mail, and the DNS is used to distribute the public key. The standard does not specify what must be checked, therefore DKIM does nothing to help with spam: the spammer just signs the email from their domain. Any service that alters a mail while forwarding it, like a mailing-list adding “[ffmpeg-devel]” in the subject line, will break the signature. What they are expected to do is to add a signature of their own, from their own domain, and possibly a signature telling that it checked the original DKIM signature and it passed. DMARC is not a new mechanism by itself but a way to publish a policy to tie SPF, DKIM and the contents together. There are cosmetic options, but the core of it is that the domain of the envelop from, the domain of the header from and the domain of the DKIM signature must match, i.e. be equal or subdomains of each other. Note that the large operators are increasingly putting pressure on everybody to force adoption of these standards. One of their methods is the blackmail “if you do not set your DMARC policy strict enough, we will start considering mail from your domain as spam”. This things is here for good, unfortunately. What I deduce from all this is that we cannot hope to keep “From: [email protected]” in the mails sent from our mailing-lists: it will only work if their-domain.org has SPF and DMARC policies lax enough, and these will vanish. The new scheme where the header from is replaced with the address of the mailing-list seems unavoidable. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
