Re: recipient delimiter ambiguity
- On Thu, Jun 24, 2010 at 12:08, Victor Duchovni
> In situations where mail is forwarded outside the environment thatYes, that certainly eliminates the failure to deliver (or in certain
> 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.
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+@...").
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+@... fred-@...", email addressed to
"bob+foo+bar@..." would be remapped to be sent to
Of course you could have a nice mess if mail was addressed to
"bob+postfix-users@..." came in with that situation. I don't
think this is really worth doing. But it was a curiosity.