OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: recipient delimiter ambiguity

From: Phil Howard (ttiphilgmail.com)
Date: Thu Jun 24 2010 - 11:31:19 CDT


On Thu, Jun 24, 2010 at 12:08, Victor Duchovni
<Victor.Duchovnimorganstanley.com> 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. "bob+example.com").
 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
"bob+example.com fred-example.net", email addressed to
"bob+foo+barexample.com" would be remapped to be sent to
"fred-foo-barexample.net".

Of course you could have a nice mess if mail was addressed to
"bob+postfix-usersexample.com" came in with that situation. I don't
think this is really worth doing. But it was a curiosity.