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.
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
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.
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:
- 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.
Desired forging of Sender: will be broken.
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.