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

[Stephane Bortzmeyer]

On Mon, Jun 28, 2004 at 09:21:12AM +0100,
 Brian Candler <B.Candler at pobox.com> wrote 
 a message of 34 lines which said:

> So, we have problem X with Internet mail, and since we can't agree
> on a good solution for problem X, we try to fix problem Y instead?

If you look for *a* solution for the spam, you are certain not to find
it. Since spammers are human (foul and evil but human), they adapt and
every single solution is doomed to failure. Fighting spam means
combining several solutions, all of them incomplete and some not
perfect.

> Envelope senders are never used except when handling undeliverable
> mail; upon successful delivery, the only thing which happens is it
> may be recorded in a Return-Path: header, which is normally hidden
> from the end-user.

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.

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 doesn't affect what goes in the From: header at all, which is
> what the end-user actually sees.

DomainKeys, a non-LMAP protocol, tries to address this issue. So does
PGP. It creates its own problems, too, such as requiring cryptography
in the MTA.
 
> 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.

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.

For those who want to know more:

SPF (http://spf.pobox.com/) A very good site, with a lot of
information, code, HOWTOs, etc. The rapid adoption of SPF is because,
for a good part, the efforts of the SPF folks to provide help.

MARID (http://www.ietf.org/html.charters/marid-charter.html) For the
SUBMITTER extension to SMTP.

The ASRG (Anti-Spam Research Group) of the IRTF produced several
interesting Internet-Drafts about these
issues. draft-irtf-asrg-lmap-discussion-01.txt, by J. Levine, for
instance, responds to most of your arguments.