On Jan 18, 2008, at 11:54 AM, Frank Ellermann wrote:
Michael Thomas wrote:
What about the situation where you have multiple From addresses and
no Sender (or a sender that doesn't correspond to any of the From
addresses)? This might not be legal 2822, but spammers don't care
about that.
The first case isn't legal, it's IMO no job for SSP to specify what
implementations / receivers do with syntactically invalid mails.
Agreed.
Invalid => do what you like (it could be first author).
The second case is legal (ditto Resent-* and domain literals).
I've no idea what to do, nobody here liked the proposal to use the
PRA, many don't like to use the Sender (if it's not one of the From-
domains), "toss a coin" (Message-ID or 1st author or Reply-To) is
unconvincing => SSP has to give up, receivers can treat it like a
single 2882-From with a domain literal.
There is a domain within the signature that should be used to assess
compliance. What prevents a valid signature of the From domain from
allowing a message to comply with "all" or "strict"?
Why attempt to have SSP define permitted values of the i= parameter
for compliance. With the one proviso of excluding a g= restricted
key, _any_ signature where the domain would be valid when signed on-
behalf-of the From header email-address, these signatures alone should
be considered compliant with "strict" or "all".
What gets displayed by the MUA is not a problem for this WG, but this
display problem is not any different than when the i= parameter is
excluded from the signature and there are multiple addresses within
the same domain.
There is no need to search for any purported responsible domain. This
is the function of a valid DKIM signature. When the signing domains
desires to make it clear which identity is being signed on-behalf-of,
this is an entirely separate matter that should not be an issue for
SSP to handled. Clearly, the signer is able to convey this choice
without the use of SSP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html