Always_bcc with aliases

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Always_bcc with aliases

Warren H. Prince
My postfix server receives email for several sub-domains of my-domain.  All email addressed to one of the sub-domains is aliased to [hidden email].  For example:


I use transport to pipe the email to an external application:


I would also like to archive a copy of every email, so I use an always_bcc

always_bcc = [hidden email]


But this doesn’t work “anymore.”  I believe it used to work, but it’s possible I didn’t test properly in the past.  I realize that “BCC recipients are not generated after Postfix forwards mail internally  Is the use of the alias and/or the transport considered an internal forward?

If it is an internal forward, does anyone have any suggestions other than my external application re-sending the email? 
Reply | Threaded
Open this post in threaded view
|

Re: Always_bcc with aliases

Wietse Venema
always_bcc is implemented upon receving email, so that

    always_bcc = [hidden email]

will send a copy to [hidden email], unless you have aliased
that to something else. In that case, your BCC copy will be sent
there.

For example if you have a wild-card alias

        @example.com blah

Then your BCC copy will be sent to blah, unless you also add an 1:1
alias to prevent that:

    # Everything aliased to blah
    @example.com blah
    # Except for [hidden email]
    [hidden email] [hidden email]

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Always_bcc with aliases

Warren H. Prince
Thanks for the response, and sorry for my delayed reaction.  

I understand that always_bcc should send a copy to the address indicated or the alias of the address indicated.  My situation is slightly different.  It’s the initial recipient (the To:) that is aliased AND uses a transport to execute an external app.  The app is expecting the alias, and that all works fine.  The app is happy.  My problem is that I also want to bcc that incoming email to an aliased address.  That doesn’t seem to happen.  

By-the-by, my app also generates a new email to be sent to an employee (without any aliases) and that always_bcc works fine.

Let me try another example.  Email is addressed to [hidden email].  All email addressed to [hidden email] is aliased to [hidden email].  There is also a transport set up to send email addressed to [hidden email] via pipe in master.cf to my application.  I would also like a copy of the email to [hidden email] to go to an archive mailbox.  Always_bcc is not functioning on the incoming email to [hidden email].

Is there any way to log always_bcc actions?  I know adding it to the header defeats the purpose of the bcc.  
Does that also apply to the server’s log?


On Mar 15, 2020, at 3:10 PM, Wietse Venema <[hidden email]> wrote:

always_bcc is implemented upon receving email, so that

   always_bcc = [hidden email]

will send a copy to [hidden email], unless you have aliased
that to something else. In that case, your BCC copy will be sent
there.

For example if you have a wild-card alias

@example.com blah

Then your BCC copy will be sent to blah, unless you also add an 1:1
alias to prevent that:

   # Everything aliased to blah
   @example.com blah
   # Except for [hidden email]
   [hidden email] [hidden email]

Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Always_bcc with aliases

Wietse Venema
Prince Law Offices:
> Thanks for the response, and sorry for my delayed reaction.  
>
> I understand that always_bcc should send a copy to the address
> indicated or the alias of the address indicated.  My situation is
> slightly different.  It?s the initial recipient (the To:) that is
> aliased AND uses a transport to execute an external app.  The app
> is expecting the alias, and that all works fine.  The app is happy.
> My problem is that I also want to bcc that incoming email to an
> aliased address.  That doesn?t seem to happen.


The code suggests otherwise:

cleanup_addr_bcc() calls cleanup_out_recipient() which calls
cleanup_map1n() which does the virtual alias expansion.

However the aliasing does not happen when you disabled address
mapping, as is done before or after a content with
"receive_override_options = no_address_mappings".

        Wietse