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

[Michael Thomas]

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.  
>  
> 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.
> 
> If you think that's all obsolete nonsense 2822upd needs to say so, 
> so far all proposals to deprecate at least Resent-* failed.  It's
> plausible to envision an architecture where one of the two Sender-
> functions are replaced by a logical order of authors.  But how can
> SSP get the world to follow this idea, when folks are used to the
> similar Sender-solution for over 20 years ?

This is all rather beside the point. The current draft doesn't
"break" 2822, it merely limits the applicability of SSP itself. SSP
has lots of other limits of applicability that are completely
unrelated to 2822 as well. That's sort of the point of the protocol
in fact: to give guidance as to what limitations a receiver should
expect. I see no reason why we need to get permission or changes
from 2822upd for SSP's own applicability.

		Mike