Re: [Exim] Forgetting delivery attempts....

Góra strony
Delete this message
Reply to this message
Autor: Adam Thornton
Data:  
Dla: exim-users
Temat: Re: [Exim] Forgetting delivery attempts....
On Mon, 2003-11-03 at 03:36, Philip Hazel wrote:
> On 2 Nov 2003, Adam Thornton wrote:
>
> > However, consider the following scenario--local ports I map are in the
> > range 50000-50049--I get a mapping of vm:50002 for a remote host and
> > port that has a transient error.
> >
> > Now, when I retry that host, Exim is going to retry vm:50002--but 50002
> > is no longer hooked up to anything. What I want to do is forget that
> > mapping and just run the transport again, so I get a new host (still vm)
> > and a new port (let's say it's 50000) this time.
>
> I don't think I fully understand this. Assuming you have patched Exim so
> that the port is looked up each time the transport is run, Exim won't
> automatically try the old port again, because you've computed a new one.
> So is there really a problem?


There appeared to be, in that there was outgoing mail stuck in the queue
until I manually established the port mapping and then flushed it. My
question, I guess, is, if it's in the queue, waiting for a retry, does
Exim attempt another MX lookup on the RCPT hostname, or does it use its
cached data? If it re-runs it from scratch, then I should be OK,
because ${run{...}} will also run, and I get a brand-new port
associateion. But if it relies on its cached information, then that
cache is stale.

The behavior of the queue seems to indicate it was the second, but I
need to do more testing.

> That will expire all retry data for all hosts, which may not be what you
> want. Another way would be to set very short retry times for the host in
> question. Something like
>
> host.name * F,1w,1s


Thanks. Actually, for me, it will have the same effect; *all* outgoing
mail gets forced through the VM proxy, so all external host names map to
vm. However, I can envision a situation in which some mail (say, that
going off-campus) didn't need to go through the proxy, while the rest
did, so that would be a better solution.

> But, as I said above, I'm not sure you really need this. Unless, of
> course, you do want to try vm:50002 every time it comes up.


Well, it surprised me too, but it appears that I need it. I will, I
hope, be able to iron out just what is going on later this week.

Adam