Below I've summarized, for each type of identity we're considering
securing, what the identity is used for, the benefit we gain from
widespread implementation, and the current use cases that are broken by
widespread implementation.
Nice summary. A few comments...
In my experience, spammers are quick to adapt to changes in the
ecosystem--much more so than many legitimate users. It is unlikely that
protecting any of these identities will result in more than a temporary
reduction in the volume of spam, it will merely change the attack
vectors that spammers use.
* HELO/EHLO domain
- Used in constructing the Received: header
Which can then be checked by recipients.
Given wide deployment:
Spammers/viruses will use domains over which they have control or
through which they're able to relay.
* MAIL FROM (Return-Path:)
- Used for the recipient of bounce mail
Given wide deployment:
Unrelated third party domains which assert a policy will not receive
bounces from forged return paths. Such bounces will instead go to
domains controlled by spammers, domains through which spammers are
able to relay, domains that don't assert a policy, or to the empty
return path.
It is probably worth nothing that this does not break most list expanders
since most override the MAIL FROM.
Alias expansion across domains will be broken. There exists at least
one proposal for a new type of expansion to replace alias expansion for
cross-domain use.
Desired forging (by some mobile/wireless deployments, etc.) of return
paths will be broken.
* From: header
- Used by recipient to identify author
Given wide deployment:
Domains that assert a policy will not appear in the From: header of
forged email sent through servers not listed in the policy.
List expansion will be broken for mail sent from domains that assert a
policy. For this reason, it is expected that few domains would assert
such a policy.
Desired forging of From: will be broken.
Sender:
Checking only Sender: makes little sense since it is an optional field that
many (if not most) messages lack. I assume what's being proposed here is to
check Sender: if it is present and From: if it is not.)
- A subset of recipients will know to use this in preference to From:
for identifying the sender of a message
Given wide deployment:
Domains that assert a policy will not appear in the Sender: header of
forged email sent through servers not listed in the policy.
List expansion will be broken for mail sent from domains that assert a
policy. For this reason, it is expected that few domains would assert
such a policy.
Alias expansion will also be broken.
A way to "fix" this would be for alias and list expanders to be altered to
insert a Sender: field. (Some list expanders already do this, but many others
do not, and whether or not it is a good idea has been the subject of a
long-running religious debate in email circles.)
Desired forging of Sender: will be broken.
There's one other alternative that needs to be on the list: Perform a check of
Resent-from: if it is present and From:. The analysis isn't materially
different from the From:/Sender: checking case.
Given these tradeoffs, I would say that protecting the MAIL FROM
(Return-Path) is of the most value. After that, protecting the From:
header is of potentially greater value to a much smaller set of domains.
Protecting HELO/EHLO is of negligible value, as the HELO/EHLO value is
not used for anything important.
I concur with this conclusion.
Ned