From: Phil Howard on 24 Jun 2010 11:43 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 24 Jun 2010 12:08 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 24 Jun 2010 12:31 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.
|
Pages: 1 Prev: lmtp concurrency configuration Next: Documentation patch: Re: postmap -q and ldap |