From: Phil Howard on
I don't see any easy fix to this.

A user has email forwarded from their address at domainA to their
address at domainB and also to their address at domainC, each running
on different mail servers (but maybe the same MTA software). The
catch is that domainA uses one recipient delimiter character (for
example '+') while domainC uses a different recipient delimiter
character (for example '-'). DomainB uses the same as domainA. So
bob(a)domainA forwards to foo(a)domainB and bar(a)domainC. Mail to
bob+xyzzy(a)domainA is forwarded to foo+xyzzy(a)domainB and
bar+xyzzy(a)domainC (not bar-xyzzy(a)domainC).

FYI, this isn't important. I just ran across it because I was using
an old server with "recipient_delimiter = -" as a test
source/destination for ongoing config changes to the new server with
"recipient_delimiter = +". Still, it would be nice if there was some
way to, as part of the mapping of bob(a)domainA -> bar(a)domainC to also
translate each '+' into '-'. The only thing I can think of at the
moment is to implement this as a TCP database (not worth the trouble).

From: Victor Duchovni on
On Thu, Jun 24, 2010 at 11:43:57AM -0400, Phil Howard wrote:

> I don't see any easy fix to this.
>
> A user has email forwarded from their address at domainA to their
> address at domainB and also to their address at domainC, each running
> on different mail servers (but maybe the same MTA software). The
> catch is that domainA uses one recipient delimiter character (for
> example '+') while domainC uses a different recipient delimiter
> character (for example '-'). DomainB uses the same as domainA. So
> bob(a)domainA forwards to foo(a)domainB and bar(a)domainC. Mail to
> bob+xyzzy(a)domainA is forwarded to foo+xyzzy(a)domainB and
> bar+xyzzy(a)domainC (not bar-xyzzy(a)domainC).

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.

--
Viktor.

From: Phil Howard on
On Thu, Jun 24, 2010 at 12:08, Victor Duchovni
<Victor.Duchovni(a)morganstanley.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+(a)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+(a)example.com fred-(a)example.net", email addressed to
"bob+foo+bar(a)example.com" would be remapped to be sent to
"fred-foo-bar(a)example.net".

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