As you have responded directly to me and not to the list, I quote your full
email below.
From what you have written I understand that in most (if not all) cases,
each email has to be BCC-ed to "destination set", which consists of
{B,X,Y,Z,S1+office,S2+office}. Only emails to S1 and S2 don't, they are
BCC-ed only to B. Do I understand correctly?
So maybe you should try to use "recipient_bcc_maps" parameter for this,
without the need for too much aliasing?
I think that recipient_bcc_maps for each of O,X,Y,Z can be the above
"destination set", while the recipient_bcc_maps for S1,S2 would be just B.
Probably O should be then aliased to something like /dev/null, as there is
no actual recipient and all recipients are handled by BCC.
If I understand the documentation correctly
( http://www.postfix.org/postconf.5.html#recipient_bcc_maps ),
bcc_recipient_maps is applied only once, and the recipients mentioned there
don't get another copy of the same message ("To avoid mailer loops,
automatic BCC recipients are not generated after Postfix forwards mail
internally, or after Postfix generates mail itself.")
Can it solve your case?
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
----- Forwarded message from Tomasz Pala <tp_ml_...@mediasat.pl> -----
Date: Thu, 5 Dec 2024 18:17:16 +0100
From: Tomasz Pala <tp_ml_...@mediasat.pl>
To: Jaroslaw Rafa <r...@rafa.eu.org>
Subject: Re: [pfx] Re: virtual alias expansion explicit prevention
User-Agent: Mozilla Thunderbird
On 2024-12-05 17:02, Jaroslaw Rafa via Postfix-users wrote:
>
> Maybe it's just me, but I'm actually having trouble to understand WHAT
> exactly are you trying to achieve. Your description looks overcomplicated to
> me.
[Sorry, here's still complicated - there's "simplest example" below, but
I want to keep full context if anything needs clarification].
Sure. All of this boils down to many-to-many mapping, i.e. all accounts
in a "group" having SAME content.
B[backup] == archive-only
O[office] -> B,X,Y,Z
X[empl01] -> B,X,Y,Z
Y[empl02] -> B,X,Y,Z
Z[empl03] -> B,X,Y,Z
Note the missing "O" on the right side!
This is the base. On top of that there are some limiting factors and
additions. E.g. supervisors that receive, but not BCC:
O[office] -> B,X,Y,Z,S1,S2
X[empl01] -> B,X,Y,Z,S1,S2
Y[empl02] -> B,X,Y,Z,S1,S2
Z[empl03] -> B,X,Y,Z,S1,S2
S1[sup01] -> B,S1
S2[sup02] -> B,S2
where Sn are in a form of sn+off...@example.net.
> Scenario 1: When someone sends mail to "off...@example.net", what should
> happen to that mail? Where should it be delivered?
To:
- several personal accounts (X,Y,Z),
- more personal accounts, but with +office expansion (Sn+office),
- backup account (B).
Let's call this DS (destination SET). In terms of symbols above:
{B,X,Y,Z,S1+office,S2+office}
> Scenario 2: If an employee responds to a mail sent to "off...@example.net",
> what should happen to that mail?
It should be BCC-ed into what's expanded from off...@example.net, i.e.
"destination SET".
> Scenario 3: If one of the employees emails some other employee - *not*
> responding to a mail sent to "off...@example.net", what should happen to
> that mail?
The same - BCC into "destination SET" (of off...@example.net).
> Scenario 4: If one of the employees emails any other address (outside of the
> company) - *not* responding to a mail sent to "off...@example.net", what
> should happen to that mail?
The same - BCC into "destination SET" (of off...@example.net).
> Maybe there are some other scenarios that I don't see right now, and that
> should be considered (for example what should happen if one of the employees
> mails "off...@example.net" ?).
No, that's not the issue. It doesn't matter what's the origin of the
mail, unless it's the supervisor.
The root of problem is handling INBOUND, i.e. external customer
responding to personal mail, which must be treated THE SAME as if it
were send to off...@example.net.
[simplest example]
Just consider two-employee example:
employee1 employee1 employee2
employee2 employee1 employee2
office employee1 employee2
- THIS is what we want to have. But as the lists of employees are large,
we're trying to "pack" them into single "alias" for the sake of
compliance and auditing/review mail flow. This could be:
{some_alias} employee1 employee2
employee1 employee1 {some_alias}
employee2 employee2 {some_alias}
office {some_alias}
- since postfix doesn't have an entity like "internal" (non-mailbox)
alias, the {some_alias} is effectively the same as "office", therefore:
employee1 employee1 office
employee2 employee2 office
office employee1 employee2
And my "destination SET" loops back to itself as there is no "office" in
last line. This would work:
employee1 employee1 employee2 office
employee1 employee1 employee2 office
office employee1 employee2 office
but we want to avoid maintenance burden of "office" (actually: many of
these) being real destinations.
The mail should land in employee1 and employee2 ONLY.
And I don't know how to make office not being saved.
This should be an alias only, not physical destination.
What I didn't mentioned previously, as that's going to be even more
complicated - I am aware that I can implement my "{internal alias}" idea
in the RDBMS backend and then simply generate these "unrolled"
destination account lists, so this is solvable (again).
Still, during the analysis of alias expansion itself and various
experiments I've made a conclusion, that implicit "recursion
termination" by aliasing an account to itself is deficiency in general,
and a one that seems to be a "low hanging fruit"; by using explicit
"termination" flag one could easily optimize postfix performance by
reducing recursion depth, especially in RDBMS-backed environments.
So my question is not about a problem I cannot solve (rather: which way
of solving would be better), but about either something I'm totally not
aware of or maybe about possible optimization.
Best regards
--
Tomasz Pala
----- End forwarded message -----
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
