Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Dave Crocker <[e-mail]>]

On 5/31/2019 3:59 AM, Douglas E. Foster wrote:
> Agency and signatures are well understood legal concepts.   3000 years 

The signature at issue here is done with DKIM.

Are you sure you are clear about the what the agency is it vets and what 
the scope of use for that vetting is?  I suspect you are assuming a 
different type and scope of authentication than DKIM is intended to 
perform.  It's not that your goal is unreasonable -- and indeed, s/mime 
and openpgp seeks to perform it -- it's that DKIM wasn't designed to do 
that.  DKIM was designed for use during tranfer to the point of 
delivery.  For this discussion, that means to the list processor (mailbox)


> ago, people sealed their letters with a signet ring stamped in warm 
> clay.   Signing technologies have changed in that time, but the 
> principle has not.   A courier is responsible for keeping the signed and 

Please note my earlier point about delivery and re-posting.  That 
implies a role for list processing that is considerably more than a 
courier's.


> sealed part of a message unaltered.   Envelope marks are acceptable.
> A digital signature is supposed to provide non-repudiation.  If I submit 

DKIM is a transfer-level signature.  That is, really, MTA-MTA (or, 
really, MTA-MDA).

A list processor is an MUA-level actor.  (cf, RFC 5598.)


> There are some obvious use-cases for MTA changes to a message, and we 
> would do well to document and address them.

Perhaps, but that's not at issue here.


> The first that comes to mind is MTA comment fields.

Huh?


> - A spam filter wants to add a tag indicating that the message is 
> suspicious, but not sufficiently suspicious to be blocked.
> IETF would do well to specify a mechanism for MTAs to add information 
> which MUAs present to the user, while identifiying that that the 
> information came from the MTA rather than the original sender.

You mean like adding a header field, outside of the ones signed by DKIM?

That's already permitted.  It's one of the reasons that the signer gets 
to decide what header fields to cover.

However, it looks as if you think presenting such information to users 
will be useful.  It won't.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net