On Wednesday, April 4 at 11:08 PM, quoth Sami Farin:
On Wed, Apr 04, 2007 at 12:50:32 -0600, Kyle Wheeler wrote:
Hello,
Because of some recent spammer behavior (looks like
reverse-tarpitting), I'm considering reducing my timoutsmtpd value
Are you using bannerdelay feature?
Yes; but that's not what's keeping connections open. The offending
connections are averaging around 1200 seconds in length (i.e. the
timeoutsmtpd default), which is way longer than my initial delay
(which maxes out at 26 seconds).
Are there drawbacks to lowering my timeout value that I'm not
thinking of? Has anyone done this before and have any reports as to
possible
Some SMTP clients (e.g. postfix, zmailer, ...) keep the connection open
in case some new email for the domain needs to be delivered
(mailing lists are a good example).
Hmmm. That sounds a reason to stick to the RFC. Not that I'm terribly
concerned about forcing clients to open new connections as necessary.
I think I'm more worried about very slow connections (e.g. receiving
mail from small rural ISPs or extremely busy ISPs (a.la. hotmail)).
If you make the timeout very small, they just have to make more
connections. Not necessarily very worrisome, but what
if they think your SMTP server keeps dying for no reason
and slow down deliveries or something?
Well, it isn't dying for no discernible reason; it spits out "421
timeout" to the client before disconnecting. So if they pay attention
to such errors, it should be clear that I'm not being entirely
capricious.
If this seems to happen, you can always add TIMEOUTSMTPD env var
feature =)
A fair point. :)
~Kyle
--
The most incomprehensible thing about the world is that it is
comprehensible.
-- Albert Einstein
pgpX0mNGjCtzV.pgp
Description: PGP signature
|