[Top] [All Lists]

Re: Proposal: Using Conservative EHLO Response Parser Behaviour For Tarpitting

2007-06-18 17:25:57

Sabahattin Gucukoglu wrote:

This is fine providing that the client can't pipeline. If the client tries to, it should be shot. The danger is, as David mentioned, in assuming that timeouts will be honoured by anyone. That's why I propose my alternative.

IMO, you can't design software with a negative idea that no one is going
to follow the standard.  You have to work the the idea that they WILL
honor the timeouts. If not, they will are simply not compliant.  Not
your fault.  I doubt any one can engineer a reliable and working system
based on chaos and random behavior.

By the way, just in case someone needs a rationale for killing off clients that talk prematurely: the idea is that a lot of broken spambots don't actually know what a continuation line is.

Sure, but in our experience, it is better to follow SMTP behavior than to prematurely knock off clients. What can happen here is that you can actually create redundant retries.

They will go on issuing commands under the assumption that they have a complete, one-line response when it becomes available.

Actually, what I have seen is that most will just drop, unless they were just dumping - behaving like a pipeline client, which most won't care whether the server supports pipelining or not, they are just dumping.

If you follow what you need to do and stop worrying about them, it will all work out.

Most spammers are 100% relying on the purity of a legacy SMTP system, with the cat's meow being the system that behaves like an "open relay" system:

    a) doesn't do any kind of checking,
    b) doesn't do local or hosted recipient validation,
    c) pretty much accepts everything (250 at all levels).

Which means that an idea that requires client change most likely will not have a high payoff unless you have an enforcement concept.

I see no reason why your variation should have less success, and would be
very interested in seeing a comparison if you're able to carry one out.

As I said in my previous message, not just yet. I'm just floating an idea for the moment. When I have some more time ...

Sabahattin, SMTP patterns have long be studied.  If there was any
meaningful AVS idea here, it would of been invented by now.

In my view, the best ideas are those that follow and enforce "SMTP compliance" and does recipient validation at the SMTP level.

To me, tarpitting and response delays doesn't help your system scalability. Other than you simply controlling your loads, putting clients on a connection queue and if they don't want to follow SMTP expected behavior, they can drop with no harm done to you.

Also, those that wish to not Listen to "response" are also handled gracefully with error counts.


Hector Santos, CTO

<Prev in Thread] Current Thread [Next in Thread>