Just out of curiosity - does anyone here disable rules like FORGED_AOL_RCVD
as a matter of course?
This rule assigns a 4.3 score to anyone who uses an AOL address through
another ISP/mail client, whether they "own" that email address or not. So
anyone with an aol.com address can't reliably use that address on their PDA
or cell phone. They can't use it to send mail from any other mail client
if they connect with a hot spot, or use some non-AOL broadband
connection. They can't use it in a send-this-page-to-a-friend form if that
form uses their address. They'll probably be able to send mail from AOL to
someone who has a forwarding account, but only if SA checks the original
Received: headers, which means SA has to be set to explicitly trust the
forwarding server or else trust all potentially-forged headers.
With the exception of reliance on Received: headers, how is this any
different from making SPF checks through SpamAssassin?
Well, here's one difference: If AOL ever alters their outgoing mail
servers - as Juno did last year - everyone has to update their SpamAssassin
config. On the other hand, with SPF or Caller-ID, AOL just updates their
DNS record and everyone gets the new config.
This SpamAssassin rule is just one example of the fact that people are
already making anti-spoofing checks on their own. But you have to choose
based on who's getting forged the most, and you have to figure out where
their legit mail is coming from. SPF, Caller-ID, etc. save you the trouble
of tracking down that information - and save you the trouble of tracking it
down again when it changes.
As Meng Weng Wong (the main designer of SPF) has repeatedly pointed out,
people are already making anti-spoofing checks based on local rules, and
services that rely on mismatching addresses and ISPs are already
breaking. Even if SPF, Caller-ID, DMP, RMX and all the rest die on the
vine, there will still be an impact on these types of email usage.
Kelson Vibber
SpeedGate Communications <www.speed.net>
as a matter of course?
This rule assigns a 4.3 score to anyone who uses an AOL address through
another ISP/mail client, whether they "own" that email address or not. So
anyone with an aol.com address can't reliably use that address on their PDA
or cell phone. They can't use it to send mail from any other mail client
if they connect with a hot spot, or use some non-AOL broadband
connection. They can't use it in a send-this-page-to-a-friend form if that
form uses their address. They'll probably be able to send mail from AOL to
someone who has a forwarding account, but only if SA checks the original
Received: headers, which means SA has to be set to explicitly trust the
forwarding server or else trust all potentially-forged headers.
With the exception of reliance on Received: headers, how is this any
different from making SPF checks through SpamAssassin?
Well, here's one difference: If AOL ever alters their outgoing mail
servers - as Juno did last year - everyone has to update their SpamAssassin
config. On the other hand, with SPF or Caller-ID, AOL just updates their
DNS record and everyone gets the new config.
This SpamAssassin rule is just one example of the fact that people are
already making anti-spoofing checks on their own. But you have to choose
based on who's getting forged the most, and you have to figure out where
their legit mail is coming from. SPF, Caller-ID, etc. save you the trouble
of tracking down that information - and save you the trouble of tracking it
down again when it changes.
As Meng Weng Wong (the main designer of SPF) has repeatedly pointed out,
people are already making anti-spoofing checks based on local rules, and
services that rely on mismatching addresses and ISPs are already
breaking. Even if SPF, Caller-ID, DMP, RMX and all the rest die on the
vine, there will still be an impact on these types of email usage.
Kelson Vibber
SpeedGate Communications <www.speed.net>