[DShield] SPF is fundamentally flawed

Bruce Lilly blilly at erols.com
Thu Feb 19 13:55:58 GMT 2004


> From: "Erik van Straten" <emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl>
> Date: Wed, 18 Feb 2004 15:53:24 +0100

> As shown below, some AOL addresses are apparently permitted to BYPASS
> AOL's SMTP proxies. Regardless, like any major ISP, AOL has *customers*
> whose PC's are compromised. They *do* send spam (and probably viruses)
> to anyone in the world. AOL's proxy may block some of them, but
> definitely not all (my MTA is receiving their junk-bounces because my
> site is being Joe-jobbed by spammers).
[...]
> However, the second example shows that AOL -erroneously- "bounces" a
> spam to my site because it was not accepted by address.com (which could
> have very well been because of SPF records) ==> AOL's setup is flawed.
> 
> Note that it is VERY unfortunate for *me* that SPF has so many major
> drawbacks. In particular those sites that are being Joe-jobbed (like my
> site) would benefit from setting up SPF DNS records: I would be getting
> fewer bounces (December 2003: 160000 - provided that spam-recipient-MTAs
> would query SPF records and reject if Sender is not Permitted From).

SPF may indeed be flawed, but your complaint seems to boil down to the fact
that you are receiving non-delivery notices for messages sent to non-existent
addresses, giving a forged sender address.  That is due to poor design of
some MTAs, and/or use of intermediate SMTP relays, which has nothing to do
with SPF.  Nor is it a problem that SPF purports to address.

If mail is destined for a non-existent recipient (SMTP RCPT TO command),
the SMTP server is supposed to send a 5yz response code to the RCPT TO
command, and at that point the transaction fails, the client goes away,
and there is no message content to bounce.  Some poorly designed MTAs
instead issue a positive (2yz) response even for bad recipient addresses,
allow the client to send DATA that cannot be delivered, and then bounce
that DATA (the message) to the specified (i.e. forged) envelope sender
address.  This has nothing whatsoever to do with SPF.  The real problem
is the MTA design failure to give a 5yz response to RCPT TO which
specifies a non-existent recipient.  RFCs 821 and 2821 clearly discuss
the command sequence and appropriate responses; 2821 specifically
addresses some problems that can arise if an MTA fails to return a 5yz
repose to RCPT TO (unfortunately, the problem of a bounce to a forged
envelope sender address is not mentioned).

Another situation that leads to a bounce rather than an in-transaction
error response to RCPT TO is the use of intermediate relays. A relay is
an MTA that accepts a message for delivery which is neither sent from
nor destined for the domain for which the MTA is responsible. SMTP relays
almost always work in a store-and-forward manner.  Once the originating
SMTP client (usually an MUA, though it could be a worm or virus running
on a Microsoft platform) has had message sender, recipient, and content
accepted by a relay, subsequent failure necessarily involves a bounce
because the client has been assured of best-effort delivery and has
completed its transaction.

With a tiny bit of effort you can see what's broken.  You can complain
to the appropriate parties about the appropriate issues.

>    ----- Transcript of session follows -----
> ... while talking to ingoio.seanet.com.:
> 
>>>>RCPT To:<kcbacon at seanet.com>
> 
> <<< 550 5.1.1 <kcbacon at seanet.com> is not a valid mailbox. 550 5.1.1 <kcbacon at seanet.com>... User unknown
> 550 5.1.1 <kcbacon at seanet.com>... User unknown
[...]
> Reporting-MTA: dns; ledok.seanet.com
> Received-From-MTA: DNS; ACB5956A.ipt.aol.com
[...]
> Remote-MTA: DNS; ingoio.seanet.com
> Diagnostic-Code: SMTP; 550 5.1.1 <kcbacon at seanet.com> is not a valid mailbox. 550 5.1.1 <kcbacon at seanet.com>... User unknown
[...]
> Received: from e.okayama-u.ac.jp (ACB5956A.ipt.aol.com [172.181.149.106])
>         by ledok.seanet.com (8.12.10/8.12.10) with SMTP id i1ID1Zmg003999
>         for <kcbacon at seanet.com>; Wed, 18 Feb 2004 05:01:41 -0800 (PST)

