On Tue, Apr 20, 2004 at 12:19:07PM +0100, Spf Pobox wrote:
|
| Seems most, if not all of it is covered by SPF, though it requires
| a SPF record for every A record to achieve, I think.
|
| Also getting admins to configure mail servers to existing RFC's is
| bad enough.
|
This is an interesting alternative approach to the MTAMark space.
I would like to mention that our single most successful antispam rule at
Pobox is "does it look like a broadband host". We can tell if a machine
is a broadband host simply by checking if the hostname contains the IP
address. Broadband machines usually PTR to something like
6535215hfc174.tampabay.rr.com
c-24-8-173-129.client.comcast.net
In a way, this kind of hostnaming scheme is analogous to the .mxout. and
MTAMark concepts, except that it's already in place and doesn't need
much new work. You just have to write a handful of heuristics that
capture most of the broadband conventions in use today :)
In the future I plan to implement a very simple antispam algorithm that
works like this:
1) is the MAIL FROM in an RHSBL? If yes, reject.
2) does SPF pass? If yes, accept.
3) does it look like a broadband host? If yes, reject.
Most zombie machines get blocked by #3.
Legitimate linux hobbyists get through due to #2.
Spammers who publish SPF get blocked by #1.
Voila! Everybody's happy.
Linux hobbyists who send mail legitimately from their home machines
controls their virtual domain; the onus is on them to publish SPF
accordingly. It's something they can proactively do, and don't mind
doing.
Spammers can publish SPF (and some already do, as expected) but because
they (in theory) show up on RHSBLs, that doesn't help them.
Zombie machines that forge MAIL FROM get blocked by #3.
Note that SPF is not being used here as an instrument of rejection; it
is an instrument of acceptance. Even if the world does not implement
SRS, we still manage to stop zombie spams and viruses.
Of course, the algorithm doesn't work so well for spam from non-zombie
boxes --- spam sources that are colocated at spam-friendly providers.
But other tools, like DNSBLs, work for those cases pretty well. And if
SRS sees widespread adoption, SPF can be used for denial there.