karl and paul, expostulating

> Filtering by connection to the SMTP port, based on source address, very
> definitely DOES work.

Filtering packets based on source address makes Ciscos go way slow on
every packet. Filtering based on destination address makes Ciscos go
very fast on most packets and a little slower on SYN-ACKs.

Filtering at the SMTP SERVER LEVEL has no impact on CISCOs at all!

Its also trivial. The current 8.8.x Sendmail code has provisions for it
already in the code. The hooks take about 20 seconds to install, and one
line to edit in a file to update. The impact on SMTP connection isn't even
measurable for those who don't trip it, and for those who do, you can even
return a rude message -- or a 421 error, which keeps the spam at the source
(loading the spammers mailserver -- a GOOD thing!)

> And again, unnecessary and overbroad. Filtering at the SMTP receiver port
> is perfectly fine, it works, and it doesn't prevent other traffic.

And, again, wrong. I want spammers to spend 75 seconds of TCP PCB time on me.
By blackholing SYN-ACKs and not sending them ICMPs, they lose capacity that
they could otherwise spend spamming other people. I call this "fighting dirty."

Again, wrong Paul. Sending back 421s to the spammers force them to waste
not only the connection time, but the scan time on their disks. If lots of
people do it they back up thousands of email messages, and THAT breaks their
mail servers. This is a very good thing. Its even uglier than the 75
seconds, in that its cumulative and probably keeps that nice message on
their disks (where it eats resolver resources, storage, and useless attempts
at delivery) for up to five days.

Much more elegant, in my opinion.

I operate a cooperative resource. I will not have it used against me.
This is not negotiable. I pay for my part of the Internet and anyone
who wants their traffic to traverse it has to make sure that I derive
similar value, in the aggregate, to theirs when they send me traffic.

No argument -- as long as a public root server isn't there. If it wasn't
I'd be SUPPORTING your black-hole list. But it is, and as such I'm not.

Actually it's not personal, it's economic. eDNS is piracy. Very different.

Riiiight...

Yes, but now that I've got the eBGP feed working I'm starting to do real time
spam reporting/detection that will cause third party unintended relays to be
disabled while a spammer is still trying to use them. Not everyone wants to
spend that 30 seconds, and if we don't make spamming even less profitable
than it is now, you'll be spending that 30 seconds 15 times per hour, 24x7.

Nonsense. Why not distribute the "block the SMTP port" list instead?

> That's a point-source response to the problem Paul. Try it on sometime.

I prefer http://www.sendmail.org/antispam/ as far as that goes. But the
problem isn't limited to a point, there are a LOT of people who want the
same protection I work so hard to give myself, and I am donating that
protection to anyone who wants it.

The point is, you can do that, hurt the spammers even more, and still find
ways to distribute the file (it IS only a flat file Paul) on an automated
basis, rapidly, if you want.

AND, you don't cut off a non-related resource (a root nameserver) in the
process.

or a 421 error, which keeps the spam at the source (loading the

  > spammers mailserver -- a GOOD thing!)

Are you joking? There's not a spammer alive that uses sendmail or
something that would similiarly requeue on temporary failure.

  > Much more elegant, in my opinion.

Assuming that 'sendspam' would actually maintain a queue.

Paul's solution has its own elegance: raising the price for allowing
antisocial behavior from bounced email to partial loss of
connectivity. But like Paul said, raising the stakes like that just
invites someone to try and one up him.

> Yes, but now that I've got the eBGP feed working I'm starting to do real time
> spam reporting/detection that will cause third party unintended relays to be
> disabled while a spammer is still trying to use them. Not everyone wants to
> spend that 30 seconds, and if we don't make spamming even less profitable
> than it is now, you'll be spending that 30 seconds 15 times per hour, 24x7.

Nonsense. Why not distribute the "block the SMTP port" list instead?

Anybody who wants to do a little gated hacking can take Paul's eBGP
feed and export it to sendmail rather than using it to blackhole the
traffic.

The point is, you can do that, hurt the spammers even more, and still find
ways to distribute the file (it IS only a flat file Paul) on an automated
basis, rapidly, if you want.

It's really the choice of the recipient of the data what they want to do
with it. Paul just creates the list, he doesn't force anyone to accept
the list or use it in a specific way.

Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-250-546-3049
http://www.memra.com - E-mail: michael@memra.com

Paul Vixie said:

> I operate a cooperative resource. I will not have it used against
> me. This is not negotiable. I pay for my part of the Internet and
> anyone who wants their traffic to traverse it has to make sure that
> I derive similar value, in the aggregate, to theirs when they send
> me traffic.

Karl Denninger said:

No argument -- as long as a public root server isn't there. If it
wasn't I'd be SUPPORTING your black-hole list. But it is, and as such
I'm not.

I understand Karl's position on this. But I would point out that
there's a long history of public resources (such as root servers) being
installed on parts of the net that have acceptable use policies. For
example, there used to be root servers that were unable to send packets
to sites that had not agreed to the NSFnet AUP.

--apb (Alan Barrett)

> or a 421 error, which keeps the spam at the source (loading the
> spammers mailserver -- a GOOD thing!)

Are you joking? There's not a spammer alive that uses sendmail or
something that would similiarly requeue on temporary failure.

> Much more elegant, in my opinion.

Assuming that 'sendspam' would actually maintain a queue.

Paul's solution has its own elegance: raising the price for allowing
antisocial behavior from bounced email to partial loss of
connectivity. But like Paul said, raising the stakes like that just
invites someone to try and one up him.

What's so elegant about that if a spammer with elementary knowledge
about SMTP and DNS can easily bounce his stuff off of any of the
thousands of unsuspecting hosts and/or use unsuspecting forwarding
name servers in the slave mode?

Daniel Simms There is more than one way to burn a book.

Dima