ckp@micro.lucent.com (Andrew Winkler) wrote:
>
>First of all, only in the smallest installations would anybody _not_
>segregate the list handling onto a separate listserver. Moreover, any
>kind of mail hub, including a listserver, would of course be running with
>at least (and I would argue at best...) a caching only name server.
I tried that with sendmail and found that the nameserver was a
resource hog and it was actually slowing things down. Haven't tried it
with qmail, though--qmail does fewer DNS lookups. I'm a little leery
of having to maintain another nameserver since BIND has been having
security problems.
>I agree, in general, that any packet is merely a request, and the full
>onus of dealing with that request lies with the recipient. Having said that,
>it may not be so easy for an smtp listener to know not to fork again to answer
>a second connection request. This is particularly a problem for those starting
>sendmail from inetd.
That's a problem with inetd. Dan Bernstein, qmail's author, has also
written something called ucspi-tcp, which contains "tcpserver", which
most qmailers use to kick off qmail-smtp since it supports unlimited
connection rates, concurrent connection limits, and tcp_wrapper-like
access control. It'll work with sendmail, too.
>Don't you just hate natural selection?
Er, no.
-Dave
Follow-Ups:
References:
|
|
