On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Actually same message to same destination may be
sent to different MTAs (e.g. different MXs with same weight).
2.3 Canonization must be better defined. It's usual for MTA to e.g.
lowercase the domain of recipient.
Our default is to leave the case of addresses alone by default, but sites
often
do configure things to "right case" their business name. That said, Early
validation would avoid such issues for us. I think.
Long ago some MTAs use to mess with the case of the domain names in the
envelope. Assuming some of them are still out there, wouldn't we want to
fold everything to lowercase (or uppercase; pick one) before doing the sort?
All problems except 2.1 may be fixed by adding additional header, like
e.g.
DKIM-Transport-recipients
which contains salted hashes (with some random salt) of all recipient
addresses, and require this header to be added to DKIM signature and
existence for every recipient's address' hash to be checked in this
header. It is compatible with any current DKIM implementation.
If you're talking about hashing all recipients together, then I don't see
this
solving all the problems except 2.1.
And if you're talking about hashing them separately, then why would you
insist that they all be present?
I think he's trying to avoid being clobbered by an envelope that gets split
downstream. If you as a verifier have the full original recipient set,
then all you care about is that your recipient set is a subset of the
original set.
But limiting the number of recipients to 1 when this extension is used
would be
a much simpler approach. Of course there's some overhead involved in doing
this, but given the idiotically limited spam report mechanisms in place at
some
sites single copy may be a requirement already.
It's also the most common use case in threat space, as I understand it.
Finally, my biggest concern here is that this, like most proposals that
involve complex linkages between the header and envelope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least
some of this spills over to both implementations and operational policy.
Indeed; I don't think that's avoidable if we want to try to tackle this
problem versus punting it back up to layers 8 and 9. But maybe that's the
best thing one can do.
Can we really expect people to get this right?
I wonder that every time I write a draft anymore. :-)
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html