ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Responsibility vs. Validity

2007-11-29 15:23:04

On Nov 29, 2007, at 1:36 PM, Jon Callas wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


If the i= tag does not "mean something", and the verifier cannot make use of it for any purpose, then what on earth is the point of having it in the standard in the first place?

It is there for the signer to relate the message back into their own framework. It is there so that *when* you get a complaint about a message, you have more to go on.

Let us suppose that the DKIM signer writes out log messages with a monotonically increasing numbers for each message it signs. That number is a perfectly fine thing to put in i= because it lets the signer know who did a bad thing. (Or whose message was used as a bad thing.)

Agreed.

However, by including the scope= parameter, both you and Jim can be satisfied. When Jim and Frank achieve identity authentication (where the i=<localpart> is asserted to be an indicator of authentication), this would ensure proper message filtering and annotation. Knowing whether intra-domain spoofing is prevented does have value. Of course, the DKIM group could insist this feature not be allowed, where identity authentication is limited to S/MIME and OpenPGP. When added as an SSP scope= parameter, this assertion allows a few to indicate they are authenticating the identity associated with the email- address. The scope= approach also makes it clear when _no_ assumptions should made about authentication of the identity associated with the email-address. Clarifying this issue via policy assertions would be safer approach. Otherwise, people are likely to try anyway and make wrong assumptions.

AFAICS, it does not mean much, but at least is should mean that whatever user of domain is present in that tag was known to have played some part in bringing that message to the signer.

Who says there has to be a domain in the tag? In the example I gave, it can be a number.

Agreed.

-Doug
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html