Re: [exim-dev] RFC: implementing 551-redirection (client sid…

Top Page
Delete this message
Reply to this message
Author: Magnus Holmgren
Date:  
To: exim-dev
Subject: Re: [exim-dev] RFC: implementing 551-redirection (client side)
On Monday 24 July 2006 16:35, Tony Finch took the opportunity to write:
> On Mon, 24 Jul 2006, Robert Millan wrote:
> > - We're a forwarder, smtp'ing to the next hop after we parsed
> > ~/.forward. - We're a sender, smtp'ing to the next hop after we got a
> > 551.
> >
> > Can we handle #2 the same way #1 is?
>
> No, because #1 is a routing operation which happens entirely before the
> transport phase.


Has anyone suggested doing callouts during routing? I'm thinking of a new
router that works similarly to the redirect router but uses SMTP calls
instead of lookups. Not so efficient perhaps, with an extra connection that
is in most cases of no use, but transparent and modular, and if 5yz's or
4yz's other than 551 are encountered, the router fails or defers, saving the
extra call. A 250 means that the router declines. Existing code should take
care of redirection loops, right? Caching is possible. It works in
combination with recipient callout verification. Those "random" callouts to
check whether a remote host accepts anything help too.

The only problem is when the callout returns 250 but the actual delivery
results in a 551. In that case I think delivery has to be deferred so the
address can be rerouted.

-- 
Magnus Holmgren        holmgren@???
                       (No Cc of list mail needed, thanks)