OPERATIONAL Question - Spamblock protocol

Karl Denninger karl at Mcs.Net
Wed Nov 19 04:31:18 UTC 1997


Hi folks,

I have an actual, no-bullshit operational opinion question relating to
spamming and spamblocking :-)

I'm working on the "intelligent bounce" software here for our spamblocker.
Right now we don't support bounces for spamblocked messages, for the reason
that the headers are often forged and thus the cycles to do this are wasted
(or annoying the wrong person).

Also, queueing the bounce back through Sendmail is usually a *bad* thing to
do, because sendmail is way to aggressive in trying to deliver mail when you
really want to make one pass at it and then give up.

So I'm having the spamblocker dump the spam into a different place, where I
then pick it up and post-process it to try to send the bounces back.

The problem is the algorythm.

My options appear to be:

1)	Go to the "From" line WITHOUT MX resolution, and deliver there.
	If it fails, go to the relay which connected to us and send to 
	{postmaster|abuse}.

	Advantages: We try to hit the exact machine the mail claims to
	be from.  There's a good chance that if it DOES have an SMTP 
	listener on it we'll get back a good reply to the RCPT TO command
	(either positive or negative).

	Disadvantages: Many sites don't run SMTP listeners on their machines
	which resolve to the domain name in the headers, and some don't even
	HAVE such a machine mapped with an "A" record to send to.  This will
	send to abuse and postmaster where a real person might be reachable
	otherwise.


2)	Go to the From line WITH MX resolution.  I've already figured out
	that hitting secondary MXs is a bad idea, for the simple reason that
	most of them will say "220" to anything in the domain they're
	secondarying for, and what you REALLY want is to get back 400 or 
	500 errors if the username is forged (as it frequently is) so you
	can then hit the relay abuse address INSTEAD.

	Advantages: This follows most closely the real Internet standards
	practice.  Its still not 100% complient, but again, we don't care if
	we're "wrong" in the area of failing to deliver one of these
	bounces.

	Disadvantages: The lookup time is non-trivial, and if the FROM line
	is forged you're going to harass the wrong person with the bounce.
	The second problem is particularly severe, since a "bad guy" can now
	pick on someone like "President at whitehouse.gov" and you're going to
	send the bounces to Mr. Clinton.  Once its figured out what you're
	doing, now these spammers have a nice denial-of-service attack they
	can launch.  This is already being done to some extent, and I'm not
	sure that its a good idea to give them more fuel.


3)	Screw the From line and hit the relay site directly; try to deliver 
	to the user there, and if it fails then hit abuse and postmaster 
	instead.  Don't bother trying to look up the From line on the 
	premise that its forged anyway.

	Advantages: The relay site either has an SMTP server on it or it
	does not.  If it does, then you just got to someone who SHOULD be
	able to put a stop to it.  If it does not, then you're wasting your
	time ANYWAY, but you probably know about it almost immediately when
	it comes back with an RST to your SYN.  If its some jerk on a dialup
	dynamic address account you'll probably time out (unless someone
	else is on the IP number now, in which case you get an RST) but
	again, its reasonably fast.

	Disadvantages: The user who sent the spam will frequently not get
	notified.  If your spamfilter blocks a legitimate user, you may
	never get notification to that person using this method.

In any case, if I fail to deliver the bounce on the first attempt I'm going
to ditch it and NOT retry.  Its not a big deal from my point of view if you
don't get back every one of the 452,223 spams you send me - - if I return
450,000 of them that's enough :-)

The intent here is to do the following:

1)	Alert the real sender if we can reasonably reach the person.
2)	Alert the relay owner if they were relayed through without knowing
	about it (and pressure them to fix it - pronto!)
3)	If we can't do either right away, toss the bounce on the floor
	on the premise that its better to give up than keep screwing around
	and clog up the pipeline.

What do the rest of you here think?  Option (1) doesn't look very sound; the
fight right now is between (2) and (3).

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost



More information about the NANOG mailing list