ietf-dkim
[Top] [All Lists]

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

2008-01-17 10:49:50
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?

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.

Arvel

Jim Fenton wrote:
Arvel Hathcock wrote:
The debate here is whether or not it's mission-critical for SSP to use From: in all cases or whether some other sender identity (like Sender: header) could be used to equal effect generally or in specific cases (like when there are multiple addresses in From).

Given that it would solve the problem described in 1525 and also bring us closer to a consensus position perhaps this thread should discuss what is lost through utilization of the Sender header in at least some cases.


Good idea, Arvel.

Suppose that an attacker wanted to spoof a message from the domain statements.bigbank.com, a domain having a Strict Sender Signing Practice that is used for transactional email. Attacker sends the following message:

Date: Wed, 16 Jan 2008 15:49:44 -0600
From: BigBank Statements <statements(_at_)statements(_dot_)bigbank(_dot_)com>, BigBank Security <security(_at_)statements(_dot_)bigbank(_dot_)com>
To: John Doe <jdoe(_at_)(_dot_)(_dot_)(_dot_)>
Subject: Account alert
Sender: bot(_at_)example(_dot_)com



As currently composed, this message would not be SSP compliant because the SSP retrieved would be that of statements.bigbank.com (Strict) and the attacker would not have the ability to create a valid signature for that domain.

Now suppose that the Sender header field is used for the SSP lookup. Since example.com doesn't have an SSP record, it would be Unknown and this spoofed message would be SSP compliant. Depending on the MUA being used, the recipient of the message is likely not to notice that there is a Sender: header field at all.


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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