[afnog] Re: AOL rejecting hosts with no rDNS?

[Brian Candler]

On Tue, Jun 29, 2004 at 10:56:02AM +0200, Alan Barrett wrote:
> On Tue, 29 Jun 2004, Brian Candler wrote:
> > If I am a spammer and I send through (let's say) AOL, SPF lets me send
> > out MAIL FROM:<> any domain which permits AOL's mail relays as its
> > sender.
> 
> Yes.  So, as the manager of the foo.example domain, I can prevent you
> from sending mail through AOL's mail relays that purports to be from
> anybody at foo.example.

Sure. In other words, that restricts the range of domains which a spammer
can use for forged envelope senders, but it's only a minor inconvenience to
the spammer.

In the olden days, spammers sent out mail with
MAIL FROM:<abcdef at tuvwxyz>

People thought: "aha! all spam has invalid domains on the RHS of MAIL FROM.
So I can block spam simply by validating the MAIL FROM: domain." It's a
cheap test, so everyone turned it on; it became the default for many MTAs.

So what happens? Spammers now use real E-mail address as the MAIL FROM
address, which makes the problem worse.

Now people say: "aha! all spam has forged domains on the RHS of MAIL FROM.
If I can detect these forgeries I can block all spam".

However, if/when SPF comes along: all the spammer has to do is pre-filter
their list of MAIL FROM: addresses to select ones which have SPF policies
which allow origination from the IP address of the system they're about to
relay through. This is a cheap DNS lookup for the spammer. Spam volumes
might be reduced for a few weeks, until the spammers implement this.

In the very best case scenario: all mail sent via AOL will end up with
@aol.com on the end of the MAIL FROM address. You won't be able to
distinguish AOL spam from AOL non-spam.

(But in practice, I think there will be many thousands of domains for the
spammer to choose from when relaying through AOL relays)

> > So I can send out:
> > 
> >    -  MAIL FROM:<>
> >    -  MAIL FROM:<anyrandomuser at aol.com>
> >    -  MAIL FROM:<anyuser at domain>  where domain belongs to a AOL customer
> >    -  MAIL FROM:<anyuser at domain>  where domain does not list SPF policy
> 
> Since this is (hypothetically) going through AOL's relays, AOL can
> impose much stricter limits than are implied by the SPF records.

Well, they can. But then they will break me (B.Candler at pobox.com), who has a
legitimate address which I want to use. Or else they will need a local
policy database where I register this address (which they will have to
manually check belongs to me), *and* I will have to use SMTP AUTH so that
they can associate this address to me.

Then, when I roam to a different ISP, I will need to re-register my address
in *their* local policy database, and so on.

However, my understanding of the SPF world view is that AOL doesn't care
about other people's domains; all they care is that other people can't use
aol.com. So they are unlikely to implement such a local policy database,
because no direct benefit accrues to AOL by doing so.

> > Now, if SPF stood a chance in a million of reducing spam, breaking my
> > mail might be worth it, but it doesn't.
> 
> SFP stands a change of reducing joe jobs.

It would only start to have a visible impact if it were to reach >90%
coverage of ISPs and domains.

However, there are much simpler and far more effective ways of reducing joe
jobs. If you send out mail with a cookie in the envelope sender (like SRS
does), then you can reject bounces to mails which you didn't send. You get
instant protection from joe jobs, without having to wait for anyone else on
the Internet to do anything, and without breaking mail.

So I think an important thing missing from most discussions is an accurate
problem statement; from that you can start to pick appropriate solutions.

> > I have not yet seen a coherent view of "the end game"
> 
> Nor have I.

Then we agree on something :-)

Spam is really annoying and I have some sympathy for the view "we must do
something, anything", but it doesn't really stack up logically unless you
have an idea of where you're trying to get to.

Cheers,

Brian.