Jump to content
Sign in to follow this  
rosaryshop

Seeking suggestions for handling bounces/misdirects

Recommended Posts

I'm looking for advice on how to handle bounced mail bombs. Here's the story:

I receive a few hundred bounced messages from SMTP servers of a single organization in Japan (KDDI) every couple days. This has been going on for years. The originator of the messages has misidentified his machine name and the messages, when not delivered, end up getting bounced to me by the KDDI servers. I am the "owner" of the domain he claims to be sending from, but the IP address from which the e-mails are originating is on KDDI's network.

I've contacted their abuse people several times with no results. Tired of dealing with it, I just started forwarding them all to their abuse address. The irony is that KDDI is part of some Japan coalition to end spam. Go figure.

Anyway, this weekend the bounces escalated and I've received about 10,000 in the last 12 hours. This is enough to begin to bog down my humble server and cause problems for our other services.

Our Internet connection is a Comcast business service. I called Comcast and asked them to put a block in the routing tables for SMTP (or any) traffic from the source servers to our network. I might as well have been asking for the moon. Once I got past their front line "customer service" people and made to tech people who understood what I was asking for, they flatly refused, and said I had to set up the blocking on my end. That kind of defeats my purpose, which was to stop the bomb before it gets here.

He did say I could file a complaint. I could almost hear them rolling on the ground, laughing in the background as he said it.

With that answer I hung up, dug into Sendmail and set the access file to reject anything coming from the IP addresses in question. I also posted two of the messages to the spamcop system. I submitted them to spamcop in the past, but spamcop rejected them. It accepted them this time; apparently spamcop's policies have changed regarding bounced mail bombs. I'm VERY THANKFUL for that!

That all being said, I invite and welcome any suggestions about other steps you might recommend I take to deal with this. Of course, I've scanned and will continue to scan the archives, too.

Following is a copy of the full bounce message as I received it:

Return-Path: <>

Received: from smf02.pdx.ne.jp (smf02.pdx.ne.jp [124.211.23.8])

by bsd1.rosaryshop.com (8.12.3/8.12.3) with ESMTP id m4MJO6f5085101

for <root[at]comboard.com>; Thu, 22 May 2008 12:24:07 -0700 (PDT)

Received: from mc-imt32-g.dav.pdx.ne.jp (mc-imt32 [10.214.7.162])

by mc-smf02-g.dav.pdx.ne.jp (Postfix) with ESMTP id 4CD292CEB29

for <root[at]comboard.com>; Fri, 23 May 2008 04:24:06 +0900 (JST)

Received: by mc-imt32-g.dav.pdx.ne.jp (Postfix)

id 4E59119F3E9; Fri, 23 May 2008 04:24:06 +0900 (JST)

Date: Fri, 23 May 2008 04:24:06 +0900 (JST)

From: MAILER-DAEMON[at]pdx.ne.jp (Mail Delivery System)

Subject: Undelivered Mail Returned to Sender

To: root[at]comboard.com

MIME-Version: 1.0

Content-Type: multipart/report; report-type=delivery-status;

boundary="469A019F302.1211484246/mc-imt32-g.dav.pdx.ne.jp"

Message-Id: <20080522192406.4E59119F3E9[at]mc-imt32-g.dav.pdx.ne.jp>

X-UIDL: Pkf"!Zm]!!~M$"!Y3^!!

This is a MIME-encapsulated message.

--469A019F302.1211484246/mc-imt32-g.dav.pdx.ne.jp

Content-Description: Notification

Content-Type: text/plain

This is the Postfix program at host mc-imt32-g.dav.pdx.ne.jp.

I'm sorry to have to inform you that your message could not

be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can

delete your own text from the attached returned message.

The Postfix program

<aipark002[at]wm.pdx.ne.jp>: host 10.214.7.132[10.214.7.132] said: 552 We failed

to deliver mail because the volume of recipient's mailbox exceeded the

local limit. aipark002[at]wm.pdx.ne.jp (in reply to end of DATA command)

--469A019F302.1211484246/mc-imt32-g.dav.pdx.ne.jp

Content-Description: Delivery report

Content-Type: message/delivery-status

Reporting-MTA: dns; mc-imt32-g.dav.pdx.ne.jp

X-Postfix-Queue-ID: 469A019F302

X-Postfix-Sender: rfc822; root[at]comboard.com

Arrival-Date: Fri, 23 May 2008 04:24:06 +0900 (JST)

Final-Recipient: rfc822; aipark002[at]wm.pdx.ne.jp

Action: failed

Status: 5.0.0

Diagnostic-Code: X-Postfix; host 10.214.7.132[10.214.7.132] said: 552 We failed

to deliver mail because the volume of recipient's mailbox exceeded the

local limit. aipark002[at]wm.pdx.ne.jp (in reply to end of DATA command)

--469A019F302.1211484246/mc-imt32-g.dav.pdx.ne.jp

Content-Description: Undelivered Message

Content-Type: message/rfc822

Received: from mc-rmt04-g.dav.pdx.ne.jp (unknown [10.214.2.36])

by mc-imt32-g.dav.pdx.ne.jp (Postfix) with ESMTP id 469A019F302

for <aipark002[at]wm.pdx.ne.jp>; Fri, 23 May 2008 04:24:06 +0900 (JST)

Received: from nmomta.auone-net.jp (unknown [10.214.2.137])

by mc-rmt04-g.dav.pdx.ne.jp (Postfix) with SMTP id 2E9FC35E608;

Fri, 23 May 2008 04:24:06 +0900 (JST)

Received: from nmomta.auone-net.jp ([210.196.14.76]) by hlegxh06.pdx.ne.jp

with SMTP

id <20080522192406.KSBH30729.hlegxh06.pdx.ne.jp[at]nmomta.auone-net.jp>;

