On Mon, Aug 13, 2012 at 06:36:48PM +0200, Andreas Ntaflos wrote:
> On 31/07/12 23:21, Viktor Dukhovni wrote:
> >> I see, thank you. In this case I don't think I can implement this in any
> >> other way than with recipient_canonical_maps on the null client itself.
> >
> > Don't use recipient_canonical_maps, use either virtual_alias_maps
> > to update the envelope recipient only, or else canonical_maps to
> > update all envelope and header addresses.
>
> What is wrong with recipient_canonical_maps so that virtual_alias_maps
> is preferable in this case? Genuinely interested, not trying to
> second-guess you.
>
> With recipient_canonical_maps we have set recipient_canonical_classes to
> "envelope_recipient", so it doesn't touch the mail headers. Isn't that
> good enough?
With recipient_canonical_classes set to "envelope_recipient" you
reduce the functionality to that of virtual_alias_maps, with the
further constraint that the mapping is one-to-one.
This can easily be accomplished more directly via virtual_alias_maps
instead, by just putting in the desired one-to-one entries, there
is no need for a second table.
So the only thing wrong with the recipient_canonical_maps approach
in this case is that it is not "natural" and triggers additional
table lookups.
What I more generally object to is naive use of
{sender,recipient}_canonical_maps to rewrite some headers differently
than others. Since the role of a header is context dependent, there
is IMHO no robust distinction between sender and recipient headers,
they are all just email addresses.
One should generally use some combination of canonical_maps,
virtual_alias_maps and if necessary smtp_generic_maps and stay
well clear of sender_canonical_maps and recipient_canonical_maps.
--
Viktor.
