lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <ILEPILDHBOLAHHEIMALBKEIHENAA.jasonc@science.org>
From: jasonc at science.org (Jason Coombs)
Subject: 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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