On 19-Feb-00 at 11:46:15 Philip Hazel wrote:
> On Fri, 18 Feb 2000, John Horne wrote:
>> 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.
>
Well likewise after some pondering I think I now understand your answer :-)
The use of 'recipient' and 'sender' was getting very confusing. Yes, I want
the bounce message to go back to the 'new_address'. I know understand what
you are saying about new_address in that the recipient of the message is
changed (in this example it was originally the unknown user
'buster@???' and all I did was change that to
'sroberts@???'). And yes, the bounce is produced by output of the
pipe, and since the 'sender' hasn't change it goes back to them. Not what I
wanted or expected! :-)
>> 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" ??
>
Perhaps so. However, I (correctly) thought that 'new_address' meant a
new recipient address, it was just that this was ignored because a bounce
was produced by the transport which used the sender address - thus ignoring
any new recipient address I set/generated.
> 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.
>
Yes, I think I would agree that a new script is required. It is 'annoying'
since this seems to have worked well for a long time now - since we first
used exim! However, even today we have found that Mercury (the file server
MTA) causes us other problems in that it ignores certain 5xx errors :-(
Many thanks again for the explanation and a suggested way forward :-)
John.
--------------------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: jhorne@???
Finger for PGP key: john@???