ledok.seanet.com accepted mail for the non-existent <kcbacon at seanet.com> instead
of sending a 5yz response to the RCPT TO command issued by the client
ACB5956A.ipt.aol.com.  ledok.seanet.com then accepted the message and attempted
to forward it to ingoio.seanet.com which *did* issue a 550 response.  At that
point, ledok.seanet.com (which had accepted responsibility for delivering to
<kcbacon at seanet.com>) issued a non-delivery report sent to the forged sender
envelope address.  As ledok.seanet.com is an MX host for the seanet.com domain,
it should have rejected the bad recipient at the RCPT TO stage, avoiding the
message and the non-delivery report.  A polite discussion with the mail
administrator at seanet.com *might* get that problem resolved, but unfortunately
there are many similarly misconfigured sites.

> Reporting-MTA: dns; rly-ip05.mx.aol.com
[...]
> Final-Recipient: RFC822; captainlyle at address.com
[...]
> Remote-MTA: DNS; spam01.address.com
[...]
> Received: from  smtp-frr06.proxy.aol.com (smtp-frr06.proxy.aol.com [195.93.93.86]) by rly-ip05.mx.aol.com (v95.1) with ESMTP id RELAYIN2-340333816165; Wed, 18 Feb 2004 05:01:58 -0500
> Received: from dutndo7.tn.tudelft.nl (ACB6E656.ipt.aol.com [172.182.230.86])
>         by smtp-frr06.proxy.aol.com (8.12.10/8.12.10) with SMTP id i1EGVJ8E023116
>         for <captainlyle at address.com>; Sat, 14 Feb 2004 16:31:20 GMT
[...]
> X-Apparently-From: Blitz007513 at aol.com
> X-AOL-IP: 195.93.93.86

In this case, ACB6E656.ipt.aol.com sent the message to smtp-frr06.proxy.aol.com
which in turn sent the message to rly-ip05.mx.aol.com.  The latter detected the
error when attempting to send to the recipient's MX host, spam01.address.com.
The root of the problem in this case appears to be that smtp-frr06.proxy.aol.com
accepted the message from Blitz007512 at aol.com, but apparently failed to retain
that sender envelope address in the SMTP transaction with rly-ip05.mx.aol.com (or
the latter ignored it).  The latter then wrongly sent the non-delivery notice to
the (forged) address in the message "From" header field.  This once more has
nothing to do with SPF; it is simply misconfiguration of AOL's MTAs.  AOL has
recorded the originator id and IP address, so you can forward a complaint about
the original to abuse at aol.com. A separate polite discussion with AOL's email
administrators might result in getting their configuration problems resolved.
An alternate possibility is that the sender envelope address was in fact specified
as <jeadt at cpo.tn.tudelft.nl>, in which case smtp-frr06.proxy.aol.com is acting
as an open relay (since neither the specified sender nor recipient are in the
aol.com email address space).  Open relays are generally considered to be a major
contributing factor to spam proliferation, and are usually a bad idea. However,
there are legitimate cases where use of an alternate sender envelope address is
appropriate, so it's not a clear-cut case of misconfiguration; AOL may simply
be accommodating their users' needs.  In any event, with three AOL machines
involved, at least one is acting as a relay unless the SMTP transactions are
taking place simultaneously in lock-step, which AFAIK is not done. When there
is a relay involved and a non-existent recipient, a non-delivery report (rather
than an SMTP error code to the originator's SMTP client) is virtually
inevitable (that's another reason why relays are a bad idea).

Incidentally, ledok.seanet.com is also acting as a relay (though not an *open*
relay) in your first example.

As you can see, SPF is not involved in these examples, and moreover could not
possibly solve the issue that you are complaining about.  What's more, the
presence of "?all" in AOL's SPF TXT record means that any IP address might
legitimately send email claiming to be associated with an AOL user (e.g. a
mobile user accessing the Internet via a wireless access point or an Internet
cafe); it simply means that AOL does not provide authoritative verification
of addresses other than the ones explicitly listed.

It's also quite a bit of a stretch to consider either this issue or SPF to be
a security issue, so it's not at all clear why this was posted to the Dshield
list in the first place (vs. e.g. the ASRG list).




More information about the list mailing list