ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor breaks email semantics

2008-01-16 13:33:30
Frank Ellermann wrote:
Michael Thomas wrote:

  
Whereas SSP began as a simple idea as a means of deciding whether
an unsigned message should have been signed, it has morphed into
an effort to validate the From field.  That is a very, very 
different goal.
      
 
  
This is revisionist history. I've pointed to both of the historical
documents of IIM and DK which directly contradict you.
    

For other historical documents compare RFC 822, 733, and 724 (1977).
It was always the idea that you could tell me what to send in your
your name (from: you, sender: me), maybe I'm unable to sign in your
name, but I could sign that I'm the sender.  
  

Mike and Dave were referring to the history of the SSP proposal, not the history of Internet mail.  The question is whether the SSP proposal has changed in this respect.  I don't think it has, and I have not seen any evidence that it has (quotes from previous revisions of the SSP draft).
 
What we do (in this hypothetical example) is perfectly legal, no
matter what the owner of the domain in your address likes better.

Admittedly multiple authors are rare - as far as I can judge it -
but the mail standards since RFC 724 guarantee that there MUST
be a Sender in this case, we're not forced to sort the authors in 
the From header field.  This has consequences, RFC 4409 option 8.1 
offers to get the Sender right, it does not offer to sort authors.
  

The roles of sender and author are different.  The fact that a Sender header field is required when there are multiple authors is not an assertion that the sender is, in fact, an author.  It's merely a consequence of the fact that the sender (agent responsible for the actual transmission of the message) cannot be inferred from the From header field in this case.

SSP seeks to determine the author's policy.

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>