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.
It has been argued that, since this working group (and perhaps all of
IETF) doesn't have expertise in UI design, the MUA should not be
considered at all. While I agree that IETF probably shouldn't be
designing user interfaces, I believe that it is entirely reasonable for
us to make design decisions based on observation of the way that
existing user interfaces do behave. Not to do so results in protocols
that are irrelevant because they don't solve real world problems.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html