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

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Magnus Holmgren
CC: exim-dev
Subject: Re: [exim-dev] RFC: implementing 551-redirection (client side)
On Tue, 25 Jul 2006, Magnus Holmgren wrote:

> 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.


... but you would have to do all the other routing first, in order to
find out where to do the callout, so I'm not sure how this would fit in.

After some thought, my feeling now is that the simplest way of "bolting
on" this functionality to the existing code is to do it all in the
deliver.c module, at the end of a delivery process. The 551 would up
till then be treated as a failure, and Exim would be about to create a
bounce message.

At that point, it should be possible to notice that the failure was a
551, and (optionally, of course) do something different. What should be
done? The most convenient, I now think, would be to submit a new message
to Exim for the redirected recipient, and mark the original recipient as
"delivered". A new logging flag (like => and -> and *>) would have to be
invented (possibly +>).

This works well because (a) you can add an X-Redirected-551: header line
so that the information about what happened is preserved in the message
(as well as being logged), (b) looping is automatically handled by the
Received: header counting, and (c) there is no significant delay. The
disadvantage is that the message passes through Exim twice.

The alternative would be to change the recipient and wait for the next
queue run, but that does not give you (a), (b), or (c).

-- 
Philip Hazel            University of Cambridge Computing Service
Get the Exim 4 book:    http://www.uit.co.uk/exim-book