Hi David,
On 18 Jun 2007 at 20:33, David F. Skoll <dfs(_at_)roaringpenguin(_dot_)com>
said:
Sabahattin Gucukoglu wrote:
They will have to assign more
threads/processes to each machine to process the deliveries, which would
endanger the client host system (to presumably noticeable levels);
You'd be AMAZED at how many people don't notice when their Windoze machine
is balky/misbehaving/unresponsive. For many people, that's the normal
state of affairs. :-)
Aye, you've got a point there. :-)
[...]
means we can put greater demand on each host while it is doing absolutely
nothing but reading continuation lines from, I don't know, 50 different
smarthosts it is planning to slam, then all the better.
You don't have a criminal mind. :-) Spam-sending engines can be *highly*
optimized. They need not be multithreaded; they don't queue messages. A
simple highly-efficient event-driven sender can probably occupy 5,000 SMTP
servers without putting noticeable load on the client. Multiply that by
tens of thousands of spambot machines, and you see the scale of the
problem.
Yes, I'd actually intended on doing a lot of operations in my MTA using
nothing but pure events (only disk I/O may block, so that's the only thing
you need workers around for). (I must be a spammer. :-) ) But putting
that aside, aren't you giving these spammers quite a bit of credit for
brains and familiarity with these swish programming ideas? We have seen
better spam-sending behaviour in company-developed hardware than in
ratware (think Ironport). Now, don't get me wrong - I'm not asking to be
DoSed (please :-) ). However, there are more factors to spam delivery
that make a lot of the efficiencies they used to take advantage of in open
relay days back then an impossibility now. Personalised mails, for
instance, to get around hash-based detection or pull off social
engineering stunts. Or word salad and unique headers or EURIs, to get
around bayes filtering and net-based queries. (If you can keep your food
in your stomach, find the documentation for one of these pieces of
slimeware.) And the hardcoded fd limits in most personal OSs that no end-
user could ever tweak by himself and which probably isn't as easy as a
single system call for a spambot to do.
Of course, if you're a spam king with some common sense, you'd want your
mail sent from a Unix machine where the program you described would be
running a hardcore job. Then again, you'd just note that Postfix was very
fast on such an OS at that, and use that instead. And every now and then,
I can actually confirm this happening (qmail's another popular one).
Please go back and read my original message again. I think you missed
the point. Pausing at the greeting is not an option because there is no
way to make the client hold the line at that stage for longer than it
wants to.
There is no way to "make" optimized ratware clients written and used by
criminals to do anything either.
No, there isn't, but the objective is to make those who are willing to
wait, wait (including spammers that take the bate). Normally, clients
that give up before the RFC-defined timeout are a problem, which is why
greet_pause has limited usefulness. So this is a greylisting replacement
and/or a glorified greet_pause option.
It works because greylisting doesn't waste server resources and (if
properly implemented) doesn't unduly inconvenience legitimate clients. This
proposal *will* inconvenience legitimate clients. If AOL (for example)
discovers that 1% of its outbound connections are being tarpitted, I'm darn
sure they'll announce that they refuse to stand for it and simply won't
deliver mail to would-be tarpitters.
(Putting aside the fact that AOL already has quite an attitude for doing
things their way and no other ...) The proposal suggests a very short
tarpitting time; the objective is to hang on to the address that's calling
so that the delivery doesn't have to be delayed any further than the
initial tarpitting time per cycle, because otherwise the mail may arrive
on another address and be delayed further. Tarpitting is not the primary
objective, we simply don't want the client to drop off before a given
amount of time as it might otherwise be tempted to do. Five minutes a
month to any given organizations' smarthosts isn't going to bankrupt any
reasonable site, no matter how disperse the mail. Greylisting, while it
may not take up resources, will suffer from the address problem (the
resolutions either require administrative help, RBLs or diminished
effectiveness, but I take your points about the implementation) and, for
those MTAs which don't prefer to queue mail unless they have to (like Exim
3, not sure about 4.5), *is* an inconvenience. Perhaps it's a matter of
perspective, or maybe I just wish more people would run their own MTA.
But so long as your mailer were sufficiently robust, it probably wouldn't
actually notice any given delivery being tarpitted briefly and the
likelihood of its being simultaneously tarpitted by enough destination
sites as to cause it ill-health is probably quite small (and, in any
event, something the client should not be trying to do anyway).
Cheers,
Sabahattin
--
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399