On Jan 17, 2008, at 11:33 AM, Jim Fenton wrote:
Arvel Hathcock wrote:
Hi Jim!
Yes, but suppose that the Sender header were used only when the
domain found therein matched one of those in the From. Then it
would disambiguate the process allowing SSP to know precisely which
of the multiple domains involved in authorship purports to be that
which posts the message to the mail stream.
This would not help in cases where the Sender: domain is entirely
different from any found in the From: but at least it would address
the root concern found in issue 1525. That is, it could no longer
be said that SSP requires the first author to be the poster (which
is the meat of issue 1525) and this issue could perhaps be closed?
But we have to handle the case where the Sender: domain is entirely
different as well. We can't just be silent on this case.
The requirement would be the Sender headers email-address domain must
be at or above the From email-address domain's policy to be compliant
with "all" or "strict". This is not being silent.
The choice of first From: domain is, as the draft notes, a largely
arbitrary one. I don't have a problem with using all of the domains
in the From: header field, other than whether we need to impose an
artificial limit on how many SSP lookups per message we do, and how
to handle the case where that is succeeded.
I do have a problem with just using Sender in the multiple From
case. Sender has different semantics than From, so using From under
some circumstances and Sender under other circumstances does "break"
the semantics defined in RFC 2822.
Agreed. Having the Sender domain impose policy would be problematic.
Cases in which there are multiple addresses in the From: and no
Sender: are inconsistent with standardized practice and the spec
could handle those just as it would messages that have no From:
header at all. I don't know.
I'm not worried about what we do with messages that violate 2822.
But I do want to make sure that we cover all the cases that are legal.
By only using the From domain(s) to establish policy, the MTA is free
to decide about these types of RFC errors. IMHO, the identity within
the i= parameter does not need to associate with any header. When the
key is unrestricted, the only significant element with respect to
compliance would be the d= parameter of the signature.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html