On Wed, Mar 14, 2001 at 08:44:04PM +0000, Philip Hazel wrote:
> On Wed, 14 Mar 2001, Oliver Cook wrote:
>
> As I say in the manual, and have said elsewhere:
>
> Exim is not designed for storing mail for dialup hosts. It is designed
> as a program for delivering mail. It is not designed to be a program
> for storing mail for specific hosts.
Point taken, although this is as much of an issue for dial-up hosts as
it is for our leased line customers who have trouble keeping Exchange up
for more than two minutes at a time! I can understand your problem with
dealing with mail for intermittently connected hosts, however.
> Of course, people use Exim for things it was never designed for. That is
> the fate of all artefacts. However, although you can chisel a piece of
> wood with a screwdriver, and bang a screw in with a hammer, it isn't
> very pretty.
:)
> addresses - it looks at all the recipients of the messages. (It's got
> the message open; it might as well take a look at all the recipients.)
Absolutely; although on our corporate "store and forward" servers the
messages will generally only have one recipient. But that's of little
importance to this thread.
> Exim originally did not have ETRN. People kept asking for it, and as I'm
> a helpful kind of guy :-) I cobbled something together. The first
:)
> possible. The best it can do is what -R does: "deliver messages
> addressed to this *domain*".
... which is in fact ideal for our customers who issue commands such as
ETRN corporatedomain.com - although it's not what's specified in the RFC
it seems to be quite a common usage of the command.
> > Imagine a situation where you want to put a wrapper, say, around
<SNIP>
> > |251 OK, no messages waiting for node <x>
>
> It doesn't know the answer to that.
... but the wrapper might do, if it were to run, say:
exim -bp|grep domain.com|egrep -v -e "-[0-9][0-9]" -c
(which, on second thought isn't quite accurate if there is more than
one recipient of said domain in a particular message... but since the
remote mailer will most likely deliver them to separate mail boxes isn't
really an 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
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.
> 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.
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
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
