Message-ID: <ILEPILDHBOLAHHEIMALBEEABFBAA.jasonc@science.org>
Date: Sun, 16 Mar 2003 20:54:50 -1000
From: "Jason Coombs" <jasonc@...ence.org>
To: <lonnie.brown@...ledger.com>, <bugtraq@...urityfocus.com>,
   <full-disclosure@...ts.netsys.com>
Subject: AOL's Billion SPAM March on Cyberspace


Aloha, Lonnie.

Your article: "ISPs Seek Bigger Mallet To Eliminate Spammers" caught my
attention.
http://www.theledger.com/apps/pbcs.dll/section?Category=COLUMNISTS0203

I'm an information security and computer forensics expert with detailed
technical knowledge of SPAM and the technology employed by spammers.
Recently I authored a report on SPAM delivery via AOL -- where a spammer
gains access to the Internet for the purpose of delivering SPAM to other
people elsewhere on the Internet. Considering the topic of your recent
article for The Ledger, I thought you'd be interested in reading this
report.

AOL is being ridiculous when they suggest that their billion SPAM march on
cyberspace does any good whatsoever. In fact, AOL is being downright
deceptive in their assertion that blocking inbound SPAM on behalf of their
subscribers who use @aol.com e-mail addresses is a virtue: AOL blocks SPAM
sent to their subscribers without AOL's permission (paid 'advertisements'
are sent to AOL subscribers with AOL's full support) but AOL does NOT block
SPAM that AOL users send to people who use OTHER ISP's e-mail services.

AOL may as well capture those billion SPAM messages and relay them to
non-AOL subscribers because this is exactly what the end-result is of AOL's
alleged attempts to curtail SPAM. AOL has positioned themselves to be a
facilitator of SPAM transmission to non-AOL subscribers while simultaneously
trumpeting their technical triumph over SPAM that originates elsewhere on
the Internet and is destined for an AOL subscriber's mailbox.

Your readers would be interested to know that anyone with an AOL account can
send SPAM to any other AOL account and AOL will NOT block it. On the other
hand, some ISPs are now blocking ALL e-mail that originates from AOL because
of these very issues.

Sincerely,

Jason Coombs
jasonc@...ence.org

--

A Report on SPAM Blackholes, Blocking/Filtering, and AOL

For the last month I have purposefully used AOL for SMTP server mail relay
in order to analyze the real-world impact of blackhole lists. AOL not only
does not block outbound SMTP from dialup customers, they operate a
transparent proxy farm that intercepts all outbound SMTP traffic and
intentionally relays this traffic on to its intended recipient (but not its
intended SMTP relay point -- you can configure ANY remote IP address as your
SMTP server and AOL's proxy farm will still do your delivery for you based
on the MX records present in the destination domain, you need not find an
open mail relay to exploit nor set up authorized/authenticated SMTP service
with any third-party service provider in order to relay SPAM through dial-up
AOL Internet service).

The results have been quite interesting. To summarize, only a few of my
outbound e-mails have been blocked by blackhole sites in the last month. All
e-mail sent to mailing lists such as bugtraq has gone through successfully.
Every rejected message has been returned to me with an explanation (thank
you, blackhole-enabled servers, your deterministic failure mode made this
experiment possible because I didn't have to worry about whether my e-mail
simply disappeared silently and could take corrective action to see that my
recipient received my message through other channels).

The most interesting failure I encountered was to my own domains. For e-mail
service we use a third-party service provider, the same provider who does
our Web hosting on Linux-based servers running Ensim (www.ensim.com). By
default our service provider refuses all inbound mail delivery based on a
blocking filter rule (not a blackhole service). This blocking filter
considers ALL e-mail from AOL to be SPAM and refuses it. This isn't just
e-mail relayed from a dial-up address block, this is ALL AOL e-mail. No user
of AOL was able to send e-mail to our domains until we requested that
inbound filtering be disabled.

It's also interesting to note that my Reporting-MTA FQDN
"mail.jasoncoombs.com" does NOT have an A record or a PTR or any other DNS
records associated with it. This doesn't bother AOL's SMTP proxy farm, and
it likewise did not bother a single SMTP server that relayed or received my
e-mail during this test.

My conclusion is that blackhole servers and filtering are a terrible way to
deal with the problem of SPAM. Few people actually benefit from these
techniques. They introduce unnecessary deterministic failure rather than
unnecessary nondeterministic failure therefore they offer their own helpful
work-around instructions. By informing the sender that their e-mail did not
go through, they automatically ("oracle"-like) produce a comprehensive list
of target domains that are protected by blackhole services -- a list that
any spammer would use to relay SPAM from a different point of presence.

Blackhole-enabled services should switch to a non-deterministic failure mode
that silently kills e-mail delivery. This would have a far greater effect,
and it would prevent spammers from easily discovering the extent to which
their SPAM is being automatically discarded systematically. It does not
appear to be a *good thing* for Non-Delivery Reports (NDR) to be generated
by blackhole-protected SMTP servers because it turns them into blackhole
oracles.

And the oracle says very few people use blackhole services.
Filtering/blocking is a superior solution, and it's very interesting to note
that AOL is getting filtered/blocked in its entirety by many SMTP servers.
This causes only minor problems in the real world because NDR are reliably
generated by AOL SMTP servers and delivered reliably via the AOL mail
network to the AOL subscriber who attempted mail delivery to a
filtered/blocked node. Anyone worth communicating with offers a Web site or
published telephone number that can easily be discovered by senders who find
themselves blocked, and the net impact is short-term DoS that reroutes
communication to more reliable failover routes.

ISPs who offer SMTP relay services for end-users need to disclose a
comprehensive list of domains to which subscribers cannot send e-mail
because of blocking/filtering or blackhole lists.

ISPs who offer SMTP servers for domain-holders to receive inbound e-mail
should disclose their blocking/filtering rules that they implement.

Either SMTP-based e-mail service is understood to be extremely unreliable
over the public Internet, or it is a part of the network's critical
infrastructure and as such should be operated without filtering or blocking
of any kind. There are other ways to solve the problem of SPAM than to rely
on existing flawed technical methods. If we are going to continue to
implement flawed technical methods, then we need to implement them in
nondeterministic failure mode so it becomes perfectly clear that NOBODY can
be certain that their e-mail has been delivered successfully unless they
request and receive a return receipt or human-originated ACK.

Sincerely,

Jason Coombs
jasonc@...ence.org

--

The original message was received at Tue, 4 Feb 2003 02:10:06 -0500 (EST)
from root@...alhost

   ----- The following addresses had permanent fatal errors -----
<jasonc@...ence.org>

   ----- Transcript of session follows -----
... while talking to mail.science.org.:
>>> MAIL From:<REMOVED>
<<< 550 5.7.1 Access denied
554 <jasonc@...ence.org>... Service unavailable

Final-Recipient: RFC822; jasonc@...ence.org
Action: failed
Status: 5.0.0
Remote-MTA: DNS; mail.science.org
Diagnostic-Code: SMTP; 550 5.7.1 Access denied
Last-Attempt-Date: Tue, 4 Feb 2003 02:10:13 -0500 (EST)
--
Reporting-MTA: dns; rly-ip04.mx.aol.com
Arrival-Date: Thu, 6 Feb 2003 02:49:00 -0500 (EST)

Final-Recipient: RFC822; <REMOVED>
Action: failed
Status: 5.0.0
Remote-MTA: DNS; <REMOVED>
Diagnostic-Code: SMTP; 550 5.7.1 Mail from 64.12.138.8 refused by blackhole
site bl.spamcop.net
Last-Attempt-Date: Thu, 6 Feb 2003 02:49:37 -0500 (EST)
--
Reporting-MTA: dns;mail.jasoncoombs.com
Received-From-MTA: dns;win2kdev
Arrival-Date: Thu, 16 Jan 2003 12:38:21 -1000

Final-Recipient: rfc822; <REMOVED>
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp;550 5.7.1 Mail from 172.194.98.240 refused by
blackhole site dynablock.wirehub.net
--
Reporting-MTA: dns;mail.jasoncoombs.com
Received-From-MTA: dns;win2kdev
Arrival-Date: Tue, 14 Jan 2003 06:04:02 -1000

Final-Recipient: rfc822; <REMOVED>
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;554 Service unavailable; [172.191.178.164] blocked
using relays.osirusoft.com


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists