Getting interesting bounces, new virus out there?

[perry]

Here are the headers of a bounced message I got today.. I've gotten about 20 of em so far, vrom various domains:

Return-Path: <allan@yyyyyyyyyyy.com>
Received: from ss (a83-132-108-64.cpe.netcabo.pt [83.132.108.777] (may be forged))
	by mx17.mx.voyager.net (8.13.2/8.10.2) with SMTP id j62EqwtG008631
	for <blake@axom.com>; Sat, 2 Jul 2005 10:54:59 -0400 (EDT)
Received: from yyyyyyyyyyy.com (yyyyyyyyyyy.com [69.73.159.999])
	by a83-132-108-64.cpe.netcabo.pt (Pastfix) with ESMTP id 4FCB456E45
	for <blake@axom.com>; Sat, 02 Jul 2005 08:13:18 -0700
Date: Sat, 02 Jul 2005 08:13:18 -0700
From: "Uniformed H. Swash" <allan@yyyyyyyyyy.com>
X-Mailer: The Bat! (v2.00.6) Personal
X-Priority: 3
Message-ID: <9797012151.20050702081318@yyyyyyyyyy.com>
To: Blake <blake@axom.com>
Subject: just do it with your girlfriend...
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Whatever it is doing, it is confusing mail servers enough to think that the messages actually came from my domain and the bounces are making it back to my catch-all. The virus is getting the IP and domain matched up and putting in the return path so that the mail makes it back to me (the allan@ user has never existed before, so that is made up).

Since I'm on sigma (new xenon), I at first thought things were somehow being relayed through the server because I've never seen bounces like this before. I opened a ticket to have em double check and did a few tests on my own (abuse.net and ordb.org). All negative.

Anyone else notice a rise in bounces like this recently? I've gotten occassional virus bounces in the past, but never this heavy. I think I'm up to about 40 today, plus my normal amount of spam that I never look at.

[Spathiphyllum]

...Received: from ss (a83-132-108-64.cpe.netcabo.pt [83.132.108.777] (may be forged))
...Received: from yyyyyyyyyyy.com (yyyyyyyyyyy.com [69.73.159.999])...

Heh, may be forged?

Anyone else notice a rise in bounces like this recently?...

Not yet.

I have a temporary suggestion to at least dump them to get out of a loop if you have any autoresponders - or just to dump obviously forged IPs. In cPanel, try the following email filter:

Filter: Any Header matches regex /\[.*(?:\.[2-9][5-9][6-9]).*\]/g
Destination: Discard

No guarantees and I haven't tested it, but something like this may work. What I tried to do was set a regular expression rule that will perform a non-greedy search for bracketed, quad IP numbers that include a value >= 256 and discard mail that includes such a header immediately. Actually, to be more precise, it looks for '.nnn' and not just 'nnn'. If you are concerned with IP ranges beginning with a number greater than 255, then remove '\.' from the regex expression.

Try it out and let us know what happens. It's just a workaround but may bide you some time until a better solution arises.

Notice: See the next post to consider alternate.

[Spathiphyllum]

Well, I tried the previous regex and it seems to be a bit too aggressive for headers. It ate my homework, er emails, that it should not have. I decided to narrow its scope a bit and it works though its scope is too restrained for any long-term solution:

/\[\d+(?:\.[2-9][5-9][6-9])\]/g

This modification only checks for quads terminating in a number greater than or equal to 256. Not great but better than eating everything.

If you cannot modify headers in your email, then set your rule for the subject line and send test emails with the "problematic" $string as the subject. Though imperfect, it's a better remote debugger than not testing at all.

Good luck and happy tweaking.

[perry]

Heh, may be forged?
[/B]

Heh, well, I obviously changed that stuff.. figured I didn't need to point it out. Guess I should have changed more so that none of the hostnames and IP's were valid, but whatever. 25 more when I woke up this morning.

The subject strings are all ones generated by mailer-daemon, "returned mail" or "undeliverable" or "failure notice".. The volume isn't quite high enough to filter out all procmail/qmail/whatever messages right now.

They all seem to have "Pastfix" as an MTA in the forged received header.. Doesn't seem like that is a real program, so filtering on that should be OK, huh?

[Spathiphyllum]

I didn't figure you'd bother changing IP addys... my bad. I had assumed that an automated script was popping out forged headers and its code had botched a "new IP code generator" loop.

...They all seem to have "Pastfix" as an MTA in the forged received header.. Doesn't seem like that is a real program, so filtering on that should be OK, huh?

Yes, that does look like a misspelling of "Postfix"... or maybe it's a soon to be released open-source MTA that is in beta. Either way for your specific issue, filtering on that would seem to be a much better (exact/errorfree) solution at least until the spammer/snooper/cracker pulls out the revised list of correctly-spelled mailers. Are you sure that you didn't forge that? Fool me once...

[perry]

SpamAssassin is now tagging the emails for me.

1.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
                            [URIs: impolishedkg.com]
 0.4 URIBL_AB_SURBL         Contains an URL listed in the AB SURBL blocklist
                            [URIs: impolishedkg.com]
 2.5 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: impolishedkg.com]
 1.5 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: impolishedkg.com]
 3.2 URIBL_OB_SURBL         Contains an URL listed in the OB SURBL blocklist
                            [URIs: impolishedkg.com]
 4.3 URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist
                            [URIs: impolishedkg.com]

Filtering on "Pastfix" in my local client worked well, but a few MTA's were stripping the original headers so some were getting through to the inbox. Seems those bl's picked up the addresses used in the virus messages a day or two ago.