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

[Brian Candler]

On Mon, Jun 28, 2004 at 10:35:11PM +0430, Stephane Bortzmeyer wrote:
> There are very good reasons to use as "purported responsible domain",
> the domain of the MAIL FROM, not the one of the From: Mailing lists
> and greeting-cards Web sites are two typical reasons.

If you trust this information when processing a spam report, then you are
not doing your job properly (with or without SPF). What you *can* trust is
the IP address in the Received: header from a trusted host. Certainly that's
a pain to parse out, and maybe a system which recorded that information in a
cryptographically-strong form would be worthwhile.

> True, the end-user does not see it. But when he reports a spam, with
> all the headers (we can hope one day users will send the complete
> headers to abuse@), you have more infomation. The LMAP (Lightweight
> MTA Authentication Protocol) family of protocols, SPF and the others,
> do not stop spam, they just create an ecosystem which is more
> transparent, less gullible and less practical for the spammers.

It won't make an ounce of difference.

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. 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

That's in addition to any domains which I legitimately own and control SPF
information for, of course.

Since all the SPF information is published in the DNS, it is absolutely
trivial for me to find thousands of domains which I can use to send out
forged mails.

That's unless AOL requires SMTP AUTH for mail sent via its relays, but then
it would need to maintain some kind of registry of which domains are
permitted to be sent via each AUTH account. Otherwise, I could not send out
mails using a non-AOL address which I legitimately own (like
B.Candler at pobox.com)

> > Worse, SPF breaks common and legitimate uses of E-mail, like
> > forwarding.
> 
> I'm certain that you know the difference between forwarding (which
> keeps the email enveloppe, such as ~/.forward) and remailing (wchich
> does not, such as procmail's |sendmail) but some people on the list
> may not.
> 
> So, yes, SPF, the current SPF, not all the LMAP family, breaks
> forwarding but not remailing. The two services are different but, in
> most cases, users do not care and could switch from one to the other.

I'm sure there are plenty of people like me who think that SPF is a stupid
idea, but even if I decide not to implement it, people who *do* implement it
will break my mail. That's just incredibly impolite.

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

SPF belongs in the problem set, not the solution set.

> Anyway, both SPF (with SRS, Sender Rewriting Scheme) and the MARID
> group (the IETF working group which is trying to produce a standard
> LMAP propocol) with the SUBMITTER extension to SMTP will solve the
> problem and enable forwarding again.

And how exactly do you stop spammers putting forged SUBMITTER information in
SMTP? Maybe that won't be a problem when all ISPs on the planet require SMTP
AUTH for relaying, *and* all ISPs on the planet are competently managed and
trustworthy (when Hell freezes over). Besides, if we required SMTP AUTH from
everyone on the planet, we wouldn't have a forgery problem in the first
place.

I have not yet seen a coherent view of "the end game": i.e. this is what
mail will look like after these proposed changes have been made, and why
E-mail will be better in this new world. Instead, people are proposing
making a bunch of changes, well-intentioned, but painful; afterwards, the
spam problem will be no better, but E-mail will be less reliable.

Brian.