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
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
