On Fri, 18 Feb 2000, John Horne wrote:
> Well, whilst I have now got the idea of what I wanted sorted out, trying to
> achieve it proved a little harder than I expected. To handle unknown users I
> now have the following transport/director:
>
> unknown_user: (transport; the same as before)
> driver = pipe
> command = "TABLES/messages/unknown-user.sh"
> ignore_status
> return_output
> timeout = 10m
> user = exim
>
> unknownuser: (director)
> no_expn
> no_verify
> debug_print = "In unknown dir, reply is $reply_address, return is
> $sender_address\n"
> transport = unknown_user
> driver = smartuser
> new_address="${if and {{match {$reply_address} \
> {(?i)@plymouth\\\\.ac\\\\.uk\\$}} \
> {! match {$h_precedence:} {(?i)junk|bulk|list}}} \
> {$reply_address} {$sender_address}}"
After some pondering, I think I see your idea. You are expecting
new_address to change the envelope address so that the bounce message
goes to that address. But new_address changes the *recipient* address,
not the sender address. So that setting of new_address has no effect at
all. The bounce message (presumably provoked by your pipe returning
output) still goes to the sender address.
> This looks good. The director is called, the $reply_address is s.roberts and
> the $sender_address is j.horne.
>
> generated new address: sroberts@???
Maybe that should say "generated new *recipient* address" ??
> queued for unknown_user transport: local_part=sroberts
> domain=csuf11.csd.plym.ac.uk
Again, *recipient* addresses.
> Any ideas as to what is going on, why I get the failure message rather than
> sroberts despite what exim says.
Exim doesn't say what you think it does!
What you need to do is to look at the bounce messages, not at the
incoming failing messages. Or alternatively, you need to change your
TABLES/messages/unknown-user.sh script so that instead of generating
output, it creates a new message to the right user and passes it to (a
new incarnation of) Exim.
Doing the former is messy because you have to cope with both local and
remote domains.
1. Keep your current set up, but instead of new_address, use header_add
to add a magic header in the case you are interested in, e.g.
X-Plymouth-Magic-real-recipient: sroberts@???
2. Then add a new director to handle local domains along the lines of:
redirect_bounce:
driver = smartuser
condition = ${if eq{$h_X-Plymouth-Magic-real-recipient:}{}{no}{yes}}
headers_remove = X-Plymouth-Magic-real-recipient
new_address = $h_X-Plymouth-Magic-real-recipient:
3. Then add a router to force messages for remote domains to the
director:
redirect_bounce:
driver = domainlist
condition = ${if eq{$h_X-Plymouth-Magic-real-recipient:}{}{no}{yes}}
route_list = * localhost byname
self = local
That is all *far* too hackish.[*] I think you would be much better off
adopting the approach of piping unknown deliveries to a script which
generates its own bounce message not by returning output, but by
submitting a new message.
[*] and possibly a security hole if people send messages from outside
containing the magic header.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.