Re: [dmarc-ietf] Reversing modifications from mailing lists

[Alessandro Vesely <[e-mail]>]

Hi,

On Tue 23/Nov/2021 00:28:01 +0100 Wei Chuang wrote:
> 
> 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?


Sure.  Note that if the receiver trusts the MLM, simply recognizing it would be 
enough to pass DMARC per the "mailing_list" policy override.  ARC additionally 
provides the ability to learn the authentication status of the message when it 
was received by the MLM.  That way, reputation can be reckoned with great 
precision.


> 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.


I tried and implemented Murray's draft, but it requires that MLMs declare which 
transformation they do.  Since they don't, you need a pre-parser that guesses 
the transformation type.  That's the difference between the two drafts.

If there are two top-level MIME parts, the transformation must be (c), because 
no one writes a MIME structure with just one part.  Otherwise it's (b).


> 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.


Yes, l= could be a useful hint.

The risk of l= is that an attacker could exploit a poor HTML interpreter to add 
a part that completely hides the original content when rendered.  Requiring 
attachments to be plain text avoids that risk.


> 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.


Mailman can copy MIME structures without changes, but simple text is often 
re-encoded.  Many messages on this list are converted to base64.  If the 
original text was quoted printable, its form depends on the agent.  An agent 
can choose where to break lines, whether to encode some characters or represent 
them as ASCII, whether to break lines at column 76 or, to increase readability, 
at white spaces.  That can vary too widely.


> 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)


That's exactly the purpose of Author.  However, no one is using it yet.


> 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.


I don't get this, I'm afraid.  What is the subject suffix length?


Best
Ale
--