--On Thursday, February 26, 2015 12:17 AM +0000 Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:

On Wed, Feb 25, 2015 at 02:03:52PM -0800, Quanah Gibson-Mount wrote:

--On Wednesday, February 25, 2015 9:17 PM +0000 Viktor Dukhovni
<postfix-us...@dukhovni.org> wrote:


> --- Editorial ---
> Firstly, I've always strongly discouraged "sender_canonical_maps".
> Use canonical_maps instead.  In the headers of an email message
> the canonical form of an address must not depend on which header
> it is found in.  What is initially a sender address, easily becomes
> a recipient address when someone uses reply-all.
>
> While there may be correct use-cases for "sender_canonical_maps"
> it is my best guess that almost all uses of this feature in the
> field are flawed.
> --- Editorial ---

It would not surprise me at all if this were set up incorrectly to start
with back in postfix 2.0, and has simply been pushed forward ever since.
I'll file a bug to re-examine the use of sender canonical maps here.

Note that for SRS (outbound) you MUST NOT change header sender and
recipient addresses, SRS is explicitly only an envelope transformation.

On the other hand what people generally abuse "sender_canonical_maps"
for typically rewrites header addresses.

A sophisticated user who knows what's going on might use:

        # Canonicalize all header and envelope addresses.
        #
        canonical_maps = ${indexed}canonical

        # Poor man's SRS milter
        #
        sender_canonical_classes = envelope_sender
        sender_canonical_maps = socketmap:unix:/var/run/srs:srs_sender

Carefully making sure that this is applied only to external domains
and only for email that is leaving your system (outbound edge
gateway).  And something similar on the inbound path for any bounces
that come back.

Thanks! I've moved the proxy:ldap lookup to canonical_maps with no ill effect in my testing. Now to proceed with SRS.

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Reply via email to