Date: Mon, 03 Aug 1998 17:01:30 -0400 From: Luis Munoz <lem@cantv.net> To: leifn@internet.dk Cc: freebsd-isp@FreeBSD.ORG Subject: Re: ETRN troubles Message-ID: <3.0.5.32.19980803170130.008b78d0@pop.cantv.net> In-Reply-To: <Pine.BSF.4.02.9808032142280.3294-100000@darla.swimsuit.int ernet.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19980803170130.008b78d0>