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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com