On Sat, Jan 20, 2024 at 05:44:25PM +0100, Simon Hoffmann 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.
>
> This is a Company Mail Server, and in Germany there is a rule to copy all
> mails to a
> special archive. This my use of always_bcc to copy all mails going through
> the server
> to the archive software import mailbox.
> > - 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.
>
> could you please elaborate on that (off-list is okay with me), because I
> don't seem
> to understand your point here.
This copies only the message headers and body, but fails to capture the
message envelope, which contains the true recipient list. With
per-recipient addressing in "recipient_bcc_maps", and provided the
archive system captures the message envelope, you don't lose that (IMHO
essential) information.
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
From:<[email protected]>
To: <[email protected]>
Subject: Let's commit fraud
...
.
With "always_bcc" one might assume that the message went to
"fake-recipient", where in real-life it was sent to "bcc1" and "bcc2".
With per-recipient bcc addresses that are captured by the archive,
this is not the case.
> > 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.
>
> But if I [have] two *sources* specified (either two files, or one sql
> and a file, ...) postfix processes those sources in the order
> specified in main/master.cf, and never looks at the second source if
> the first source results in a match (no matter if that match means the
> user is allowed to send with that address not not).
As expected.
> So in general, if I need postfix to query *both* sources, I need to
> use a unionmap, correct?
Yes, of course.
> yes. each user can also have a few aliases, so I would either provide
> correct regexps (and would escape a dot if any actual address would
> have it)
And use "^" and "$" anchors, which is easy to forget for most (mis)users
of RE patterns.
> or would provide a hash table.
That's generally the mor robust and more scalable approach.
> > This is more simply expressed as:
> >
> > static:internal-software-user
>
> used in a unionmap, right?
Wherever you want an output that does not depend on the lookup key,
possibly as part of a unionmap, sure.
> Sometimes I send notifications to customers directly without using the ticket
> system
> because they are just notifications and a ticket is only needed if the
> customer has
> questions and replies to my notification email. But I could achieve that by
> stating
>
> [email protected] ticket-system, myuser
>
> in the hash map, right?
As documented.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
