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 jasoncat_private -- 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 jasoncat_private -- The original message was received at Tue, 4 Feb 2003 02:10:06 -0500 (EST) from root@localhost ----- The following addresses had permanent fatal errors ----- <jasoncat_private> ----- Transcript of session follows ----- ... while talking to mail.science.org.: >>> MAIL From:<REMOVED> <<< 550 5.7.1 Access denied 554 <jasoncat_private>... Service unavailable Final-Recipient: RFC822; jasoncat_private 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
This archive was generated by hypermail 2b30 : Sun Mar 16 2003 - 11:09:05 PST