On Sun, Nov 27, 2022 at 6:01 PM Dave Crocker <[email protected]> wrote:

> On 11/27/2022 5:48 PM, Murray S. Kucherawy wrote:
>
> Post-delivery survival of the signature is not only not a goal, it is
>> arguably (or possibly demonstrably) a problem.
>>
>
> Can we say more about this if we're going to take that position?  A naked
> "not a goal" doesn't jive with RFC 4686, which explicitly says it is a
> goal, or at least that it was one.
>
> 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 in RFC 2822
<https://www.rfc-editor.org/rfc/rfc2822> [RFC2822
<https://www.rfc-editor.org/rfc/rfc2822>].  The
   transmission of messages via SMTP, defined in RFC 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.

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 /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.

-MSK
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to