receive_override_options=no_bcc_mappings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

receive_override_options=no_bcc_mappings

karavelov
Hello,

For our setup here we needed to selectively disable BCC mappings without disabling the other mappings. So attached is a patch that adds this capability to receive_override_options . It does not change any other behavior.

The patch is against v2.8.3. I hope that it will be integrated in some next version of the server.

Best regards & great software BTW
Luben Karavelov

postfix-no_bcc_mappings.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Victor Duchovni
On Thu, Jun 16, 2011 at 12:44:36AM +0300, [hidden email] wrote:

> For our setup here we needed to selectively disable BCC mappings without disabling the other mappings. So attached is a patch that adds this capability to receive_override_options . It does not change any other behavior.
>
> The patch is against  v2.8.3. I hope that it will be integrated in some next version of the server.

A cleaner solution is multiple Postfix instances, each configured for
the job at hand.

        http://www.postfix.org/MULTI_INSTANCE_README.html

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Wietse Venema
In reply to this post by karavelov
[hidden email]:
> Hello,
>
>For our setup here we needed to selectively disable BCC mappings
>without disabling the other mappings. So attached is a patch that
>adds this capability to receive_override_options . It does not
>change any other behavior.

I don't understand this.

Apparently you can't use receive_override_options=no_address_mappings
because you need virtual alias or canonical mapping on both sides
of the filter?

I would expect that such things either before or after the
filter but not on both sides.

        Wietse

>The patch is against  v2.8.3. I hope that it will be integrated in
>some next version of the server.
>
>Best regards & great software BTW Luben Karavelov
>
>[ Attachment, skipping... ]
>
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

karavelov
In reply to this post by karavelov


----- Цитат от Wietse Venema ([hidden email]), на 16.06.2011 в 01:18 -----
[hidden email]:
Hello,

For our setup here we needed to selectively disable BCC mappings
without disabling the other mappings. So attached is a patch that
adds this capability to receive_override_options . It does not
change any other behavior.

I don't understand this.

Apparently you can't use receive_override_options=no_address_mappings
because you need virtual alias or canonical mapping on both sides
of the filter?

I would expect that such things either before or after the
filter but not on both sides.

Wietse

We do not use it before/after filter. The setup is that BCC mapping is only needed for sending outgoing mail (we send a copy to the "Sent" folder) so we enable BCC mapping by default (in main.cf) and disable it on default smtpd that handles incoming mail (we obviously need the other mappings there but do not need bcc mappings).

The setup is somewhat unusual but it was decision made a long time ago. I would not argue if this is a good idea but the reason is every client (even clients with POP3 setup) to have copy of the sent mail. Until now it was working with separate instance of Postfix just for this (and separate instance for SPAM filtering etc). I find easier to care for one postfix config (instance) than a number of them. So I am in a process of consolidating them.

Best regards
Luben


Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Wietse Venema
Wietse:
> Apparently you can't use receive_override_options=no_address_mappings
> because you need virtual alias or canonical mapping on both sides
> of the filter?

[hidden email]:
> We do not use it before/after filter. The setup is that BCC mapping
> is only needed for sending outgoing mail (we send a copy to the
> "Sent" folder) so we enable BCC mapping by default (in main.cf)
> and disable it on default smtpd that handles incoming mail (we
> obviously need the other mappings there but do not need bcc mappings).

I see. What about using this instead?

    /etc/postfix/master.cf
        smtp            inet  n       -       n       -       -       smtpd
             -o sender_bcc_maps=
        submission      inet  n       -       n       -       -       smtpd

    /etc/postfix/main.cf:
        sender_bcc_maps = maptype:mapname

Or this?

    /etc/postfix/master.cf
        smtp            inet  n       -       n       -       -       smtpd
        submission      inet  n       -       n       -       -       smtpd
            -o sender_bcc_maps=maptype:mapname

I am reluctant to add no_bcc_mappings, because that would make BCC
mappings be a special case, and special cases make systems more
difficult to understand.

To avoid the special case, I'd have to also implement support for
no_canonical_mappings, no_virtual_alias_mappings, and for
no_address_masquerade. Otherwise, people would be wondering why
they can turn off one feature and not the other.

