ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Taking responsibility for a message

2011-04-26 07:25:29
On 26/Apr/11 07:09, Murray S. Kucherawy wrote:
-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]

So with all that in mind, here's my suggestion for replacing the first part 
of
this section:
[...]
    o  Subject

    o  Date,

I guess Message-ID is among those "structural, not semantic" fields.
I concur.  However, we miss a field that says an MTA is _knowingly_
breaking whatever signatures may be present.

    o  To, Cc

    o  Resent-Date, Resent-From, Resent-To, Resent-Cc

    o  In-Reply-To, References

    o  List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
       List-Owner, List-Archive

Does List-Id deserve its own bullet?

I'd actually like to add Authentication-Results because an agent
that wishes to claim that observed authentication meta-data should
become part of the message core certainly should sign such a field,
but that's not worth recycling at Proposed and basically RFC5451
already says that anyway.

It is clear that when DKIM talks about "taking some responsibility",
it means it is the MTA as a whole who takes any responsibility, not
the signing agent.  Any field semantics might be documented in some
MLM-policy documentation, if there is a need to make it clear /what/
responsibility is being taken.

A-R is peculiar because it is often added by the very DKIM agent.
However, strictly speaking, the field is not added by the signer, but
by the verifier.

More confusion originates from the fact that MLMs keep lots of
original fields, including From.  I'd propose to replace the last
phrase in the last paragraph of Section 2.1 "Background", so that it
reads something like so, for example:

 The DKIM signing specification deliberately rejects the notion of
 tying the signing {DKIM 12} domain (the "d=" tag in a DKIM signature)
 to any other identifier {DKIM 12} within a message; any ADMD that
 handles a message could sign it, regardless of its origin or author
 domain.  In particular, DKIM does not define any meaning to the
 occurrence of a match between the content of a "d=" tag and the value
 of, for example, a domain name in the RFC5322.From field, nor is
 there any obvious degraded value to a signature where they do not
 match.  An ADMD can thus let an MLM add DKIM signatures to posts
 that originated from other domains, thereby asserting "some"
 responsibility for handling them.  The exact semantics of the signed
 contents is usually documented elsewhere.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html