Hi David, On 18 Jun 2007 at 20:33, David F. Skoll <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399
