Considering that there is tons of operational considerations to making
even the smallest change in DKIM, it seems to me that a recharter ought
to justify *why* the listed problems have an operational impact and
whether it is reasonable to believe that there is an actual solution to
them. Considering that the wg flamed out last year about replay stuff, I
think that's very pertinent as to why anybody thinks that anything has
changed in the last year.
In particular:
Known difficulties caused by multi-hop email delivery include:
• If a message is modified after DKIM signing, it is not possible to determine
what was modified, or which hop made which changes.
• The SMTP RCPT TO address might not be present in the signed header fields of
an email, meaning that the same message can be sent to arbitrarily many
recipients, and those recipients can not tell if the signer intended to them as
recipients.
• Similarly, a message with the exact same DKIM signature can be legitimately
received by multiple recipients at a single domain, meaning that tracking
signatures is not sufficient to determine whether a message is being replayed.
• The SMTP MAIL FROM address can be forged, meaning that accepting an email
and later sending a DSN to that address can cause backscatter, making it hard
to perform asynchronous content analysis or delay delivery while collecting
more signal; leading to the use of greylisting as a suboptimal workaround to
delay making a determination.
1) Why would knowing the changes in a message be useful? I have my own
thoughts here, but the point is that it seems to me there needs to be
some operational justification. Ie, "if we knew the changes we could do
XYZ".
2) About Rcpt-to: why would knowing this be useful? And why is knowing
it a DKIM problem? If it's useful for DKIM, it could be useful for other
things I would think.
3) The word "replayed" is sort of a red flag, imho. Are we really trying
to take a bite out of that apple again? If so, what justifies another
go-round? Do we know something new from last year?
4) Again: DKIM doesn't have anything to say about the envelope. DKIM
works on headers and the message body. If getting some alignment between
the envelope layer and the message layer is useful, is that really a
DKIM problem? Wouldn't it better to just have a new header(s) and DKIM
can just sign it like normal?
To achieve its goals, this work requires a wide scope. The group may need to
supersede, modify, or replace many parts of the current email infrastructure
and associated reporting mechanisms.
I have to say when I saw this it looked pretty ominous to me. What
bounds on "email infrastructure" are we talking about? Any at all? Isn't
that pretty important that the full email community has a say on its
bounds? What is off limits?
Of all of them, (1) seems like the most likely to have a path to being
solved (maybe we could use diff instead of l= and z= or something) but
the rest seem pretty vague as to why we believe there is any solution or
why a solution is justified in the first place. If we're going to get
sucked into "trust us" by vendors/MAAWG who can't/won't say anything
about their operational issues, then we seem to be pretty much the same
boat as last year.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
