On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin
<dubrovin(_at_)corp(_dot_)mail(_dot_)ru>
wrote:
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)
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.
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 same message to same destination may be sent to
different MTAs (e.g. different MXs with same weight).
Yes the current text in the document already calls all of those issues out.
2.3 Canonization must be better defined. It's usual for MTA to e.g.
lowercase the domain of recipient.
That's a good point.
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.
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)
Also an interesting idea.
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.
If you do asymmetric encryption, with or without a distinct selector,
aren't you basically doing the same thing I'm proposing, other than where
it gets recorded in the message?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html