Philip Hazel wrote:
>On Tue, 8 Jul 2003, Russell Wilton wrote:
>
>
>>This works as expected except for one thing: when it ships a message off to
>>another host, it sends it to $local_part@mailhost. Unfortunately $local_part
>>has had the suffix stripped at that point, so mail for 'list-admin' gets sent to
>>'list', causing mail loops and other general havoc.
>>
>>
>
>This is something that has come up before. Now, what was the answer....
>
>
>>Is there any option to either the router or the transport that will make it use
>>the original local_part instead of the truncated version? Or is there a better
>>way to do this? Any help greatly appreciated.
>>
>>
>
>The previous discussion resulted in a Wish List item:
>
> (161) 27-May-03 S Don't strip affixes for RCPT commands
>
>(An generic transport option for this is the suggestion.)
>
>In the current release, we concluded that if you want to have the
>original local part in an outoing message, you should avoid using
>local_part_suffix (or prefix) in the router. Instead, you can use a
>regular expression. For example, instead of
>
> local_part_suffix = -foobar
>
>you could have
>
> local_parts = ^.*-foobar
>
>Or use a "condition" condition that does something similar. It's a bit
>tedious, but there's probably some way to hack it.
>
>
Thanks for the suggestion. In my case, however, I need both the
truncated local_part for the LDAP lookup and also the original version
to send out. I solved my problem by splitting the function over two
routers: the first to remove the suffixes, do the LDAP search and then
pass, and the second to just use the address_data to route the message.
My concern is that it took me quite by surprise that a maunaulroute
router would change the recipient address for any reason. A manualroute
option to tell it to set the local_part back to the original value
before calling the transport would be nice. Or maybe that should be the
default....
And while I'm on the topic of manualroute enhancements :-) It would be
useful if one could force a pass, fail or defer outcome by setting the
route_data appropriately, in a manner similar to the :defer: and :fail:
features of the redirect router. The functionality is partly there in
that one can set the route_data to null to get a pass, or to some bogus
value that fails and use host_find_failed to get the desired outcome.
But that's kind of circuitous and it limits one to two possible
outcomes. If it were possible to put a value in route_data that would
directly select any of the five possible outcomes that are currently
valid for host_find_failed, I would find that a useful enhancement.
Thanks for your consideration.
Russ
--
Russell D. Wilton E Mail: WILTON@???
Network Services Manager Voice: (403) 329-2525
University of Lethbridge FAX: (403) 382-7108
4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4
