From owner-freebsd-isp Sun Dec 22 20:45:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA15567 for isp-outgoing; Sun, 22 Dec 1996 20:45:32 -0800 (PST) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA15562 for ; Sun, 22 Dec 1996 20:45:30 -0800 (PST) Received: from swoosh.dunn.org (swoosh.dunn.org [206.158.7.243]) by ns2.harborcom.net (8.8.4/8.8.4) with SMTP id XAA25297 for ; Sun, 22 Dec 1996 23:45:28 -0500 (EST) Date: Sun, 22 Dec 1996 23:40:49 -0500 () From: Bradley Dunn Reply-To: Bradley Dunn To: freebsd-isp@freebsd.org Subject: Sendmail queue processing Message-ID: X-X-Sender: bradley@harborcom.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. We have a customer that is using the ETRN feature of sendmail 8.8 to retrieve mail for their domain. We are the lowest MX for their host, and we have O TryNullMXList in sendmail.cf to make sendmail try the host directly. It is all working fine, except some, but not all, mail for their domain takes a loooong time to get delivered. For example, sometimes mail from our server to their server generates a "message undelivered after four hours" warning. They are calling in and running ETRN every 15 minutes, 24x7. Now my guess as to the problem is that the messages queued for them are locked by sendmail's normal processing of the queue. Is that a valid diagnosis? We have an unusually large queue, I suppose, as we are one of the mail relays for the FreeBSD mailing lists. Our queue usually ranges from 300-500 messages. We are using -q30m. The only solution I can think of is to up the interval between queue runs, therefore lessening the chance that the queued messages for our customer will be locked when they do an ETRN. That solution is obviously sub-optimal. I suppose the optimal solution would be to tell sendmail not to process the queued messages for this customer unless explicitly told to do so with an ETRN. Is that possible? Any ideas? -BD