ietf-dkim
[Top] [All Lists]

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

2008-01-16 12:52:18
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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>