[unisog] AOL Bouncing E-mail

Christopher Crowley ccrowley at tulane.edu
Wed Feb 25 21:50:27 GMT 2004

We recently experienced several AOL block periods.

They have multiple types of blocks.  The one we saw was RLY:B1, a dynamic
block based on the number of complaints AOL users are filing.  This takes
about 24 hours to relax, if you have stopped the source of the e-mail.
Telnet to port 25 ( from your SMTP server ) of any of the IPs listed from a
`nslookup -q=mx aol.com`. You may see a reject notice, and one of these
dynamic block codes.

The source of the spam e-mail has been trojanized PCs with a mail relay
backdoor.  They use our SMTP server to send thousands of messages, all of
which are targeted at aol.com recipients.  To prevent this from occuring, we
are using DCC to throttle individual systems that send too many messages.
It has worked well so far.  The DCC configuration is a little unusual in
that it doesn't contact the DCC flooding network.  It merely uses its local
database to keep track of how much mail is coming from particular sources.

Christopher Crowley
Technology Services
Tulane University
ccrowley at tulane.edu

----- Original Message ----- 
From: "Matt Crawford" <crawdad at fnal.gov>
To: "Azrael" <Azrael at psu.edu>
Cc: "ITS - Security Operations and Services" <security at psu.edu>;
<unisog at sans.org>
Sent: Tuesday, February 24, 2004 4:36 PM
Subject: Re: [unisog] AOL Bouncing E-mail

> > A few weeks ago, there was some discussion about AOL blocking some
> > SMTP servers.  My university is now experiencing a problem with AOL
> > bouncing our E-mail and I was hoping that some of you would share your
> > experience with AOL on this matter.
> A non-profit I help out with was shut out of AOL because of spam sent
> to mailing lists hosted by the group, with subscribers on AOL who
> wanted to receive at least the non-spam component of the list traffic.
> (And these lists weren't bad off at all, as spammed-lists go.)
> After hours on the phone with the AOL "help" desk, they were told the
> cutoff was because their reverse DNS wasn't resolving -- which was
> completely false.  They went through the call queue again and may now
> be on the whitelist.

More information about the unisog mailing list