From: mouss (no email)
Date: Sun May 11 2008 - 08:47:37 EDT
Jack Raats wrote:
>
> I thought that reject_unauth_pipelining only works in
> smtpd_data_restrictions?
- sleep by itself works at any stage.
- reject_unauth_destination works with "synchronous" commands (commands
for which the client must read the server response before issuing
another command). RCPT TO is asynchronous (client can send multiple RCPT
TO before reading the server responses).
In the default and recommended setup (smtpd_delay_reject=yes), client,
helo, sender and recipient restrictions are executed at RCPT TO stage.
for this reason:
- reject_unauth_peipelining is useless in this case.
- if you use multiple sleep commands in client, helo, sender and
recipient, they will add up, and may possibly lead to client timeout. so
be careful here.
If you use smtpd_delay_reject=no (not recommended unless you know what
you are doing), then reject_unauth_pipelining can be used to reject
"quick talkers" (this is the "greetpause" technique Rob is talking about).
The problem with sleep is that it blocks an smtpd process. so if you
have 100 smtpd processes and you get 100 connections that you sleep on
for 15 seconds, then your postfix is losing 15 seconds (and since this
is repeated for future connections, your smtpd processes will be
spending a lot of time sleeping). This may be considered as a self DoS.
if you really want this technique, then do sleep selectively (only for
"suspicious" clients). but even then, your system is still more
vulnerable to DoS than a standard setup.
Something like OpenBSD spamd is probably a better way to implement this
technique.
> I added
>
> smtpd_delay_reject = no
> smtpd_client_restrictions =
> sleep 15,
> reject_unauth_pipelining,
> permit
> to my main.cf.
>
> > See SMTPD_ACCESS_README.html#timing for a discussion of what this
> > entails.
>
> I'm going to read that in the garden where the sun is shining :-)
> Thanks
>
> Jack
>
|
|
|