Viktor Dukhovni 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.
Further processing is then done on the archive server with keywords, such as
keeping
Quotes for x years, invoices for y years and so on.
>
> - 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.
>
> So a more "sophisticated" approach is:
<snip>
Thanks for the code/example!
> > 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.
But if I 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).
So in general, if I need postfix to query *both* sources, I need to use a
unionmap,
correct?
>
> > 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.
Thanks for the confirmation!
>
> > /user....@domain.com/ user....@domain.com
> > /user....@domain.com/ user....@domain.com
> > /user.th...@domain.com/ user.th...@domain.com
> > /sa...@domain.com/ zammad-user
> > /supp...@domain.com/ zammad-user
>
> Yet another misuse of regular expressions, I hope that in a real
> deployment you'd either write:
>
> /^user\.one@domain\.com$/ user....@domain.com
> /^user\.two@domain\.com$/ user....@domain.com
> /^user\.three@domain\.com$/ user.th...@domain.com
> /^sales@domain\.com$/ zammad-user
> /^support@domain\.com$/ zammad-user
>
> or, better still, for exact matches of literals use a "hash" or "cdb"
> table:
>
> user....@domain.com user....@domain.com
> user....@domain.com user....@domain.com
> user.th...@domain.com user.th...@domain.com
> sa...@domain.com zammad-user
> supp...@domain.com zammad-user
> ...
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) or would provide a
hash
table. The above was just meant as a simplified example to have content in the
file to talk
about, but to not use actual production data. I should have stated that.
>
> > /.*/ internal-software-user
>
> This is more simply expressed as:
>
> static:internal-software-user
used in a unionmap, right?
I think when reading the docs the "A table that always returns its name as the
lookup
result" threw me of because I was still thinking in a "search pattern in first
column, result in second column" way and dismissed this then because it would
only
return one value. But since the whole pcre always only returns one value it's
the
same thing. Thank you for catching that! :)
>
> 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.
I am aware of that, thanks, but this server will only be directly connected to
by
either actual humans and their MUA of choice or by the ticket system and
additional
internal software. There will never be another server connecting to this server
on
ports 465/587 and the logins maps will only be applied to these ports.
>
> > 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.
thinking about it, even the ticket system could be a hash table, I just have to
think
about adding a new entry to that table should there be a new email address we
like
integrate into the ticket system.
>
> > 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:
> us...@example.com user1
> us...@example.com user2
> ...
>
> ticket-sender:
> tick...@example.com ticket-system
> tick...@example.com 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.
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
supp...@example.com ticket-system, myuser
in the hash map, right?
> 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.
Yeah, it would probably best to just use a single hash map, but for that I need
to
clean up the server and all connecting clients a bit to have strict rules and
have
dedicated auth-users for each script and not the mess I have currently. With
that,
the sender login map would even serve as a really good documentation which
internal
system has which task and therefore needs to send as which email address.
I'll add that to my endless todo list :)
>
> --
> Viktor.
Thanks for your input Viktor!
Cheers,
Simon
signature.asc
Description: PGP signature
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
