At 11:04 AM 1/27/2007 -0600, Don Lee wrote:
SPF provides enough information to prevent certain kinds of forgery.
Let's focus on those uses of SPF that provide precise, reliable data, and
how those can be used.
HELO checking is a good example. I think there is consensus that this is
safe and effective, and can be deployed immediately everywhere without pain.
I think we should push this. It does *not* constitute
a particularly effective ant-spam policy, so it should not be oversold,
but it can be very effective in blocking spam bot-nets and the like that
forge HELO names.
I can vouch for the safety and effectiveness of HELO checking, even for
senders who do not publish their authorized transmitting addresses. Our
default record for rr.com, for example, includes over a million addresses.
24.24.0.0/14 262144
24.28.0.0/15 131072
24.30.128.0/18 16384
24.30.192.0/19 8192
24.92.160.0/19 8192
24.92.192.0/18 16384
24.93.0.0/16 65536
24.94.0.0/15 131072
65.24.0.0/14 262144
65.32.0.0/15 131072
65.34.0.0/20 4096
66.74.0.0/15 131072
Totals: 12 1167360
Even with this many opportunities for zombies to find a permissive network
owner, we don't see much abuse of their HELO name. It will happen, of
course, but when it does, I expect rr.com to remedy the situation by
authorizing only the few dozen addresses they really need to say "HELO this
is rr.com".
In checking MAIL FROM: , there are lots of issues with forwarding, SRS, etc.
Hence the spirited conversation on this list. This is great.
I suggest a simple, efficient hierarchy in authentication tests:
1) Check HELO to verify an entire session with a sender. Senders with
sufficient reputation need no further checks. All mail in that session can
go directly to the recipient's inbox.
2) Check MAIL FROM on each non-whitelisted message where the Return Address
domain differs from the HELO domain. Again whitelist any that qualify.
3) Check the contents of the message using DKIM, or whatever other method
the sender might offer.
4) Run the remainder through the usual IP blacklists and spam filters.
It's safe, because there are no losses other than what would occur without
the HELO check. It's effective, because senders can authorize their own
transmitters without any conflicting requirements by
forwarders. Forwarders can authorize their own transmitters, or they can
make specific arrangements with the sender to use the senders HELO name.
We should step back and focus on what SPF _can_ do reliably
and with precision, and reduce our focus on what it does not do well.
I would like to see wide adoption of SPF as a useful tool. Chasing
corner cases and forwarding issues detracts from this goal.
SPF could expand its scope to include a robust check of the HELO name, but
until that happens, SPF authorized senders can simply publish "helo=spf" at
_auth.<domain>, and anyone using our Registry take that as permission to
REJECT any use of their name that doesn't pass the HELO check.
-- Dave
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735