[ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first
Author breaks email semantics
fenton at cisco.com
Wed Jan 16 16:54:13 PST 2008
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
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.bigbank.com>, BigBank Security <security at statements.bigbank.com>
To: John Doe <jdoe at ...>
Subject: Account alert
Sender: bot at example.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
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.
More information about the ietf-dkim