On Sat, Jan 20, 2024 at 03:42:52PM +0100, Simon Hoffmann via Postfix-users
wrote:
> I am currently planning to switch from OpenSMTPd to postfix for two reasons
>
> - smtpd_sender_login_maps functionality not really implemented in OpenSMTPd
> - always_bcc not possible on OpenSMTPd
FWIW, I'd like to recommend "recipient_bcc_maps" over always_bcc.
- You will perhaps before long want to make exceptions.
- You may want to "preserve the envelope", by generating a
recipient-specific bcc address. Just "always_bcc" fails
to record "bcc" recipients, and may record header recipients
who weren't actually (envelope) recipients of the message.
So a more "sophisticated" approach is:
main.cf:
pcre = pcre:${config_directory}/
recipient_bcc_maps = ${pcre}bcc.pcre
bcc.pcre:
if !/\.bcc\.invalid$/
# More specific patterns/exceptions as needed
/(.*)/ ${1}.bcc.invalid
endif
and then deliver all addresses ending in ".bcc.invalid" to the
archive
main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport
# No need to "split the envelope" when archiving
archive_recipient_limit = 1000
# Every message goes to the archive, give it more
# concurrency. Ideally, low latency should help avoid
# congestion: throughput = concurrency/latency.
archive_concurrency_limit = 50
transport:
.bcc.invalid archive:[archive.example]
master.cf:
archive unix ... smtp
# Safety net, nothing should be rejected here...
-o soft_bounce=yes
> While reading up on the postfix manual for smtpd_sender_login_maps I've read
> that
> postfix stops at the first match, so if you specify two files you should use a
> unionmap or those files may not have any pattern in common.
Postfix tables present a key/value abstraction. A single key in a
single result out. For file-based hash tables, there is no natural key
"order", and any given key can match only once.
First match logic is however appropriate for PCRE and CIDR tables, used
e.g. with access(5) where a "DUNNO" result allows for exceptions to a
subsequent general rule.
Bottom line, yes, for pattern-based tables, where multiple keys can
match a result, the first match is natural and least surprising.
> I have users on the server that should only be allowed to send with
> their own address, but then there is a ticket system that should
> impersonate a few addresses (like sales@, support@, ...). Furthermore
> I have a user to send email from internal software that should be able
> to impersonate all user accounts.
>
> So if I understand correctly, a simple pcre with the following content
> would not be working for me?
Correct.
> /[email protected]/ [email protected]
> /[email protected]/ [email protected]
> /[email protected]/ [email protected]
> /[email protected]/ zammad-user
> /[email protected]/ zammad-user
Yet another misuse of regular expressions, I hope that in a real
deployment you'd either write:
/^user\.one@domain\.com$/ [email protected]
/^user\.two@domain\.com$/ [email protected]
/^user\.three@domain\.com$/ [email protected]
/^sales@domain\.com$/ zammad-user
/^support@domain\.com$/ zammad-user
or, better still, for exact matches of literals use a "hash" or "cdb"
table:
[email protected] [email protected]
[email protected] [email protected]
[email protected] [email protected]
[email protected] zammad-user
[email protected] zammad-user
...
> /.*/ internal-software-user
This is more simply expressed as:
static:internal-software-user
I should also be mention that naturally sender_login_mismatch
presumes a login, so only works at the first hop MSA to which the user's
MUA authenticates. It won't work at a smarthost relay.
> Another alternative I thought of would be to create three separate
> pcre file and use a unionmap.
Replacing "pcre" with better/safer equivalents as much as possible, yes.
$ postmap -q foo 'unionmap:{inline:{ {foo = bar} }, inline:{ {foo = baz} },
static:that}'
bar,baz,that
> In the first file I would list all named/personal users with their email
> addresses and their login names,
Using instead simple "hash" or "cdb" tables and "static" as appropriate:
main.cf:
sender_login_maps =
unionmap: {
${indexed}sender-login,
${indexed}ticket-sender,
static:internal-software-user
}
sender-login:
[email protected] user1
[email protected] user2
...
ticket-sender:
[email protected] ticket-system
[email protected] ticket-system
...
without any PCRE tables at all. Note that if the ticket system users
don't have a separate individual login, they could be folded into the
first table. And that a "Makefile", could generate a combined source
file from the list of user to login pairs to make a single source file
that avoids the need for a unionmap. Just append
,internal-software-user
to each RHS value. You can create fancy run-time logic with pipemap and
unionmap, but best to keep it simple.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
