On Jan 18, 2008, at 12:45 PM, Michael Thomas wrote:
Douglas Otis wrote:
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.
I'm sorry, but we're writing a security protocol here. Spammers
don't obey real laws, let alone care about 2822 arcana. You might as
well just put all your eggs in the RFC3514 basket.
Valid DKIM signatures only ensure which domain introduced the message.
RFC 2822 compliance is completely a separate matter.
When a signing domain decides to make the signature's on-behalf-of
clear, they can do so without needing SSP. If you think ambiguously
signed messages by the From domain represent a security risk, you must
not depend upon SSP to make this decision for you. This would be
depending upon the same entity that ambiguously signed message.
Ambitiously signed messages represent legal and valid signatures,
since DKIM is _not_ about identifying the individual per the charter,
nor should this become a requirement of SSP.
When SSP makes a policy assertion of "all" or "strict", this should
only establish a requirement for the domain of the signature. Call it
the validated responsible domain.
What difference would it make when the i= parameter to contains an
opaque value not associated with any header contained within the
message? Remember, DKIM is not about identifying individuals. What
security risk do you envision when there are multiple email-addresses
within the same domain, but where the i= is not included within the
signature? Why would it be safe to assume the signature is on-behalf-
of any specific identity in that case?
Keep in mind, you are describing something well within the control of
the signing domain. What risk are you concerned about?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html