On 11/27/2022 6:13 PM, Murray S. Kucherawy wrote:
On Sun, Nov 27, 2022 at 6:01 PM Dave Crocker <[email protected]> wrote:
Hmmm. Having looked through the RFC, for every occurrence of
'delivery', I don't see an obvious statement indicating it is a goal.
This is the citation I keep coming to, toward the end of Section 1.1:
DKIM operates entirely on the content (body and selected header
fields) of the message, as defined inRFC 2822
<https://www.rfc-editor.org/rfc/rfc2822> [RFC2822
<https://www.rfc-editor.org/rfc/rfc2822>]. The
transmission of messages via SMTP, defined inRFC 2821
<https://www.rfc-editor.org/rfc/rfc2821> [RFC2821
<https://www.rfc-editor.org/rfc/rfc2821>], and
such elements as the envelope-from and envelope-to addresses and the
HELO domain are not relevant to DKIM verification. This is an
intentional decision made to allow verification of messages via
protocols other than SMTP, such as POP [RFC1939
<https://www.rfc-editor.org/rfc/rfc1939>] and IMAP [RFC3501
<https://www.rfc-editor.org/rfc/rfc3501>]
which an MUA acting as a verifier might use.
I take this to mean the MUA is intended to be able to do the
verification, or at least that was our thinking back then.
Personally, I don't remember ever mentally considering DKIM to be a
transport-only mechanism, but kind of a lot's happened since then.
Yeah. I think that still fits within the place my reading landed on,
even without seeing that bit of text.
It's fine if we think this was in hindsight a bad posture to take, but
we should probably draw a line from there to here and give some
explanation that doesn't seem like we're arbitrarily contradicting
ourselves.
I think it was a reasonable posture at the time. First, because it
meant that the design of DKIM was such that its use did not require
infrastructure support. And I think that was enormously helpful for
early adoption.
But second because, well, gosh, we explicitly did not expect replay to
be the problem it has become.
So, more than hindsight is presentsight. Current use of DKIM isn't in
the MUA -- with rare exceptions -- and removal of the signature at
delivery is an easy way of closing one avenue for abuse. (And to the
extent some site deems it essential to retain the signature through
delivery, they can.)
I /do/ see a reference to wanting DKIM evaluation to be at the MDA
or MUA. Saying MUA does, obviously, imply surviving past formal
delivery. Hmmm...
The thing I'm noticing is that this is the only place (that I can
recall) where it's specific about which part of the ecosystem
constitutes a "Verifier". That is, 4686 says the Verifier might be
something using POP or IMAP to look at a message in a mailbox.
Meanwhile, I'm quite certain we wrote 6376 with MSAs and MDAs in mind
since that's where the implementations of the time were, even though I
don't think we explicitly said it must be thus. As it turns out, we
wrote a standard that can be, and is, successfully applied in any of
those places.
Going back to an earlier posting, I noted that a site that removes
the signature as part of delivery could provide an option to
retain it.
Making this only a recommendation certainly does have particular
advantages.
Indeed.
Note that this does not mean it can't be standards track. Merely that
statements about use need to be, ummm, flexible...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