> The setup is somewhat unusual but it was decision made a long time
> ago. I would not argue if this is a good idea but the reason is
> every client (even clients with POP3 setup) to have copy of the
> sent mail. Until now it was working with separate instance of
> Postfix just for this (and separate instance for SPAM filtering
> etc). I find easier to care for one postfix config (instance) than
> a number of them. So I am in a process of consolidating them.

Beware, as you add -o options in master.cf you have, it becomes
harder to change one thing without breaking another thing.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

karavelov
In reply to this post by karavelov

 

----- Цитат от Wietse Venema ([hidden email]), на 16.06.2011 в 02:44 -----

Wietse:
Apparently you can't use receive_override_options=no_address_mappings
because you need virtual alias or canonical mapping on both sides
of the filter?

[hidden email]:
We do not use it before/after filter. The setup is that BCC mapping
is only needed for sending outgoing mail (we send a copy to the
"Sent" folder) so we enable BCC mapping by default (in main.cf)
and disable it on default smtpd that handles incoming mail (we
obviously need the other mappings there but do not need bcc mappings).

I see. What about using this instead?

/etc/postfix/master.cf
smtp inet n - n - - smtpd
-o sender_bcc_maps=
submission inet n - n - - smtpd

/etc/postfix/main.cf:
sender_bcc_maps = maptype:mapname

Or this?

/etc/postfix/master.cf
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o sender_bcc_maps=maptype:mapname

I am reluctant to add no_bcc_mappings, because that would make BCC
mappings be a special case, and special cases make systems more
difficult to understand.

To avoid the special case, I'd have to also implement support for
no_canonical_mappings, no_virtual_alias_mappings, and for
no_address_masquerade. Otherwise, people would be wondering why
they can turn off one feature and not the other.

The setup is somewhat unusual but it was decision made a long time
ago. I would not argue if this is a good idea but the reason is
every client (even clients with POP3 setup) to have copy of the
sent mail. Until now it was working with separate instance of
Postfix just for this (and separate instance for SPAM filtering
etc). I find easier to care for one postfix config (instance) than
a number of them. So I am in a process of consolidating them.

Beware, as you add -o options in master.cf you have, it becomes
harder to change one thing without breaking another thing.

Wietse

I thought that sender_bcc_maps/recipient_bcc_maps are options to the cleanup process, not smtpd. Will smtpd pass this informations somehow to the cleanup process? If it could be done in this way, I could use it and the patch is not needed. 

The special case was already there (CLEANUP_FLAG_BCC_OK). The patch just adds command line option for cleaning the flag separate from no_address_mappings. I think it is a special case in order to prevent sending multiple BCCs for one mail.

Luben

Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Victor Duchovni
In reply to this post by Wietse Venema
On Wed, Jun 15, 2011 at 07:44:53PM -0400, Wietse Venema wrote:

> > We do not use it before/after filter. The setup is that BCC mapping
> > is only needed for sending outgoing mail (we send a copy to the
> > "Sent" folder) so we enable BCC mapping by default (in main.cf)
> > and disable it on default smtpd that handles incoming mail (we
> > obviously need the other mappings there but do not need bcc mappings).
>
> I see. What about using this instead?
>
>     /etc/postfix/master.cf
>         smtp            inet  n       -       n       -       -       smtpd
>              -o sender_bcc_maps=
>         submission      inet  n       -       n       -       -       smtpd
>
>     /etc/postfix/main.cf:
>         sender_bcc_maps = maptype:mapname
>
> Or this?
>
>     /etc/postfix/master.cf
>         smtp            inet  n       -       n       -       -       smtpd
>         submission      inet  n       -       n       -       -       smtpd
>             -o sender_bcc_maps=maptype:mapname

As the OP observed, correctly, this won't work since bcc is done in cleanup,
so a cleanup_service_name= override is required instead. However, a better
solution is for the OP to not pursue the pointless "consolidation"
(making a more complex mess out of a few simple parts). Just learn to
manage multiple instances better.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

