From owner-freebsd-isp Mon Aug 3 14:11:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA09562 for freebsd-isp-outgoing; Mon, 3 Aug 1998 14:11:38 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from postman.true.net (s1.admin.true.net [161.196.66.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA09532 for ; Mon, 3 Aug 1998 14:11:24 -0700 (PDT) (envelope-from lem@cantv.net) Received: from s2.admin.true.net (mail.cantv.net [161.196.66.21]) by postman.true.net (8.8.7/8.6.12) with ESMTP id RAA25157; Mon, 3 Aug 1998 17:11:10 -0400 (VET) Received: from lem.cantv.net (root@localhost) by s2.admin.true.net (8.8.7/CS-R-1.4) with SMTP id RAA08778; Mon, 3 Aug 1998 17:10:15 -0400 (VET) X-BlackMail: ws-7.chacao-01.int.cantv.net, lem.cantv.net, lem@cantv.net, 200.44.44.23 X-Authenticated-Timestamp: 17:10:15(VET) on August 03, 1998 Message-Id: <3.0.5.32.19980803170130.008b78d0@pop.cantv.net> X-Sender: lem@pop.cantv.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 03 Aug 1998 17:01:30 -0400 To: leifn@internet.dk From: Luis Munoz Subject: Re: ETRN troubles Cc: freebsd-isp@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:49 PM 03/08/1998 +0200, Leif Neland wrote: >Our mailserver is secondary MX for several dialin-nodes, which pick up >their mail by ETRN > >Sometimes when a dialin node wants to receive its mail and issues an ETRN, >it doesn't receive it. > >Could it be because sendmail has already started trying to deliver it, >while the node is off-line, and therefore the mail is busy, or because it >has already been tried to be delivered a few minutes ago, and therefore >sendmail won't deliver it so soon? The locks on the mail queue affect a single piece of mail (ie, you lock a message and not a site) so I think this is rather difficult. The ETRN command behaves (or should behave) like a sendmail -qRxxxx which invalidates any history information you could have about the particular destination, if you have that option set. >Should (and can) I persuade sendmail to never try to deliver to nodes >doing ETRN before they ask for it? Or only try to deliver once, and then >just queue the mail for pickup? If you have a machine dedicated to this task, this is as simple as having sendmail not run the queue periodically and configure it to always queue mail. This would do what you want, however I don't think this can solve the problem... I would suggest that you track the software on the client side to look for some pattern there (MS products? ;) Another alternative would be to define a high-numbered port for each customer of this kind of service and use inted.conf to tie this to a sendmail -qRxxxx -v and the customer can execute a telnet to that port (and see any errors also :) We've done this with enough success to maintain it, but I believe ETRN is a cleaner solution if you can afford a server for this. Regards. -lem To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message