On Tue, Apr 20, 2004 at 01:19:26AM -0400, April Lorenzen wrote:
|
| This document offers a recommended standardized FQDN (Fully Qualified
| Domain Name) naming convention pattern for servers used to send outbound
| internet email. The purpose is to allow inbound internet email servers
| to recognize outbound email servers designated as authorized or
| unauthorized by those in control of DNS for the sending server IP addresses.
|
This is an interesting alternative approach to the MTAMark space.
On that note, 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.