Hector, consider a mailing list as a publishing organization, which is what it is. If article submission happened via HTTP, say, like in web fora, there would be no reason to talk about From: rewriting. The fortuitous circumstance that both article submission and the final distribution happen through SMTP generated the current conundrum.
It presumably seemed to be easier or less intrusive to tag the Subject: and leave the From: unaltered. The correct approach should have been to use the publishing organization's own From:, possibly adding the author's name or initials to the Subject:. We only realize that mistake now, after the introduction of email authentication. Yes, we kept using the wrong arrangement for 40+ years. That is not a good reason to persevere. Best Ale -- On Thu 18/Jun/2020 21:01:29 +0200 Hector Santos wrote: > Alessandro, > > There are long time solid reasons why the "Local.From" field needs to > be stable. In particular, with local messaging, unless the local > system allows for anonymous entry of the Local.From field when > creating a Local message, there is a MUST for a 1 to 1 association > with the account. > > If local mail is exported for a external network, it doesn't matter > what mail network it is, you really don't want to introduce the idea > of allowing the changing of the Network.from field and making it > anonymous or disassociated with the original source. The domain is > associated with the source of the message, and the user part of the > address reflects the user account at the domain. There are good > reasons for that. Lets say the user is causing a problem on a remote > system. Using the network.From, the remote system could contact the > original system and issue a complaint. If we were "free" to remove > that idea, it be would harder to trace it. DKIM allows you to lock > that field down so that it can't be tampered with. > > You have to understand the long time pov of developers that have been > at this for 40 years. Every system I have worked, the different > networks, it was the same thing -- leave the from field alone! Do not > make it "anonymous" or capable of being an "unknown." > > Its the same for Instant Messaging, for Chatting, the TELEPHONE, the > Caller ID, etc, it is a TABOO to change the "From" entity. > > If you want to continue your line of logic to rationalize Rewriting, > then you need to make it "protocol complete" to help keep the > association of the From field with the original source intact. But > more importantly, it should have get permission from the original > domain in order to rewrite. This can be done with a DMARC tag extension: > > DMARC p=reject|quarantine ... rewrite=0|1 > > The default sides with highest security -- No Rewriting. But if the > domain wishes to allow for rewriting, then it should explicitly state > it in this policy record, rewrite=1. > > This is something I could possibly support IFF the originating domain > allows it. There would other things to consider to tie the loose ends, > but the #1, would be the rewrite=1 tag. > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
