Bounced email from AOL?

Is anyone else receiving bounced emails from AOL with the error message: “host[] said: 554 TRANSACTION FAILED 554 AOL will not accept delivery of this message”

Is that an actual email you sent, or are you just getting a bounce?

I have a domain that spammers have used to forge their headers, so I periodically get bounces from AOL.

One of my announcement lists also gets a lot of bounces from AOL…

This was discussed in an earlier thread.

I’m getting a lot of bounced e-mails as well. I read the other thread, but I didn’t really see any resolution. I know there’s nothing I can do to stop the spammers from making up e-mail addresses, but how can I filter these out?

I tried telling the Addresses control panel to toss any address that’s not defined (like but I still get the bounces.

Next, I tried setting up a filter to filter out the subject lines with “User Unknown”, “Returned Mail”, etc. I STILL get the bounces…and like 400 a day (possibly more).

I used to get some every so often, but this week it really just EXPLODED for no reason I can determine. They come in almost all at once. Sure, I can filter it in my e-mail clients, but I’d much rather do it server side and not have to download all that crap to begin with.

If you have set unspecified addresses at a domain to “bounce”, and you’re still getting returned mail to addresses which don’t exist, please send a copy of such a bounce (with full headers) to support with attention to me.

Okay, will do…


Just to confirm, does that go for others? Do you want bounced spam from AOL with forged headers from Dreamhost customer domains?

No!!! Definitely not. We get 4-5 complaints about this on a daily basis already, and it’s something we can’t do anything about. I’m only interested if the bounces are actual bounces from spam being sent (via an insecure form to mail script or something) via our servers… if there is a case where you’re not sure, might be best to check.

Bottom line (well somewhat of an over-simplification, but should cover most cases) is:
[]1) If the bounce is sent TO an address at your domain, from AOL, most likely, it’s just due to a forged envelope-sender.[/]

[]If the bounces are sent TO "", you probably have something to worry about.[/]
You can check this by examining the Received headers… you’re looking for something like:

Received: from ( []) by (Postfix) with ESMTP id 3D3A9909D4 for <>; Tue, 16 Dec 2003 21:16:16 -0800 (PST)
[ message was sent to user@machine ]

rather than:

Received: from ( []) by (Postfix) with ESMTP id 8FEB52BDB5 for <>; Thu, 4 Dec 2003 18:10:06 -0800 (PST)
[ message was sent to address@[domain we host] ]

I just wanted to confirm that the messages in this case were not, in fact, sent to an address which didn’t exist.

In this case, the issue was due to actual spam sent via an insecure user script, and returned to the user’s actual username at the user machine itself.

The issue about which made the issue a little more confusing is that even though the bounces were sent TO a valid address, the spammer used [somefakeaddress] as an address in the "To: " or "Cc: " headers of the original spam… this is one way that these formmail exploits trick certain vulnerable scripts into accepting the mail.

Hope that makes sense.

Just a note - we do not setup our mail servers or user machines to accept for [address] You will not receive actual mail to this address (unless you go to a lot of trouble to set things up this way specifically).

Yep. The problem in my case was that some sneaky spammer was going around my HTML form and submitting his own data to my CGI script. Although I had a text field on the form that would have prevented most people from submitting bogus data, this guy apparently wrote his own.

…so where I asked for the user’s e-mail address (so I could e-mail them back), he submitted:
[new line]
Subject: this really works
bcc: [tons of AOL e-mail addresses]

When my form passed this off to sendmail, it sent spam out from my domain.

I have since taken the form offline. Once the bounced messages finish coming through, I’ll put up a corrected version with A LOT more error checking.

I’m also going to rename the CGI script so he can’t go directly to the same place anymore. (Yeah, it will be easy to find the new one since it’s in the HTML form, but anything I can do to make life harder for this spammer is good.)

So, although I was getting lots of AOL bounces, it was my own fault for having a form without enough error checking. I encourage everyone to double-check their scripts to make sure you don’t have the same vulnerability…especially if you get a lot of bounce messages for e-mail you never sent.

If you need just straight form to mail functionality, the nms-cgi version seems to be the best. We run that version, and we’ve even had some problems with that one (although I think some of our custom changes that are needed to make it work with all customer domains are probably to blame).

Big increase recently in spammers abusing scripts that are NOT the standard Matt Wright formmail program, and ones which do not not follow the standard naming conventions.

BTW, using the form itself to restrict data is a bad idea… it’s trivial to post data to a site without using the form at all, and this of course is what the spammers do. While renaming the program may help a little, I would (as you say) definitely not rely on that. If something is exploitable, I almost guarantee a spammer will find it eventually. My guess is that they use bots to actually crawl peoples’ pages and look for tags.

A pretty good paper which explains how some of these exploits work is at: