[dmarc-ietf] Reversing modifications from mailing lists

[Wei Chuang <[e-mail]>]

Hi all,

[Standard disclaimer, that the comments below are my own and don't
represent my employer at all]

I saw Ale's draft draft-vesely-dmarc-mlm-transform
<https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform> in
the ARC list, and wanted to discuss some of the ideas.  Just to put in
context my points- My understanding is we have to trust the forwarders to
use the ARC authentication results, which we might not have because the
forwarder is new, or has low volume.  Moreover mailing lists do much of the
modifications that break DMARC.  This is a common enough scenario that I
think it's useful to consider alternatives such as the ideas found in Ale's
draft.  The numbered bullets are ideas summarized from Ale's draft, and
asterix * bullets are my comments about that.

1. Ale's draft suggests not reversing all possible transforms, and rather
focuses on a subset caused by mailing lists that are reversible
  * Could ARC be suitable for those other scenarios? Could we expect that
forwarders that do more substantial irreversible rewriting such as
modifying URLs in a spam/phishing filter MTA, already have a strong
relationship with the receiver?  Presumably, might they be trusted by the
receiver and their ARC result could be used?
2. Footers must only be added with as a) append on single text/plain part
b) mime part appended to multipart/mixed c) mime wrap where a footer is
added in a new multipart/mixed.
  * It's not very clear to me how Ale's draft handles the b) and c)
scenario.   (There is mention of "reason="transformed"", but this still
seems incomplete)  I saw that Murray has a draft
draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> that
identifies addition of new mime parts that could be helpful there.
3.  Footers added to text/plain must be identified with at least four "_"
as a separator.
  * Would the DKIM length "l=" field be helpful?  Understood there are
abuse risks.
4. "quoted-printable encoding must not be used for... single-part
text/plain messages, as it is impossible to guess original soft line breaks
after re-encoding"
   * Are you suggesting quoted printable encoding aren't fully reversible?
Actually, could the RFC2045 canonical encoding of the message be used as
the source for doing the DKIM content hashing?  This would bypass having to
worry about additional transfer re-encodings by forwarders.
5. Finding the original FROM by looking at From, Author, Original-From,
X-Original-From, Reply-To, and Cc.
  * Can this be standardized to a fixed location such as Author?  (Sorry
I'm unfamiliar with the discussion on Author)
6. Subject
  * Agreed that some simple heuristic as proposed in the draft is a good
approach.  Perhaps the original subject suffix length also might work here
too.

Comments and discussion are very much welcome.
-Wei