On 6/21/2020 3:44 PM, Douglas E. Foster wrote:
Dave Crocker writes:The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email address. This is helpful for identifying the three key stakeholder needs: 1) MLM's such as IETF want to alter the author's submission. 2) Authors like Hector want their submission left unmodified
List Servers has historically modified submissions, the body and subject line. It is part of the "package" per se. Burned in. While problematic for DKIM, I doubt that will ever change.
However, my only concern has been always with the RFC5322.From address rewriting kludge when done in a blind way. If the MLM is aware of DMARC, then it is intentional ignorant of a security protocol. While it may have been done in certain legacy distributions, it was not a common practice for List Servers to rewrite the 822/2822/5322.From field. What was "rewritten" was the return address for errors & bouncing back to the MLM list agent.
A kludge is by definition (by Google) "an ill-assorted collection of parts assembled to fulfill a particular purpose." We ideally view a kludge as a temporary solution until a real fix is obtained. But as we have learned by practice, a kludge, a temporary solution left unaddressed, has a tendency to become permanent. So if the IETF is going to sanction this kludge, then we should get it officially IETF reviewed, documented, and not via some highly subjective wiki primarily authored by one person who believed this was the right thing to do without foreseeing the consequences.
3) Users like Dave want accurate author information in the MUA. There is no legal corollary for "largely-unmodified". If I use whiteout on a signed document, spill an ink bottle on hallf of the signature, or replace the special lawyer-only staples with standard staples, the document ceases to be trusted and is probably unenforcable. The nature of the changes made by the IETF mailing list renders the reverse transformation impossible, so there is no way to validate the transformed document against the original unless the original is obtained, yet the purpose of the transformatiin is to hide the original. A real solution has to eliminate this operation. Hector is right.
Imo, the resigner performing the rewriting, SHOULD resign using a secured resigner domain with the same level protection sought by the original author domain.
This would be consistent with the ietf.org only rewriting for domains with a p=reject|quarantine DMARC policy. It uses _dmarc.ietf.org for the rewriting domain. Since this _dmarc.ietf.org domain only exist for rewriting a p=reject|quarantine domain, it would be technically logical for _dmarc.ietf.org to also have a p=reject|quarantine policy as well. This includes using _dmarc.ietf.org for the return address to kept with the expected DMARC alignment. That will maintain the DMARC aligned protection for the original submission and resigner distribution.
-- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
