ietf-dkim
[Top] [All Lists]

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

2008-01-18 14:42:34

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

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