AOL says no to Sender ID, but yes to SPF

fighting email spam

[tedster]

The back and forth about Microsoft's Sender ID technology continues. For those of us looking for a "real" solution to email spam (and who isn't?) this is an area to pay close attention.

The Sender Policy Framework (SPF) portion of the plan in particular looks to be gaining wider adoption and deploying SPF records can already make a difference in getting your emails through.

AOL will now not be moving forward with full deployment of the Sender ID protocol," spokesman Nicholas Graham said in a statement sent via e-mail yesterday. Instead, the Dulles, Va.-based Internet service provider will support only the sender policy framework (SPF) to fight spam by verifying the source of e-mail sent to its users, he said....AOL is concerned about the lack of acceptance for Sender ID in the open-source community, Graham said. Additionally, the ISP is afraid that recent changes to Sender ID will make it incompatible with the original SPF specification, he said. AOL had endorsed Sender ID when it was submitted to the IETF in June.Full Story on ComputerWorld [computerworld.com]

[marcs]

SPF is flawed, IMHO, as it relies on domain owners providing DNS entries. That's like saying, add the record to your zone file and we'll trust you not to spam.

All spammers need to do is set up domains, add their SMTP server to the SPF list for the domain and spam away. Domain registration is too easy/cheap.

It will also do a number on email forwarding. The sending/forwarding server is not likely to be listed in the SPF record for the sender (From field).

[moltar]

A lot of spam is sent from infected users' computers via trojan applications.

[py9jmas]

All spammers need to do is set up domains, add their SMTP server to the SPF list for the domain and spam away. Domain registration is too easy/cheap.

That's not the point. They have to pay for a domain. Within, what? hours? minutes? that domain will be on every RBL out there and will be worthless. It makes spammers accountable. It stops them from abusing other people's domains. It helps prevent phising.

It will also do a number on email forwarding. The sending/forwarding server is not likely to be listed in the SPF record for the sender (From field).

I wonder if that is why they came up with the Sender Rewirting Scheme? ;-)
[libsrs2.org...]

[pmkpmk]

SPF should not be the only defense. As wall as SpamAssassin should not be the only defense. As well as Razor/Pyzor/DCC should not be the only defense.

Use them ALL together!

First, let your mail-agent check for the obvious: unresolveable adresses, faked headers, directory attacks, etc. Everything obvious gets thrown away or rejected right away.

THEN check it for viruses. If it has a virus, inform the sender and throw it away.

THEN look for SPF information.

THEN pipe trough (at least) Razor, better trough DCC and Pyzor as well.

THEN ceck if it's on any RBL.

THEN run it through a Bayes filter, and maybe some others (even the good old "Bad Words" filter is still useful).

THEN have a look at the results and form a majority vote: an email flagged as SPAM by all tests above geths thrown away. An email flagged by only a few gets flagged only and passed to the user.

We use this concept for some time now. The overall majority of SPAM gets rejected by the first line of defense. What passes has a typical detection rate of 98% without producing false positivis. We rather settle for 1-2 untagged spams a day in order to avoid false positives.

[coopster]

Apache says no to Sender ID as well. From the Apache News page ( [apache.org...] ):

2004, September 2: Open letter [apache.org]: Issued to the IETF MARID Working Group [ietf.org] regarding the ASF's position on Sender ID.