Thanks for the feedback and answers. On Wed, Nov 24, 2021 at 3:01 AM Alessandro Vesely <[email protected]> wrote:
> 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. > If the RFC2045 canonical representation at the final destination can be the same as the canonical representation at the original sender, (and assuming there isn't some content modification like adding inline footers etc). then that might be a way of side stepping some of the issues with quoted printable encoding. Understood that would be a departure from DKIM/ARC hashing and verification. > > > 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? > Sorry I wasn't too clear here. It's largely the same idea as the DKIM body length "l=" field above except for reformulated for the Subject header and its mailing list mutations. The original sender would encode a length of the original subject say "s.l=<value>". A receiver would only hash the right most "s.l=<value>" length string when validating a Subject hash from the original sender. This assumes that mailing lists may prepend a string typically for identification. thanks again, -Wei > > Best > Ale > -- > > > > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
