Email ???

[Steve Friedman]

On Wed, 2 May 2007, Tim wrote:

> Tim (about sendmail greet pause):
>>> How does it work?  If it pauses the current connection with that server,
>>> independently of any other system trying to send you mail, then only one
>>> thing at a time gets delayed, so it shouldn't be a DOS.  But if sendmail
>>> pauses completely while one thing talks to it, and won't do anything
>>> else until that task is completed, yes, I see potential problems.
>
>
> Steve Friedman:
>> It's a DoS because the system can have only a finite number of sockets
>> open (this is both a kernel limit and a postfix tuning parameter limit),
>> and greet pause ties them up doing nothing for a period of time.
>
> This is a genuine question:  Is that actually worse than having the
> server tied up dealing with lots of spam?

The key part of my initial response is "and doesn't affect legitimate 
mail".  For example, postfix can detect pipeline violations without a 
greet pause -- using marginally more WAN bandwidth than greet pause but 
doesn't affect legitimate mail.  My other point was "just how much spam is 
blocked using greet pause that wouldn't be caught using other means".  I 
claim (without any data to back me up :-) that any spambot so poorly 
written as to be trapped by greet pause would also be trapped by less 
intrusive means (e.g., reject_rbl_client zen.spamhaus.org, greylisting, 
reject_unauth_pipelining).  Thus, you and your legitimate peer servers 
(which also must wait for the greet pause) are paying a price without 
reaping any benefit.

>
> I would imagine that anyone who wanted to try this approach, would also
> want to increase the number of sockets that could be handled, to avoid
> getting DOSd.
>

If one truly wanted to go down this path, then the "correct" solution 
would be to populate a database with the IP addresses of all peers from 
whom you have accepted e-mail and not greet pause those servers.  Then, 
like greylisting, you wouldn't affect your usual correspondents after the 
initial training period.

> It would also seem prudent to reset a connection if more traffic came
> through when you'd told it to wait.
>
>

Agreed, but if you wait to detect a pipelining violation until the DATA 
phase (rather than simply at the HELO phase), you can accomplish something 
during that time instead of just pausing.

Steve Friedman