Re: Slow Performance on semi-large lists
I made the same recommendation a few months ago. Later scrutiny of how defer mode works (with 8.9.3, IIRC) uncovered that using it caused relaying checks to be bypassed entirely. I retracted the recommendation in early April: http://csf.colorado.edu/archive/2000/mj2-dev/msg00219.html
Looking at the check_rcpt section of the stock configuration files for sendmail 8.11.1, it appears that this is still the case. If so, it is probably wise for administrators who, like me, have a modest understanding of sendmail to use defer mode only on a restricted interface.
Michael
On 14 Dec 09:48, Chuq Von Rospach wrote:
Try setting
O DeliveryMode=defer
in your sendmail.cf. That causes sendmail to accept the mail without making a DNS lookup on it first. Note that this also implies DeliveryMode=queue, so stuff won't be delivered immediately. That means (if you already aren't) that you need to do queue runs aggressively using -q.
At 12:10 PM -0800 12/14/00, Michael Yount wrote:
I made the same recommendation a few months ago. Later scrutiny of how defer mode works (with 8.9.3, IIRC) uncovered that using it caused relaying checks to be bypassed entirely.
Oh, grumble.
If so, it is probably wise for administrators who, like me, have a modest understanding of sendmail to use defer mode only on a restricted interface.
what that means for Mailman is you can't tweak the sendmail.cf, and therefore can't use DELIVERY_MODULE = SMTPDirect. You'd have to instead use the Sendmail DELIVERY_MODULE (which I haven't tested, and which doesn't (sigh) use MAX_RCPTS. And you could add the -odd to SENDMAIL_CMD in the mm_cfg file to get this. But it changes other stuff, so...
Oh, grumble. It works if you spin the dead chicken three times while wearing teal socks, but not if you spin it counterclockwise in red socks, during a full moon..
Thanks for the heads-up, Michael.
Another option, I guess, is to run two sendmails on two ports, a public one using mode=queue on 25, and a second one on some other port mode=defer, but that's at best security by obscurity. Ah, the joys of sendmail...
(postfix fans can step in and start giggling any time they want...)
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> what that means for Mailman is you can't tweak the
CVR> sendmail.cf, and therefore can't use DELIVERY_MODULE =
CVR> SMTPDirect. You'd have to instead use the Sendmail
CVR> DELIVERY_MODULE (which I haven't tested, and which doesn't
CVR> (sigh) use MAX_RCPTS. And you could add the -odd to
CVR> SENDMAIL_CMD in the mm_cfg file to get this. But it changes
CVR> other stuff, so...
Two things to note. First, if people want to get serious about Sendmail.py, someone please fix it not to go through the shell (i.e. don't use os.popen()). It's not hard to fix, just tedious and I don't want to spend the time on it. I'll take contributions of course. Be aware that in 2.1 DELIVERY_MODULE will probably not be part of the mainline message pipeline.
Second, someone posted patches to Python's smtplib.py so that the same interface can be used to "sendmail -bs" (i.e. sendmail run from the command line with SMTP commands on standard input). I don't remember who or where that was posted, but it's worth searching for and proofreading. Or if the original author is reading this, resend me the url and I'll see about getting it into Python 2.1.
Does sendmail do the same synchronous DNS lookups when used in -bs mode?
giggle-ly y'rs, -Barry
At 10:20 PM -0500 12/14/00, Barry A. Warsaw wrote:
Does sendmail do the same synchronous DNS lookups when used in -bs mode?
yes, but you can add another flag to turn it off (I think... -odd)
fitting flag, now that I look at it.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
We're visiting the relatives. Cover us.
participants (3)
-
barry@digicool.com
-
Chuq Von Rospach
-
Michael Yount