karavelov
In reply to this post by karavelov

 

----- Цитат от Victor Duchovni ([hidden email]), на 16.06.2011 в 05:27 -----


Or this?

/etc/postfix/master.cf
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o sender_bcc_maps=maptype:mapname

As the OP observed, correctly, this won't work since bcc is done in cleanup,
so a cleanup_service_name= override is required instead. However, a better
solution is for the OP to not pursue the pointless "consolidation"
(making a more complex mess out of a few simple parts). Just learn to
manage multiple instances better.

--
Viktor.

 

Thanks for the suggestion, cleanup_service_name override is better and more clean solution compared to patched version. It simplifies the configuration. 

Thanks again

Luben

Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Wietse Venema
In reply to this post by karavelov
[hidden email]:
>I thought that sender_bcc_maps/recipient_bcc_maps are options to
>the cleanup process, not smtpd. Will smtpd pass this informations
>somehow to the cleanup process? If it could be done in this way,
>I could use it and the patch is not needed.

Correct. this happens in cleanup not smtpd. The implementation of
BCC features has moved over time from pickup/smtpd to cleanup.

>The special case was already there (CLEANUP_FLAG_BCC_OK?????)?.

I am referring to a special case in the USER INTERFACE.  If they
can turn off BCC in the USER INTERFACE, then they will wonder why
they can't turn off canonical mapping etc. in the USER INTERFACE.

Special cases in the USER INTERFACE make a system hard to understand.

BTW, on a mailing list, you should place ">" before the text that
you reply to. Please use a mail client that supports proper reply
style.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

Rich Wales
As an example of how sender_bcc_maps might be specified only in a
single specific context, here is what I have been doing for some
time now.

I wanted to generate BCC copies for every message submitted by my
users (family members).  In the "submission" stanza of my master.cf,
I include the following option line:

        -o cleanup_service_name=msa-cleanup

and then I include a corresponding new stanza in master.cf:

msa-cleanup unix n      -       n       -       0       cleanup
        -o sender_bcc_maps=hash:/etc/postfix/sender_bcc

where my "sender_bcc" file contains entries such as the following:

        [hidden email]    [hidden email]

and each recipient address (such as richw-bcc) is aliased to the
regular address (richw) in /etc/aliases.

The result is that BCC copies get created only upon local creation
and submission of a new message, and not for anything received
from the outside by smtpd.

The name "msa-cleanup" (msa = mail submission agent) is arbitrary
and could have been something else.  And I didn't really need to
use a separate set of "...-bcc" user aliases, though this turned
out to be useful for Cyrus Sieve processing of the BCC copies.

There may, I'm sure, be other variations possible here; I'm just
showing this as one way to do it.

Rich Wales
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: receive_override_options=no_bcc_mappings

karavelov
In reply to this post by Wietse Venema
On 16.06.2011 16:13, Wietse Venema wrote:
[hidden email]
I thought that sender_bcc_maps/recipient_bcc_maps are options to
the cleanup process, not smtpd. Will smtpd pass this informations
somehow to the cleanup process? If it could be done in this way,
I could use it and the patch is not needed.
Correct. this happens in cleanup not smtpd. The implementation of
BCC features has moved over time from pickup/smtpd to cleanup.

The special case was already there (CLEANUP_FLAG_BCC_OK?????)?.
I am referring to a special case in the USER INTERFACE.  If they
can turn off BCC in the USER INTERFACE, then they will wonder why
they can't turn off canonical mapping etc. in the USER INTERFACE.

Special cases in the USER INTERFACE make a system hard to understand.

BTW, on a mailing list, you should place ">" before the text that
you reply to. Please use a mail client that supports proper reply
style.

	Wietse
Thanks for all advices. I have moved my configuration to use
cleanup_service_name way suggested by Viktor and Rich Wales - it is
way better to not have the default be the special case (adding bcc).

Now I do think that the feature proposed by me is useless - at the
time of writing/proposing it I did not know that I could specify
different cleanup service per smtpd.

Thanks again
Luben

P.S. Sorry for broken quoting in the text version of my previous
messages.