Subject: Re: [Asrg] On assertions

From: John Levine <[email-masked]>
Date: 2 Aug 2008 11:53:48 -0000

>I thought one indicated "we receive no mail" by establishing a valid
>MX record that points to a machine with the smtp port open and a
>silly little daemon that gives 552 errors in reply to all MAIL FROM
>commands listening on it.  (would that be a viable commercial
>service?)

Depends.  I know of some domains that get several thousand connection
attempts per second, all spam, when they have an MX.  How much
bandwidth does your daemon have and how many simultaneous connections
will it handle?

_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Sat, 2 Aug 2008 19:15:13 -0400 (EDT)

> bandwidth does your daemon have and how many simultaneous connections

Several thousand connections per second, at (say) 100 bytes of traffic
each (banner, HELO/EHLO, response, MAIL, response, QUIT, response - if
the responses are short, I don't think 100 bytes total is far off)?

Several hundred thousand bytes per second.  Not over a 10Mbit pipe's
capacity, though approaching it (perhaps even a little over it, given
the various layers' overhead).  Lots of hosting centres can do a 10Mbit
pipe no problem.

Simultaneous connections?  After doing the mail shim for work, I
believe I could build an SMTP daemon which does that; based on some
back-of-the-envelope estimates, simultaneous connections might be a
problem, but probably not requiring more than a little kernel tuning
(and maybe tarting up the machine with RAM, though given modern ideas
of reasonable RAM load, possibly not).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Sat, 2 Aug 2008 19:21:37 -0500

On Sat, Aug 2, 2008 at 6:15 PM, der Mouse <[email-masked]> wrote:

>>> (would that be a viable commercial service?)
>> [is it technically feasable?]
> [yes]

The question is, does the customer exist? (even if they don't know it yet)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 3 Aug 2008 11:21:59 -0000

>> attempts per second, all spam, when they have an MX. ...

>pipe no problem. ...

OK, now remember this is just one customer, who'd probably cost
$100/mo to host.  Who's going to pay that just not to get mail?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 03 Aug 2008 09:57:41 +0200

> the various layers' overhead).  Lots of hosting centres can do a 10Mbit

There is something basically wrong in trying to achieve efficiency 
when serving spammers, IMHO.

> believe I could build an SMTP daemon which does that;

What about http://www.spamcannibal.org/?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Sun, 3 Aug 2008 20:55:26 -0400 (EDT)

>> believe I could build an SMTP daemon which does that; [...]

I don't know; what about it?  What does a webpage have to do with it?

My impression of spam cannibal, which admittedly was formed without
looking at it myself, is that it swallows the spam, not just rejecting
connections.   If it can be made to do this, it's probably worth at
least looking at.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: "David Nicol" <[email-masked]>
Date: Sun, 3 Aug 2008 20:37:35 -0500

On Sun, Aug 3, 2008 at 2:57 AM, Alessandro Vesely <[email-masked]>
> What about http://www.spamcannibal.org/?

spamcannibal appears to be a DNSBL that works in concert with a
tarpitting firewall modification.  That's nifty, and tarpitting the
connections to the concept under discussion here (which desperately
needs its own thread, as it is a complete departure from assertions),
which could be called mx.nomail.org (nomail.org appears to be
registered by a Czech name reselling service from their whois record,
FWTW) would probably be a good thing.  Response time is not that
important; the idea is to draw email connection attempts away when you
don't receive any.  Deferring that 550 until the end of the data,
tarpitting and discarding the whole time, could be more effective.

But setting up a mx record to something that does not exist, or to the
wrong mx, for instance mail.ietf.org -- would work just as well, but
would be somewhat rude to the domain you are mxing to.

Collecting the attempts as a spam trap, filter corpus builder?
There's a purpose.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 06 Aug 2008 11:28:18 +0200

> needs its own thread, as it is a complete departure from assertions),

The (admittedly loose) connection is that I'd rather tarpit any 
connection to mx.nomail.org (or a semantically equivalent mx denial)
than efficiently deliver 552 errors.

> tarpitting and discarding the whole time, could be more effective.

One obvious question is about the status of tarpitting w.r.t. RFCs 793 
or 1122, that SMTP relies upon. Is it a recommended action against 
spammers?

And what about filtering blacklisted IPs at the firewall level, i.e. 
blocking (reject, drop, or tarpit) their syn requests? Is it better 
than letting spammers consume our mailer daemon resources?

---

From: der Mouse <[email-masked]>
Date: Wed, 6 Aug 2008 11:07:27 -0400 (EDT)

> One obvious question is about the status of tarpitting w.r.t. RFCs
> 793 or 1122, that SMTP relies upon.

I can't think of any requirement in either of them that tarpitting
violates.  If anyone can, I'd be interested to hear.

> Is it a recommended action against spammers?

Some will recommend it.  These days I don't think it's much use.  The
only benefit I've ever seen in it is that it ties up sending threads.
But with the rise of botnet spamming, threads (and compuer resources in
general) are far cheaper to spammers than they are to receivers, so
there's little point.  (In general, botnets let spammers externalize
almost all of their computer-resource costs.)

> than letting spammers consume our mailer daemon resources?

Sometimes.

Unfortunately, that's about all that can be said without knowing more
about the environment the question is being asked for.  For example,
some sites want to keep statistics at a level of detail that's
impossible if you don't let the mailer see everything.  Others are
drowning under a sufficiently large flood that the only ways to cope at
all are to firewall off the worst offenders - or, I suppose, outsource
mail to someone with a much fatter pipe, which gets expen$ive.  (There
are endless other reasons each way, too; these are just two examples.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: "David Nicol" <[email-masked]>
Date: Wed, 6 Aug 2008 11:21:56 -0500

> almost all of their computer-resource costs.)

how about rigging mx.anybot.block.sp.am to respond with A records that point
to known botnet participants?

-- 
"don't let the perfect become the enemy of the good" -- some politician on CNN
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Wed, 6 Aug 2008 11:23:15 -0500

of course I meant to say

On Wed, Aug 6, 2008 at 11:21 AM, David Nicol <[email-masked]> wrote:
> how about rigging mx.anybot.block.sp.am as a trick A record that gives
> a list of eight random known botnet participants?

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 06 Aug 2008 12:51:16 -0400

Alessandro Vesely wrote:

> blocking (reject, drop, or tarpit) their syn requests? Is it better than 
> letting spammers consume our mailer daemon resources?

I have identified 957286 IP addresses infested with (just) Cutwail[+] in 
the past week sending an average of 5.7 emails apiece (last (approx) 30 
hours).

Secondly, some bot operators know about banner delays and tarpitting, 
and have relatively short timeouts to avoid damage from them.  Banner 
delays, while not as effective as they once were, are still working 
quite well.

The same reason that makes banner delays work (short timeout bots give 
up), makes tarpitting work less well (short timeout bots give up).

Just how much trouble do you think tarpitting causes spammers like that?

Not much.

It may help in some unusual cases with extremely stupid spammers.  Like 
Linhardt sending email to Comcast <evil grin>

Except in a few cases (very specialized MTAs or low email volumes) 
tarpitting usually causes much more trouble to the receiver than the sender.

Dropping 'em at the router is difficult, because routers (at present) 
can't be configured to hold all the IPs you'd like it to, and can only 
be used very selectively.

[+] and 669576 infested with Srizbi, with an average of 9.23/apiece 
(currently 13.62% of all spam).  Etc.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: grenville armitage <[email-masked]>
Date: Thu, 07 Aug 2008 08:47:52 +1000

Alessandro Vesely wrote:
	[..]
> letting spammers consume our mailer daemon resources?

Perhaps a little tangential, but back in 2006/2007 I had a student
implement a scheme for randomised reject/drop of inbound SYN based on
blacklists (http://caia.swin.edu.au/stockade/). A cute (although not
yet proven useful) aspect of our system was that we did the reject/drop
of TCP SYN from origin Y with a certain probability X that faded over time T.
Time T was measured from the last time we 'saw spam' from origin Y. This
amounted to an auto-rehabilitation of blacklisted origins, so that false
positives for 'saw spam' wouldn't have negative impact for more than
<some configurable number> of minutes. (I'm not sure if our software's ever
been used elsewhere, however.)

cheers,
gja

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Aug 2008 09:40:25 +0200

> the past week sending an average of 5.7 emails apiece (last (approx) 30 

[OT] May I ask if you publish them on a DNSBL?

> Just how much trouble do you think tarpitting causes spammers like that?

Thus, you are suggesting that drop, which can be considered a poor 
man's tarpit, wrt reject can be more effective. Or is the reason 
(short timeout bots give up) rooted in the fact that tarpitting exists?

> be used very selectively.

(Using a Linux box may overcome that limit)

> (currently 13.62% of all spam).  Etc.

Thanks for the insight

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 07 Aug 2008 11:13:12 -0400

Alessandro Vesely wrote:

> Thus, you are suggesting that drop, which can be considered a poor man's 
> tarpit, wrt reject can be more effective. Or is the reason (short 
> timeout bots give up) rooted in the fact that tarpitting exists?

Rooted in the fact that attempting to "negotiate" thru slow delivery is 
not in the best interests of increasing the sheer quantity of 
deliveries, whether it be tarpitting, banner delays, or just slow MTAs.

If most (or the big) receivers started deliberately slowing delivery 
then the spammers would have to change tactics again.

> (Using a Linux box may overcome that limit)

It may, and at first glance, it might seem no worse than letting the MTA 
do the queries and rejects at connect, but consider:

- the temptation, of course, is to apply the technology for more than 
just port 25.  This could cause some serious performance problems if the 
subnet (behind the router) doing this is does more than just inbound 
email - like web traffic or DNS.  Secondly, not all DNSBLs should be 
used this way.  Eg: PBL or CBL/XBL.

- timing requirements are a lot more stringent at router level.  A query 
delay that might be more than reasonable for SMTP level could cause 
legitimate connections to fail at the TCP/IP level.

If the linux box doing the router-level stuff is co-resident with the 
MX, it could be quite tractable.  On the other hand, getting, say, IPF 
to do it might be more than a minor challenge.

[I think spamd effectively does this to a certain extent, but I've not 
researched it very well.]

It'd be well to consider why Spamhaus DROP is so small.  Not only are 
there size constraints, but also the difficulty in distinguishing ranges 
that are so bad you want to drop _everything_, not just SMTP.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg