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