On 28 Apr 2015 12:51:42 EDT,
"John R Levine" <jo...@taugh.com> wrote:
> > This is merely an attempt to find a mechanism whereby DMARC and MLMs could
> > cooperate, up to the point where subscriber Recipient validators could
> > honour an Author domain's p=reject, without removing the original author's
> > mailbox from the From header.
>
> Unless I've missed something, I don't see how this solves any of the well
> known problems. Bad guys can do whatever lists do, so you need to know
> whether to trust the list, at which point you might as well just trust the
> list and not mess around with the headers.
The main difference is that the original Author's message, including
5322.From, is precisely reproducible (modulo canonicalization changes) from
the message sent to the list, and will match the original DKIM-Signature
with the required 5322.From alignment. If it doesn't, the final Receiver
should do what RFC7489 says it should do: "[A]pply the most strict policy
selected among the checks that fail."
Yes, bad guys can do whatever lists do, but in this case, they'll need to
piggy-back on a recent DMARC-passing message sent legitimately to them from
the originating domain with a p=reject policy, and they'll have to include
that message in its entirety, including all the signed headers, in their
spam/phishing message; they can't simply replace the original message with
their own. It seems much easier just to open a disposable account at a
p=reject ESP and send the spam directly from there.
> Also, if you want to go down the sender + list route, how about that
> double DKIM signing hack? It has the advantage that it's invisible to
> MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code
> which probably comes from a library that Murray wrote.
I'll grant the advantage of invisibility to MUAs, but double signing has the
disadvantage that the originating signer has to know when to add a weak
signature with an fs=lists-r-us.com tag. What I'm suggesting doesn't need
the originating signer to have any special knowledge.
There's another, slightly labour-intensive approach (still dependent on
Murray's draft-kucherawy-dkim-transform-00, and an extra "stf=" tag for
subject tagging) that doesn't modify 5322.From:
1. The list keeps the original author's mailbox alone in the From header,
but makes the reversible transformations described, and adds a DKIM
signature with d=list.domain and tf= and stf= tags.
2. The "decorated" message is sent to list members with list-domain address
as Sender.
3. Recipient validators find an Author Domain signature that fails, and
a Sender Domain signature that is valid but doesn't align with the From
Domain.
4. Because the Sender Domain signature is valid and contains tf= and stf=
tags, Recipient validators reconstruct the original message and check
it against the Author Domain DKIM signature. If it passes, the message
is deemed to pass DMARC; otherwise it fails.
I'm not sure if that's an improvement on the multimailbox From approach,
but at least it leaves no burden for MUAs (unless they happen to be
validators).
MJA
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
