On Thu, Jun 24, 2010 at 12:08, Victor Duchovni <[email protected]> wrote:
> In situations where mail is forwarded outside the environment that > supports the local recipient delimiter (e.g. Postfix->Exchange): > > I set: > > propagate_unmatched_extesion = canonical > > overriding the default: > > propagate_unmatched_extensions = canonical, virtual > > that way, mail arrives to the right recipient on the destination system. > The recipient can still apply filters on the headers, but loses the > extension in the envelope, which is typically not tragic. Yes, that certainly eliminates the failure to deliver (or in certain cases, a misdelivery where real users have the delimiter character at the remote domain). I was thinking that a logic which could be used is this. A variable similar to the above could be used to list which tables would have this logic in effect (maybe called "map_extension_delimiter_in_lookup" ... default being null to avoid impacting existing configurations in any way). For lookup tables specified, first the local delimiter character would be appended to the username, before the @domain where applicable, and that used as the lookup key (e.g. "[email protected]"). If that lookup succeeds, then the character at the end of the username part of the result would be used to replace every instance of the local delimiter character. So with a table entry of "[email protected] [email protected]", email addressed to "[email protected]" would be remapped to be sent to "[email protected]". Of course you could have a nice mess if mail was addressed to "[email protected]" came in with that situation. I don't think this is really worth doing. But it was a curiosity.
