Kaiwan.com a SPAM Source?

Mailman List Mirror (Read Only)
1

*WARNING* Configuration of your router with the following file may cause
multiple configuration errors. Do not configure your router with the
following information.

Recently today, Nap.Net's coprorate mail exhanger (does not support
relaying) was e-mail bombed. Upon tracking this down, we found that the
attack was sourcing from kaiwan.com. Our NOC contacted thier contact per
InterNIC database, and asked them about the attack, thinking it might have
been relayed through them or such. However, the nice gentleman on the
phone (read irony into that please) said that that in fact was not the
case. The had a script that when it identifies SPAM, it parses the header,
retrieves the path of the spam, gets the contact info from the InterNIC
database, and then sends multiple emails out to the path of the SPAM for
each one received. An automated Denial of Service attack. How nice.

Kaiwan.com has been completely uncooperative. Nap.Net has a strict AUP,
and has agressively addressed any SPAM complaints addressed against any of
it's downstream customers. However, unfortunately a customer must SPAM at
least once before we can identify such SPAM. Automated scripts like this
are of no help, and in fact possibly cause more harm than help.

Just an FYI, it was either steam here, or add a network statement to my BGP
config that contains more specific routes of kaiwan.com. This seemed a
little less drastic.

Chris A. Icide

2

Hmmm...

We are implementing a customer-selectable bounce option to our "spamblock"
technology which will do something like this, but not nearly that obnoxious.

The spamblocker will make ONE attempt to send to the "From" header the
bounce message. IF THAT FAILS, it will send ONE copy of the bounce to
postmaster and abuse on the MACHINE which LAST relayed the mail to us.

The only way the abuse and postmaster mailboxes will get hit is if the From
line is forged or otherwise unusable for replies. But, if someone relays
off you, you WILL get one message per spam until you fix the relay problem.

I think this is perfectly reasonable. One spam, one complaint.

Again, this is a configurable option on the customer end. We are currently
defaulting to ditch SPAM silently; the customer will have to *ASK* for
bounce behavior.

The message from the bounce system will have a system default, but also be
overrideable on a customer-by-customer basis. Thus, you CAN get a bounce
which is an ASCIIzed middle finger, for example :slight_smile: