Krystal n chips
There
may be some information in the bounce messages which tell us why they've been bounced e.g. if an RBL was involved (see below) but I'm not holding my breath.
It's possible that AOL are making use of one of the myriad
RBL (Realtime Blocking Lists) which are available, or are "rolling their own". RBLs, or
"a fit of pique" as they might appear,
can be an extremely effective way of stopping spam, depending on the listing policy and efficiency of the operator. A little background...
Most spam does not come direct from the spammers machine, for obvious reasons. What the spammers are on the lookout for are what are called
open relays. These are machines which are inadvertantly permitting third-party relaying of email through themselves, either due to incompetence or negligence. Email is transmitted throug the internet from server to server in a
very similar way to ordinary paper mail, which goes from sorting office to sorting office until it finally reaches one where it can be delivered to the recipient's mailbox. Most, though not all, software has any security features that it might have switched off when you "get it out of he box" and email is no exception. The so-called "rationale" for this is it makes it "easy to get it up and running" (<rant> which translates as "we might be able to get away with using somebody cheap to run our servers, rather than somebody who actually knows what they are doing..."
</rant>).
The problem is that having got your mail server up and running, there is great tendency to leave it "working" and not to go back and turn on all the appropriate security features, either becasue you are afraid of breaking something, or becasue you forget. So it's likely that this shiny new server will, as well as accepting mail for "the locals" who hanve mailboxes on it, also
relay mail for third-parties, that is will helpfully try to deliver messages it recieves over the internet, but which
are not destined for local mailboxes. This is box is then an open-relay, and is a prime candidate for being relay-raped.
Once a spammer find such an open relay, he proceeds to do one of two things. If he's clever, he drip feeds spam through it, on the grounds that 99% of the time the operator won't notice (rember they've not been clued up enough to secure the box in the first place). If he's not clued-up, he'll dump as much spam at it as he can. A depressingly large proportion of the time, nobody notices even this, but there is a higher chance that it will get noticed and the plug pulled. The spammer then moves on to his next open relay.
But what to do about all the spam that's pouring through the open relays until it gets noticed ? This is where the RBLs come in. The allow the addresses of the offending systems to be reported and listed in near "real time" in such a way that any mail server can look up the address of the sending
system (note that's the
network address of the offending system,
not any
email address associated with the message -- they're too easily forged) and decide before even receiving the message whether or not it wants to accept it, based purley on where it's come from. This is a Good Thing[TM] because any receiving site which performs this check will not accept the message in the first place, thus reducing network traffic, and it doesn't have to expend resources scanning the message to see if it's a virus or spam
after getting it. The messages are left to pile up on the open-relay system leaving it to the operator to
that system to deal with.
Now if this (badly run) open-relay
happens to belong to an ISP, for example, then the email of legitimate customers of the ISP will get their email blocked as well as the spam; and this is where the issue gets contentious. Supporters of this type of approach (myself included, for the record) point out that as a matter of historical fact, system oerators will tend not to listen to complaints from third parties to secure their systems, only (sometimes) to their customers, and not often to them. I have witnessed on more than one occassion an very big UK ISP refuse to accept there was a mail-relaying problem with one of their servers for nearly two months until they got RBLed (by somebody else on this occassion -- I was trying to help them out before resorting to that
); and guess what -- the problem that they hadn't been able to solve for 7 weeks was fixed overnight when all
their customers started complaining to
them about their legitimate email not getting though.
Now the opponents of this system say that it's totally unfair that innocent customers of the offending ISP (or whoever) who are trying to send legitimate email end up becoming "collateral victims" of my refusal to accept email from them (well, not just them, their whole ISP.) This is a point of view with which I have much sympathy.
However, experience has shown that systme operators tend not to respond to these complaints if they don't come from their customers. And anyway, why should i have to accept a shed load of spam coming from Dodgy-ISP, just to get the email from the one or two legitimate customers who wish to correspoind with me, and
then have to run a load of software to weed out the 90% of it which is spam, just because the operator wouldn't setup their machine properly in the first place.
(For completeness, I should point out that although the example cited here tend to imply an individual-oriented ISP like AOL, the worst offenders
tend to be the baby-coporate ISPs, that is the ones who sell connectivity to small businesses who themselves want to run their own mailservers. Getting mail relaying working correctly for these customers is marginally more difficult than for a setup where you only have local mailboxes, but not much. Any sysadmin who cannot do this properly shoulddn't be doing it all -- excepting, of course, the case where they know what they should be doing, but manglement refuse to allow them to do it for some spurious reason or another. but it is in this latter case (managementBinterference) that customer pressure, rather than third-party pressure, has the most effect.)
In short, spam filterning by ther recipient, no matter how clever it is, is ultimately no more than a sophisticated delete key. And hitting delete, although very effective in remoing the spam,
has absolutely no effect on the spmmaer at all. What the RBL techiniques does, in effect, is to push the problem of dealing with the spam back, just a little bit,
towards the spammer (in this case by inconveniencing the operator of the open relay rather than the recipient). As these people get their act together and secure their machines against open relaying (which is, when you get right the bottom line, theft of their resources by the spammer) less systmes will be available to spam though, and there will simply be less bandwidth available to the spammers. While we continue to simply absorb what they throw at us -- by deleting it, not rejecting it -- the problem will get worse. And I'm of the opinion that if a little "collateral damage" occurs, unfortunate though it is, thing will be better for it in the end...
Phew, this has all ended going on far longer that I was expecting, but as you might have guessed, you've got me going one of my pet subjects...