* * * * *

      Perhaps the solution is to disable any form of bounce back message

I awoke to a phone call from a frantic Smirk, trying to get one of our new
servers under control from a deluge of email (if I sounded angry today Smirk,
that's because I got up a bit early, and it took nearly two hours for me to
eay my way through lunch, so let me apologize).

The end result will probaby take as long to explain as it took to handle.

The server was drowning in email being sent to [email protected]. We don't
host the website for seaton.biz. Nor do we handle email for seaton.biz. In
fact, we have nothing, nada, zip, zilch, **nothing what so ever** to do with
seaton.biz, except for a ton of email trying to be delivered to
[email protected] from our server.

Got that?

Read that paragraph again.

Good.

Now, why were we trying to send email to [email protected]? Good question.
At the time, the MX (Mail eXchange) record for seaton.biz (which contains the
address of the server(s) that handle email for seaton.biz) were resolving to
127.0.0.1.

Now, the IP (Internet Protocol) address 127.0.0.1 is a special IP address—
it's the “loopback” address; any network traffic sent to IP address 127.0.0.1
is sent to the box doing the sending—the data “loops back.”

So our server sent the email to [email protected] to IP address 127.0.0.1,
which, since that's the “loopback” address, was sent right back to our
server. Our server accepted the email because, hey, it has the permission to
send email to itself. But since we don't host seaton.biz, or in fact, have
anything to do with seaton.biz, the email got requeued up for delivery again.


Which begs the question why we were trying to send email to
[email protected] in the first place. In checking the email logs, it seems
that one “Nicholas,” who has the email address of [email protected], sent a
bunch of spam to all the sites on our server. And in typical spam fasion, it
was sent to a whole bunch of addresses, the majority of which don't exist!

That's right. “Nicholas” here was sending email to [email protected],
[email protected], [email protected], [email protected], etc. etc. with a return
email address of [email protected].

Now, our email server, like every other email server in existance, is
configured to send an error notification back to the sender when the email
address doesn't exist. So each spam that “Nicholas” sent that didn't get
delivered because the destination address didn't exist created a message to
[email protected] saying as much.

So that's why we had thousands upon thousands of messages attempting to be
delivered to [email protected], which, because the email server for
seaton.biz was set to the “loopback” address, were being delivered right back
to our server for yet another attempt at delivery.

Beautiful, huh?

Now, that's not to say that the owners of seaton.biz were the actual spammers
most likely they're not and they're the victim of a “joe job [1].”

So now the question is: who's doing more damage here? The original spammer
“Nicholas?” Or the owners of seaton.biz when they changed their MX records to
127.0.0.1? (not that I can blame them for doing that—it keeps a bunch of
useless email from being sent to them and wasting their bandwidth) And what
can we do to keep this from happening in the future?

I suppose one way would be to immediately delete any email destined for a
site we have nothing to do with, but with an MX record of 127.0.0.1.

Does anyone know how to get sendmail to do that?

[1] http://en.wikipedia.org/wiki/Joe_job

Email author at [email protected]