Hello,
I'm having trouble with configuration that should be pretty common, yet
I'm unable to make it straightforward.
Consider a company having a generic off...@example.net e-mail being
serviced by several personal accounts, a...@example.net and supervised
by m...@example.net (let it be some management, whatever).
Supervisors do other things besides looking out at office@ex..,
therefore we want to use address extension (passed to LMTP).
Let's use recipient_delimiter = +.
Entire office@ex.. should be backed up permanently: bac...@example.net.
Employees A..F shouldn't have access to data prior their assignment and
past their reassignment, therefore no shared mailboxes and such.
This is no problem as we want our replies to come from personal
addresses for the customer to know who is he talking with.
All the users should have their own flags, IMAP folders and so on, and
see what was send by other employees (this fully covers shared
mailboxes). M..P can also receive mail directly to their +office
subfolder, which is a subject of being backed up ONLY, not shared.
sender_bcc_maps pointed file contents:
A@ex.. office@ex..
B@ex.. office@ex..
[..CDE..]
F@ex.. office@ex..
M+office@ex.. backup@ex..
P+office@ex.. backup@ex..
- this shares outgoing with associates and backup@s.
virtual_alias_maps contents:
office@ex.. A@ex.. B@ex.. C@ex.. D@ex.. E@ex.. F@ex..
M+office@ex.. N+office@ex.. O+office@ex.. P+office@ex..
backup@ex..
So far so good. But - since A..F outgoing mail is originating from
personal addresses (this is actually another security precaution -
sending as office@ex.. is restricted for other users, so for this
scenario this is relevant that we cannot translate From envelope to
office@ex.. itself), customers' replies need to be routed back to
office@ex.., therefore remaining part of virtual_alias_maps:
A@ex.. A@ex.. office@ex..
B@ex.. B@ex.. office@ex..
[..CDE..]
F@ex.. F@ex.. office@ex..
M+office@ex.. M+office@ex.. backup@ex..
[..NO..]
P+office@ex.. P+office@ex.. backup@ex..
...and there's the problem - arise of loops like:
A@ex.. A@ex.. office@ex..
office@ex.. A@ex.. [...]
According to man 5 virtual recursion can be terminated by aliasing to
itself, however office@ex.. is not a real account (the backup@ex.. is)
and we'd like to avoid having one (unless necessary).
With above setup expansion seems to take such path:
office -> A..F,M..P+office,backup {11}
A -> A, office -> A..F,M..P+office,backup (again...)
[..BCDE..]
F -> F, office -> A..F,M..P+office,backup
M..P -> M..P, backup
so it's expanding into 11*7+4 = 81 addresses before they're compacted.
Although virtual_alias_expansion_limit = 1000 by default, this is
exploding really fast and for more complicated setups becomes really
cumbersome.
The best I could think of was some symbol to explicitly mark RIGHT-hand
addresses as non-recursive instantaneously, so that
office@ex.. =A =B =C =D =E =F
won't try to resolve A..F any further. I haven't found anything like
this so tried to abuse recipient delimiter, adding second one (/) to
LMTP and realiasing as (@ex.. on the right removed for clearance):
office@ex.. A/ B/ C/ D/ E/ F/
M/office N/office O/office P/office
backup@ex..
which works fine - postfix doesn't know the '/' delimiter, so having no
literal LEFT-hand match doesn't expand anything, but when we receive
mail addressed to offic...@example.net we end up with A/+x...@example.net
and now LMTP complains about two separators being next to each other
(still M/offic...@example.net being valid). As we do use various (many)
extensions in real setups this was not accepted. Of course we could just
move the destination into A..F/office as well, but then their main INBOX
would be empty - acceptable solution, but something feels odd, like
doing some weird workarounds for something obviously missing...
I'm not sure if it's not a XY-kind of problem, so I hope I've described
all the relevant rules we're trying to follow (bearing in mind the real
setup is much more complicated and seems to grow exponentially).
Right now I'm considering patching LMTP to treat multiple consecutive
delimiters as one or adding the 'off...@example.net' accounts only to
terminate alias expansion, but this seems superfluous... After all, even
with terminated:
office@ex.. A@ex.. B@ex.. C@ex.. D@ex.. E@ex.. F@ex..
M+office@ex.. N+office@ex.. O+office@ex.. P+office@ex..
backup@ex.. off...@example.net
there will be:
office -> A..F, M..P, backup, office {12}
A -> A, office
[..BCDE..]
F -> F, office
M..P -> M..P, backup
= 12 + 10 = 22 expansions instead of 11 directly specified.
As we got more of such not terminated non-accounts, creating and
maintaining (i.e. purging) them seems less attractive than patching LMTP
and keep (ab)using our delimiter hack.
Therefore I wonder - am I missing something, or maybe it would be
profitable to introduce one or both of:
1. RIGHT-hand "treat as final" (do not recurse),
2. RIGHT-hand explicit "treat LEFT-hand as terminated" (as an
alternative to implicit aliasing to itself) runes?
E.g. (magic placeholder symbols "=" and "!").
off...@example.net =a...@example.net [..] !
== send directly to a...@example.net (no matter if it's aliased elsewhere),
== treat off...@example.net as recurse-terminated, but without sending
to off...@example.net (as in current implicit syntax).
TIA and best regards
--
Tomasz Pala
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
