1. This standard is not backward compatible with existing DKIM
implementations. It makes it useless. In addition, in it's current form
it can not be implemented in most MTAs (see below)
It wouldn't work at all in our MTA without modifications because our general
filter interface currently receives recipient addresses after some processing
has been performed. We could add an option to change that fairly easily, but as
you note, that doesn't address all the issues.
2. This standard mixes transport standards (SMTP) and message standard.
There are multiple issues as a result of this:
2.1 Same message may have multiple recipients on different MTAs while
each MTA only sees it's own recipients. So, destination MTA can not
verify signature, because it doesn't know all recipients. This can be
fixed if message to every destination is signed independently, but it
breaks existing mail flows, because in most cases message is signed
before placing to MTA queue.
We have sufficient flexibility in this regard to sign late (and as noted
above, verify early), and we can split by destination before signing
each variant separately.
What would be much more difficult is detecting this usage and turning off
splitting where feasible to avoid breaking the signature. That would be very
difficult.
The bottom line is that at best this will be very fragile, at worst it will
fail a significant percentage of the time.
2.2 Recieving MTA may e.g. limit the number of recipients and single
message may be sent to different final recipients on the same MTA in
multiple session as few different messages, each message with partial
list of recipients.
Actually, this quickly turns into a hairball. The minute the receiving
system starts 4yz'ing some recipients the precomputed signature is going
to be rendered invalid and will have to be recomputed.
And how does the receiving MTA know when do this? It gets no indication
that it's dealing with this particular DKIM variant until after recipients
are processed. So it's only choice would be to do it unconditionally, or
to try and keep track of senders who use this feature.
Yuck.
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.
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?
2.1 can also be solved in this case, but it disclosures BCCs of the
message (even if this header is removed before delivery to mailbox)
Prior to delivery the bcc's are disclosed by being present in the envelope. So
as long as the sender adopts the approach of splitting by destination before
signing, only including the recipients for a given copy in the signature, and
the receiver removes the field prior to final delivery, I think it might
work.
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.
All problems may be solved by using asymmetric encryption instead of
hashing, e.g. require domains with support for this standard to publish
some public key (or to use special DKIM selector) via DNS record and
encrypt recipient's addresses in the additional header with public key
and only sign recipients for systems with this key published.
Yes, and that's really cute. Considerable overhead though.
P.S. I just did a quick look into standard, sorry if I missed or
misunderstood something.
So did I, and so do I.
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.
Can we really expect people to get this right?
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html