Date: Mon, 23 Dec 1996 06:06:02 -0500 (EST) From: "R.D. Thrush" <rd@thrush.com> To: Bradley Dunn <bradley@dunn.org> Cc: freebsd-isp@FreeBSD.org Subject: Sendmail queue processing Message-ID: <199612231106.GAA08079@tarpit.thrush.com> In-Reply-To: <Pine.WNT.3.95.961222230829.-79319B-100000@swoosh.dunn.org> References: <Pine.WNT.3.95.961222230829.-79319B-100000@swoosh.dunn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've used Paul Pomes re-mqueue.pl for the past year to improve sendmail efficiency in a similar situation. (It has been in contrib/ in the past several sendmail distributions). Extracted from the source: # Rationale: With a limited number of sendmail processes allowed to run, # messages that can't be delivered immediately slow down the ones that can. # This becomes especially important when messages are being queued instead # of delivered right away, or when the queue becomes excessively deep. # By putting messages that have already failed one or more delivery attempts # into another queue, the primary queue can be kept small and fast. I run sendmail -bd -q15m and process an ave. of 25,000 messages/day. Messages start moving into the slower queues after 45 minutes in the main mqueue. >>>>> "b" == Bradley Dunn <bradley@dunn.org> writes: b> We have a customer that is using the ETRN feature of sendmail 8.8 to b> retrieve mail for their domain. We are the lowest MX for their host, and b> we have O TryNullMXList in sendmail.cf to make sendmail try the host b> directly. b> It is all working fine, except some, but not all, mail for their domain b> takes a loooong time to get delivered. For example, sometimes mail from b> our server to their server generates a "message undelivered after four b> hours" warning. They are calling in and running ETRN every 15 minutes, b> 24x7. b> Now my guess as to the problem is that the messages queued for them are b> locked by sendmail's normal processing of the queue. Is that a valid b> diagnosis? We have an unusually large queue, I suppose, as we are one of b> the mail relays for the FreeBSD mailing lists. Our queue usually ranges b> from 300-500 messages. We are using -q30m. b> The only solution I can think of is to up the interval between queue runs, b> therefore lessening the chance that the queued messages for our customer b> will be locked when they do an ETRN. That solution is obviously b> sub-optimal. b> I suppose the optimal solution would be to tell sendmail not to process b> the queued messages for this customer unless explicitly told to do so with b> an ETRN. Is that possible? b> Any ideas? b> -BD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612231106.GAA08079>