ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

2011-03-29 10:12:19
On 3/28/2011 11:27 PM, Jim Fenton wrote:
1. "authors and their organizations" could be misinterpreted ...

I'm with Dave.  It looks clear ro me that it's a list of examples.

     "The Signer MAY choose to use the same namespace for its AUIDs as its 
users' email addresses or MAY choose other means of representing its users. 
However, the signer SHOULD use the same AUID for each message intended to be 
evaluated as being within the same sphere of responsibility, if it wishes to 
offer receivers the option of using the AUID as a stable identifier that is 
finer grained than the SDID."

I suggest that the first sentence change MAY to "might" in order to make it 
non-normative.

I further suggest removing the second sentence "However...".  It is giving 
(normative) usage guidance for something that it has already made out of scope.

I'd also take out the INFORMATIVE NOTE.  It's an opaque token, so a
signer can do anything with the mailbox part of that token that it
wants.  With a d=example.com, you could equally well use
i=bob(_at_)example(_dot_)com or i=@bob.example.com.  They're different names, 
but
receivers can infer equally little from each of them.


The closest I can come to what you describe in Section 6.3 is:

     "If the SDID is not the same as the address in the From: header
field, the mail system SHOULD take pains to ensure that the actual
SDID is clear to the reader."

Good lord, no.  My users don't see SDIDs or any other part of a DKIM
signature.  That goes in the same bit bucket with the advice to
display the signed and unsigned parts of the message in different
colors.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html