Fri, 23 May 2008 04:24:06 +0900

Received: from comboard.com ([219.108.108.129])

by nm03mta.auone-net.jp

id <20080523042405891.MA60.AB8A240[at]nm03mta.auone-net.jp>;

Fri, 23 May 2008 04:24:05 +0900

Received: (from root[at]localhost)

by comboard.com (8.11.6/8.11.6) id m4MJO4R13155;

Fri, 23 May 2008 04:24:04 +0900

Date: Fri, 23 May 2008 04:24:04 +0900

Message-Id: <200805221924.m4MJO4R13155[at]comboard.com>

MIME-Version: 1.0

To: aipark002[at]wm.pdx.ne.jp, aipark003[at]wm.pdx.ne.jp

Subject: Alarm !

From: itaya[at]aipark.com

Content-ID: <Fri_May_23_04_24_02_JST_2008_0[at]comboard.com>

Content-type: text/plain; charset="iso-2022-jp"

Content-Description: An object packed by metasend

Content-Transfer-Encoding: 7bit

2008/05/23 02:58:15

$BDdEEDLJs(B

$BHD20D.%(%3%-%e!<%V(B

--469A019F302.1211484246/mc-imt32-g.dav.pdx.ne.jp--

Share this post


Link to post
Share on other sites

...Welcome!

I'm looking for advice on how to handle bounced mail bombs. Here's the story:

<snip>

The irony is that KDDI is part of some Japan coalition to end spam.

<snip>

"spam" is a trademark of Hormel Corporation, so please do not use it here to refer to unsolicited e-mail (spam). Please see "spam and the Internet," especially the third paragraph. Thanks for complying with Hormel's polite request!
Our Internet connection is a Comcast business service. I called Comcast and asked them to put a block in the routing tables for SMTP (or any) traffic from the source servers to our network. I might as well have been asking for the moon. Once I got past their front line "customer service" people and made to tech people who understood what I was asking for, they flatly refused, and said I had to set up the blocking on my end. That kind of defeats my purpose, which was to stop the bomb before it gets here.
...A worthy goal! The only suggestion I can come up with is to spend a bit more money and subscribe to a professional e-mail service provider, one that is willing to reject e-mail with a "5xx" message, based on a block list, during the SMTP handshake stage.
<snip>

Following is a copy of the full bounce message as I received it:

<snip>

...Oh, no, please don't do that again! The preferred way of providing such information is to submit the spam to the SpamCop parser and provide the Tracking URL in your Forum post (then proceeding to either complete or cancel the result, so that it can not be misused by other users). Please see the link in "Start Here - before you make your first Post" (it appears prominently on the main page of the SpamCop Forum -- http://forum.spamcop.net/forums/index.php?act=idx) labeled "How-to Post a Question - Short." Thanks!

Share this post


Link to post
Share on other sites
I'm looking for advice on how to handle bounced mail bombs. ...
So, essentially comboard.com record is set to MX bsd1.rosaryshop.com 74.93.189.34 which is wrong?

[ah, no I see comboard.com is 'yours' too, that's the one the problem is about but that's just crudely forged in the bounced message seen.

Looking at 210.196.14.76:

Non-authoritative answer:

76.14.196.210.in-addr.arpa name = nm03omta07.auone-net.jp

So the Postfix program at host mc-imt32-g.dav.pdx.ne.jp (mc-imt32 [10.214.7.162])

needs fixing - that looks like an internal address only. And it is probably just one of many though you say the bounces are from just the one network owner.

Well, short of that, the usual pattern is for such huge surges in misdirected bounces to fade away fairly quickly. But you fear your case is not typical. Hopefully others can suggest something.]

Edited by Farelf

Share this post


Link to post
Share on other sites
With that answer I hung up, dug into Sendmail and set the access file to reject anything coming from the IP addresses in question. I also posted two of the messages to the spamcop system. I submitted them to spamcop in the past, but spamcop rejected them. It accepted them this time; apparently spamcop's policies have changed regarding bounced mail bombs. I'm VERY THANKFUL for that!

Like the others there is little I can think of that might improve your lot.

Sadly, submitting just two reports to the SCBL will have no effect in that the IP address would not get listed. I'm not an expert on the block list algorithm but I know that it demands multiple reports and multiple reporters to trigger a listing (unless spam traps are part of the equation). Otherwise the SCBL reports will alert the 'owner' of the IP to a problem. But, of course, they may choose to do nothing about just two reports.

I guess you've done just about all you could do with the arrangements you have in place.

Andrew

Share this post


Link to post
Share on other sites

Actually, blocking at your mail server will make a big difference. With most MX software, IP blocklists are applied immediately following the EHLO command. The point being, you will never be receiving the DATA portion of the SMTP transaction, which is where all the bandwidth is used. If it is rejected during SMTP, your mail server will not have to handle the message at all, so it should help to alleviate your problem.

You might also try tarpitting if your servers support it. With tarpitting, after the EHLO from the sending server, if your server decides to reject the message, it wait a predetermined amount of time before letting the sender know. This ties up one of their outbound connections for a couple minutes, and helps to limit the rate that these messages can be sent at, especially if your server allows you to only allow X number of simultaneous incoming connections from a single source.

Also, misdirected bounces are reportable through spamcop. Maybe getting their server listed on a blocklist for a while will grab their attention. Of course, for that to work, there would have to be someone else out their getting bombed and reporting them also, as I don't believe a single reported can get an IP listed. However, if your scenario is correct as described, it is likely that you are not the only one receiving misdirected bounces from their server.

Share this post


Link to post
Share on other sites

Thanks, all, for your helpful comments. I'll look into these things.

I especially like the tarpit idea and will see if I can get my version of sendmail to do that without too much trouble.

SHM

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×