On Wed, Mar 14, 2001 at 09:27:07PM -0500, Dave C. wrote:
>
> On Wed, 14 Mar 2001, Oliver Cook wrote:
> 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?
I should hope that the carbon-based variety would understand "not allowed" :)
> 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)
Yes I could modify the source to say that; basically I'm just trying to give
the customer as much information about what's happening to their mail as is
possible.
> > 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.
Even so, my main problem with this recipe is that exim will consider the
messages "delivered" and say as much in the logs. Which might be a bit
problematic since the support department have read access to these logs and will
tell the customer "yes well i'm sure that mails been delivered because it says
it has been...". Whereas if it's on the queue...
> 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..
Yes, although I am convinced their is a half-way house; it's just a case of
giving enough information to the remote mailer to make it worthwhile.
It's a shame that the bodge that is ETRN is in such widespread use and demand
for business. I don't really like it as a concept either, but it's one of these
"customers want it so we offer it" kind of things.
Thanks for replying Dave it's nice to bounce ideas about.
Ollie
--
Oliver Cook Systems Administrator, ClaraNET
ollie@??? 020 7903 3000 ext. 291
