At 08:31 AM 1/25/2007 -0600, Seth Goodman wrote:
David MacQuigg wrote on Thursday, January 25, 2007 7:08 AM -0600:
> They already provide this information to big companies like Yahoo.
> They just need to publish it in a form that is easily accessed. SPF
> records are almost sufficient, and we use them to create default
> records, but they are just a little short of what we need for a
> robust HELO check. So we ask senders who offer SPF authentication
> to go one more step and publish "helo=spf" at _auth.<domain>. The
> incentive is an immediate improvement in their reputation, because
> we can then reject the zombies using their name.
Comcast doesn't care if smaller domains say Comcast's mail will be less
deliverable if they fail to take the action du jour. Some small system
operators already make such personal statements with zero impact. If a
provider has enough customers to matter, they are unable to decline mail
from any other large provider, regardless of technical merits. Unlike
the situation of CompuServe of the 1980's, Comcast and friends can
currently deliver their mail, and even the current spam load does not
appear to threaten that.
We don't reject mail from senders with a low reputation. We just process
it like any other receiver, using the best available IP blacklists and spam
filters. This is an important difference between our system and most
others. Our authentication/reputation system provides a benefit, without
incurring any new losses. About half my legitimate mail is now
whitelisted. I expect this will approach 100% as our sender database grows.
The situation in the early 80's was extreme, with users having to maintain
multiple accounts at different ISPs. We seem to be moving in that
direction now, with senders having to jump through a different set of hoops
for each big receiver. I had to convince Yahoo that I knew how to operate
a mailing list, because that was the closest category they had for one of
my small domains!
It's hard enough to convince large providers to keep their public list
of outbound servers (SPF record) up to date. Asking them to publish yet
another record under an arrangement that is not widely supported is
unrealistic and will only hinder SPF adoption.
The Registry is in no way competing with SPF (although it does offer an
alternative to those who absolutely refuse to publish an SPF record). We
are doing everything we can to encourage the use of SPF. See "Using SPF
Records to List HELO Addresses" at
http://open-mail.org/files/Notes_for_Senders.htm Our latest change was to
add the "helo=spf" option, thereby avoiding the need to duplicate
information that is already in an SPF record. Suggestions for further
changes are welcome, although at this point, it seems as simple as it can
get, short of SPF providing a HELO option.
I believe the reason large senders don't keep their SPF records up to date
is that it doesn't affect their deliverability. Spammers have not made
much effort to forge HELO names, so if we use a sender's entire IP block in
a default record, the result is the same.
Another problem is that big ISPs seem to treat SPF records not as
protecting their name (authorizing only a few servers), but as advertising
how big they are (authorizing thousands of servers). Hotmail.com, for
example, authorizes 981504 servers in 37 IP blocks!
Both these problems can be solved if and when spammers start forging HELO
names. Our message to senders will be simple, but powerful.
Sorry! We cannot guarantee delivery of this message. <your domain> does
not have sufficient reputation for <recipient>.
We will run it through our spam filter, and keep it in our quarantine, but
the recipient may not read it.
See http://open-mail.org/rejects for help.
Note that we avoid putting ourselves in the position of making
policy. Nobody can blame us for a false reject. Our role is to enable
*recipients* to set their own thresholds for reputation, and communicate
clearly to senders the consequences of a low reputation.
-- 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