On Wed, 14 Mar 2001, Oliver Cook wrote:
> On Wed, Mar 14, 2001 at 08:44:04PM +0000, Philip Hazel wrote:
> > On Wed, 14 Mar 2001, Oliver Cook wrote:
[...]
Just my $0.02 on this issue.
> > > |252 OK, pending messages for node <x> started
> > > |253 OK, <n> pending messages for node <x> started
> > > |458 Unable to queue messages for node <x>
> > > |459 Node <x> not allowed: <reason>
> >
> > Not sure I understand what those mean.
>
> My reading of them vaguely translated them to this in my mind:
>
> 252 OK, started sending messages to <remote-mailer>
> 253 OK, started sending messages to <remote-mailer> and there are
> <n> of them
> 458 Oops, wrapper broke when trying to send out messages for
> <remote-mailer>
> 459 <remote-mailer> is not allowed to issue ETRN commands
I beleive 'host not allowed to issue ETRN' is in fact supported.. I
beleive it uses a 5xx code though. But really, how many clients (the
automated kind, or the carbon-based kind) would pay any attention to
this or have any idea what it meant anyway?
> In each case, I don't think this means it's trying to send all messages
> that are in the queue for <remote-mailer>, but only those which match
> the argument specified for ETRN. The <remote-mailer> bit is just to
> say which host requested that <domain>'s emails were dequeued.
>
> > I will consider, for Exim 4, an option that says "wait for the command
> > and use its stdout as the SMTP response". In this context "consider"
> > means "take a look at the code and see this is an easy thing to add with
> > only a few lines of code".
>
> I'd be very grateful. The current situation works with -R, but I can
> see a situation occuring where, if we decide to employ a wrapper, a
> customer will say, your server said 250 OK, but it didn't send out mail.
I interpret the '250 Ok'
to mean:
'Ok, I will transmit any mail which is waiting for you'..
and if you don't get any mail, then there wasnt any. This of course
ignores local error conditions (which are really the problem of the
admin of the local site)
> > If you are seriously into storing mail for dial-in users (which I guess
> > you might be since you are at clara.net), you should not really be using
> > -R. You should instead deliver the mail into files on the server, in
> > BSMTP format, where they can wait off Exim's queue. There was an elegant
> > sample config published which did this for messages that couldn't be
> > delivered within n minutes; when the ETRN kicked, the messages were
> > re-submitted to Exim with -bS. Thus, it avoided having to have another
> > program to do the final delivery.
>
> I had a quick peek at that earlier on.. C037 I think it was. It didn't seem
> ideal though; I have a problem with delivering mail to a file, if that isn't
> going to be the mail's final resting place. If it's got another hop to go
> along it ought to be 'in a queue' of some sort; but I guess that's just a case
> of me being peculiar. In any case, the customers quite like it being on
> the queue in case they "forget" to issue an ETRN when they have their mail
> server back up, and it can be delivered by the next queue runner.
Even when mail is in exim's 'queue' it is still in 'files' ;) Its just a
question of which files, maintained by which program or subsystem. But
if mail for a given domain cannot be delivered becuase the host is
unreachable (and is known to often and frequently unreachable, as i the
case with a host connecting via a modem [analog or ISDN]), then it sucks
to have to have exim slough through all those messages when running the
queue before it gets to messages which _can_ be delivered immediately.
Basically, tossing the mail off to an alternate file sort of mimics the
'queue for a specific host (or domain)' concept that exim does not
implement directly. [I should mention that I am the submitter of C037,
so I may be biased:>]
If a client is using ETRN they take the responsibility for ensuring
their software issues the ETRN when they are able to receive mail and
wish it to be transmitted - otherwise dispense with ETRN and just have
exim retry at reasonable (as defined by you) intervals to see if they
are there..
> Just to clarify, this isn't about dial-up users and mail punting to them over
> SMTP, it's more a case of corporate customers for whom we are secondary MX,
> and who can't keep their mail servers up for long! It's also, to a lesser degree,
> corporate customers who insist on using ISDN. Mail for dial-up users is handled
Just a nitpick - ISDN is technically still 'dialup'. Regardless, the
comment could more properly have read
'... storing mail for intermittently connected (or intermittently
operable, if that is the case ;) hosts ...'
Personally I would only recommend or support ETRN for hosts that were
truly intermittently connected, and not in the case of the admins not
being clueful enough (or running reliable enough MTA software) to keep
their systems running.
Actually, to be completely accurate, I do not recommend ETRN at all but
am forced to support it - UUCP far more reliably implements the 'store
and forward concept' - but regardless of the fact it is viwed as
obsolete that there is nothing which obsoletes it for that case. Exim of
course does not directly implement UUCP but it is fairly trivial to
implement it with appropriate routers and transports (I can speak from
experience as Ive actually done this)
> by separate servers and delivered for pickup by POP3.
>
> I will probably (neigh, almost certainly) see if I can munge together something
> that would allow something close to what I mentioned about the wrapper. If I can
> get it together tidily I'll submit a patch in case you want to use it.
>
> Thanks for the detailed reply, Philip.
>
> Regards,
>
> Ollie
>
> --
> Oliver Cook Systems Administrator, ClaraNET
> ollie@??? 020 7903 3000 ext. 291
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
--
