[pfx] Re: Do I have to reload Postfix after the X.509 certificate (and key) file has been renewed?
> Note that with `certbot`, the `fullchain.pem` file [...] > contains only the certificate chain, without the private key [...]. > > So you don't get atomicity from `certbot`. I know. I just opened a feature request: https://github.com/certbot/certbot/issues/9915 Am Samstag, 23. März 2024, 16:25:47 CET schrieb Viktor Dukhovni via Postfix-users: > On Sat, Mar 23, 2024 at 01:57:39PM +0100, Matthias Nagel via Postfix-users > wrote: > > > Also note, that the file which is configured in > > `smtpd_tls_chain_files` is only a symbolic link, e.g. > > > > # ls -lha /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem > > lrwxrwxrwx 1 root root 51 11. Mar 21:44 > > /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem -> > > ../../archive/my-host.my-domain.tld:smtps/fullchain3.pem > > Note that with `certbot`, the `fullchain.pem` file (its symlink target) > contains only the certificate chain, without the private key, which is > still in a separate file (the symlink target of): `privkey.pem`. > > So you don't get atomicity from `certbot`. I don't consume `certbot` > files directly, rather I use: > > https://github.com/tlsaware/danebot > > Which works very well in steady-state. What's missing are features like > built-in support for changing the list of domains to be renewed, which > sadly requires low-level fiddling with "cerbot certonly --csr ...". > > For example, I had recently needed to use: > > # Create a private key and CSR with the desired names > ... > > # Obtain a new certificate > certbot certonly --webroot --cert-name $(uname -n) --csr csr.pem \ > --cert-path $PWD/staging/$(uname -n)/newcert.pem \ > --fullchain-path $PWD/staging/$(uname -n)/newfull.pem \ > --chain-path $PWD/staging/$(uname -n)/newchain.pem > > # Then integrate these files into the archive directory, making > # new symlinks, ... > > This would ideally be automated, but requires tricky logic if it is to > support more than just --webroot, and even that requires a bit of extra > logic to specify the webroots correctly for existing and any new > domains. > > Perhaps I should be looking to switch to one of the other ACME clients. > > -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart, Deutschland Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.na...@mhnnet.de, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?
I am running Postfix mail-mta/postfix-3.8.5 with dev-libs/openssl-3.0.13. If I correctly understood my Postifx server should not use a FF group with 1024 bits, but at least 2024 bits. (References to the docs are given below.) So the question still stand, how do I ensure that Postfix uses at least 2048bit DH, if TLS 1.2 and FFDH have been negotiated? > You are assessing opertunistic TLS? Ignore it. Unfortunately not. Yes, we are speaking about oppertunistic TLS as I am looking at my mail server in the role of an SMTP server for incoming mails from the public Internet. I must not make TLS encryption mandatory, as there are still a lot of (legacy) systems out there which do not support TLS (unfortunately). For the same reason, I don‘t want to disable FFDH completely as there are even more legacy servers on the public Internet which still do not support EC. At the same time, I have to meet certain legal regulations which mandate a minimum crypthographic strength. So while it is seemingly fine to not use TLS at all on the one hand, TLS must meet certain minimal requirements if it is used on the other hand. I mean I also disable SSL 3.0, TLS 1.0 and TLS 1.1 and only allow TLS 1.2 or 1.3 besides plain transport. From a technical perspective one could also argue that leaving SSL 3.0 and TLS <1.2 enabled is still better than plain transport. I wonder whether setting `smtpd_tls_dh1024_param_file` to a custom 2048-bit DH group would help? But from my understanding of the docs that should not be necessary as Postfix 3.8.5 uses a built-in 2048bit group if left empty. PS: As of January 2024, the German BSI has tighten its recommendation for asymmetric algorithms over finite fields to at least 3000 bits (i.e. RSA encryption, RSA signatures and FFDH). See „FFDHE Server support“ in https://www.postfix.org/FORWARD_SECRECY_README.html#quick-start > In Postfix < 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or below > works "out of the box" [...] > > The built-in default Postfix FFDHE group is a 2048-bit group as of > Postfix 3.1. You can optionally generate non-default Postfix SMTP server > FFDHE parameters [...], but this is not [...] recommended. Just leave > "smtpd_tls_dh1024_param_file" at its default empty value. > > The set of FFDHE groups enabled for use with TLS 1.3 becomes > configurable with Postfix ≥ 3.8 and OpenSSL ≥ 3.0. The default setting > of "tls_ffdhe_auto_groups" enables the RFC7919 2048 and 3072-bit groups. In https://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file > File with DH parameters that the Postfix SMTP server should use with > non-export EDH ciphers. > > With Postfix ≥ 3.7, built with OpenSSL version is 3.0.0 or later, if the > parameter value is either empty or "auto", then the DH parameter > selection is delegated to the OpenSSL library [...] Custom local > parameters are no longer recommended when using Postfix ≥ 3.7 built > against OpenSSL 3.0.0. > > [...] As of Postfix 3.1, the compiled-in default prime is 2048-bits, and > it is not strictly necessary, though perhaps somewhat beneficial to > generate custom DH parameters. In https://www.postfix.org/postconf.5.html#tls_ffdhe_auto_groups > The default list of FFDHE groups that Postfix enables in OpenSSL 3.0 > and up includes just the 2048 and 3072-bit groups. [...] > > Setting this parameter empty disables FFDHE support in TLS 1.3. Whether > FFDHE key agreement is enabled in TLS 1.2 and earlier depends on whether > any of the "kDHE" ciphers are included in the cipherlist. > > This feature is available in Postfix 3.8 and later, when it is compiled > and linked with OpenSSL 3.0 or later. Am Samstag, 23. März 2024, 13:02:05 CET schrieb Bastian Blank via Postfix-users: > On Sat, Mar 23, 2024 at 12:36:23PM +0100, Matthias Nagel via Postfix-users > wrote: > > I am currently assessing the TLS security of a Postfix mail server and > > among other things sslscan reported that the server allows a (non-EC) DH > > exchange with only 1024 bits. While one solution would be to only allow > > ECDH(E) and disable DH(E) entirely, I would rather like to keep support for > > DH(E) for compatibility reasons but only enforce a lower limit on the size > > of the finite group (maybe 2048 bit, or even 3072 bits preferably). How do > > I do that with Postfix? I cannot find any smptd_tls_... setting which seems > > related to that aspect. > > You are assessing mandatory TLS? Then disable non-ECDHE. > > You are assessing opertunistic TLS? Ignore it. > > Bastian > > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Do I have to reload Postfix after the X.509 certificate (and key) file has been renewed?
Hello everybody, I use `smtpd_tls_chain_files` to set the X.509 certificate (and key) for Postfix. Do I have to reload Postfix, e.g. via `systemctrl reload postfix.service` after the certificate (and key) file has been renewed? The following sentence in https://www.postfix.org/postconf.5.html#smtpd_tls_chain_files suggests that this is not necessary: > Storing the private key in the same file as the corresponding certificate > is more reliable. > With the key and certificate in separate files, there is a chance that > during key rollover a Postfix process might load a private key and > certificate from separate files that don't match. This sound to me as Postfix would pick up the new certificate at some point eventually even without reloading. Maybe not immediately, but that would not be necessary as certificate are renewed weeks before the previous certificate expires. Also note, that the file which is configured in `smtpd_tls_chain_files` is only a symbolic link, e.g. # ls -lha /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem lrwxrwxrwx 1 root root 51 11. Mar 21:44 /etc/letsencrypt/live/my-host.my-domain.tld:smtps/fullchain.pem -> ../../archive/my-host.my-domain.tld:smtps/fullchain3.pem I am just point that out in case the answer depends on that. Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Why has smtpd_tls_cipherlist been deprecated?
Hello everybody, what is the rationale behind the deprecation of the setting `smtpd_tls_cipherlist`? Are there any plans to remove it entirely in some future versions? I am looking for an option to explicitly set the list of allowed cipher suites. The deprecated setting `smtpd_tls_cipherlist` allowed that. The new setting `smtpd_tls_mandatory_ciphers` only supports to enable a selection of cipher suites by defining a lower limit on the cryptographic strength (i.e. „low“, „medium“, „high“, ...) and it seems I can additionally use `smtpd_tls_exclude_ciphers` to remove certain unwanted cipher suites subsequently. For me, that feels a little bit cumbersome. Why not provide both ways? Or did I miss something? Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to set the minimum number of bits for (non-EC) DH key exchange?
Hi everyone, I am currently assessing the TLS security of a Postfix mail server and among other things sslscan reported that the server allows a (non-EC) DH exchange with only 1024 bits. While one solution would be to only allow ECDH(E) and disable DH(E) entirely, I would rather like to keep support for DH(E) for compatibility reasons but only enforce a lower limit on the size of the finite group (maybe 2048 bit, or even 3072 bits preferably). How do I do that with Postfix? I cannot find any smptd_tls_... setting which seems related to that aspect. Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to forward submitted mails under the identity of an email alias to all other members of that alias?
> > How do I forward submitted mails under the identity of an email alias
> > to all other members of that alias? Is that even possible with Postfix
> > only?
>
> Yes, with sender_bcc_maps, and with the proviso that the BCC will be to
> all the members of that "alias", rather than just "the other members".
Not optimal, because it might confuse some users to receive their own mail in
return, but OK.
> Bcc the alias to itself. While you can't specify multiple addresses
> *directly*, the specified address *is* subject to alias expansion.
Good to know.
I thought that I read somwhere in the Postfix docs that the specified addess
*is not* subject to alias expansion in order to avoid circular redirections.
Maybe I am remembering incorrectly or the docs are outdated.
Do you know why it is not possible to specify multiple addresses and how
difficult it would be to fix that in Postfix?
If it was possible to specify multiple addresses, I could write an LDAP filter
which would expand the alias to all addresses excluding the SASL auth name and
that would solve the problem.
> sender_bcc_maps = inline:{
> { doe@bcc.example = doe@bcc.example }
> }
>
> Replace the inline tables with equivalent tables of your choice,
> holding all the desired aliases and bcc mappings.
Yes, now that I have learned that addresses of sender_bcc_maps are subject to
alias expansion I will do that.
Thanks a lot.
Am Sonntag, 11. Februar 2024, 16:33:33 CET schrieb Viktor Dukhovni via
Postfix-users:
> On Sun, Feb 11, 2024 at 10:59:37AM +0100, Matthias Nagel via Postfix-users
> wrote:
>
> > How do I forward submitted mails under the identity of an email alias
> > to all other members of that alias? Is that even possible with Postfix
> > only?
>
> Yes, with sender_bcc_maps, and with the proviso that the BCC will be to
> all the members of that "alias", rather than just "the other members".
>
> > I found the configuration parameter sender_bcc_maps. At first glance,
> > that looked promising, however it neither supports mail aliases nor
> > more than one address.
>
> Bcc the alias to itself. While you can't specify multiple addresses
> *directly*, the specified address *is* subject to alias expansion.
>
> > Just for the sake of clarity, I give a simplified example with only
> > two mail accounts to illustrate what I want to achieve. Lets assume
> > there are the virtual mail accounts `jane@my-domain.tld` and
> > `john@my-domain.tld` as well as the alias `d...@my-domain.tld`
> > which resolves to both mail accounts:
>
> main.cf:
> virtual_alias_maps = inline:{
> { doe@bcc.example = john.doe@bcc.example, jane.doe@bcc.example }
> }
>
> sender_bcc_maps = inline:{
> { doe@bcc.example = doe@bcc.example }
> }
>
> Replace the inline tables with equivalent tables of your choice,
> holding all the desired aliases and bcc mappings.
>
>
--
Matthias Nagel
Dachtlerstr. 2, 40499 Stuttgart, Deutschland
Festnetz: +49-711-25295180, Mobil: +49-151-15998774
E-Mail: matthias.na...@mhnnet.de, Threema: 86VM8KN7
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to forward submitted mails under the identity of an email alias to all other members of that alias?
Dear all, how do I forward submitted mails under the identity of an email alias to all other members of that alias? Is that even possible with Postfix only? I am running Postfix 3.8.4 with OpenLDAP as the backend for account and alias management. Postfix is setup for virtual mail hosting and transports mails for addresses listed in virtual_mailbox_maps to Dovecot via LMTP as their final destination. Moreover, the alias feature implements a simple mailing list feature via virtual_alias_maps. Mail clients which submit new mails via SMTP are restricted by smtpd_sender_login_maps to either use their „personal“ mail address or one of the aliases their are member of as the sending mail address. I am trying to implement the following feature: When a mail client submits a new mail under the identity of an email alias as the sender, Postfix shall deliver this mail to all other members of that email alias (of course in addition to the actual recipient). How can I implement such a behavior? Is that even possible with Postfix? I found the configuration parameter sender_bcc_maps. At first glance, that looked promising, however it neither supports mail aliases nor more than one address. Just for the sake of clarity, I give a simplified example with only two mail accounts to illustrate what I want to achieve. Lets assume there are the virtual mail accounts `jane@my-domain.tld` and `john@my-domain.tld` as well as the alias `d...@my-domain.tld` which resolves to both mail accounts: 1. Someone, e.g. fri...@foreign-domain.tld sends a mail to d...@my-domain.tld 2. Postfix receives the mail, resolves the alias and transports two copies of the mail to Dovecot (via LMTP) for recipient jane@my-domain.tld and john@my-domain.tld 3. Lets say, Jane decides to reply. Jane's mail client submits a mail to Postfix for fri...@foreign-domain.tld as the recipient and with d...@my-domain.tld as the sender identity. 4. Postfix relays the mail to fri...@foreign-domain.tld but also transports a copy of the mail for john@my-domain.tld to Dovecot 5. John is able to notice that Jane has already replied to fri...@foreign-domain.tld Any suggestions, tips or help are much appreciated. Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to temporarily pause virtual mail delivery?
Am Mittwoch, 22. November 2023, 19:01:23 CET schrieb postfix--- via Postfix-users: > > I am looking for an option to temporarily pause delivery via LMTP and defer > > mail while the Dovecot mailboxes are being backed-up in order to get an > > consistent state. > > Just take dovecot LMTP offline. Isn't the default behavior of postfix to > queue undeliverable mail and once its able to deliver, it will? No need to > bounce public mail with a 4xx error. > I don‘t want to bounce the mail publicly. I want Postfix to take it out of the active queue, put it into the deferred queue (on the *same* mail server) and Postfix shall attempt to re-deliver it later on. Taking Dovecot LMTP offline doesn‘t seem to be that easy either. So I was looking for an alternative on the Postfix side. -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to temporarily pause virtual mail delivery?
I am using Posfix with virtual mailboxes. Dovecot hosts these mailboxes and Posfix delivers mails via the LMTP delivery agent to Dovecot. I am looking for an option to temporarily pause delivery via LMTP and defer mail while the Dovecot mailboxes are being backed-up in order to get an consistent state. After the backup has been completed, I want to re-enable mail delivery. Delivery via the LMTP delivery agent shall be paused independently from how the mail got into Postfix. This means, even if a mail has been picked up locally (from sendmail) and the mail's destination is a virtual mailbox, the mail shall be deferred. At the same time, mails which are supposed to be sent off the machine shall still be delivered via the SMTP delivery agent normally. What is the best way to configure that behavior? In the following, I'll present my approach as far as I got. According to my understanding of the Postfix architecture the correct place to do that is after the incoming queue. (Most solutions from the Internet tinker with the configuration of the SMTPD, but this does not suit my objectives.) I assume that the better solution is to use the `transport_maps` and to override the LMTP delivery agent with the ERROR delivery agent for the virtual mailbox delivery. My current configuration is ``` virtual_mailbox_domains = my-domain.de virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap/virtual-mailboxes.cf virtual_alias_maps = proxy:ldap:/etc/postfix/ldap/virtual-aliases.cf ``` I am planning to use ``` transport_maps = hash:/etc/postfix/transport ``` with `/etc/postfix/transport` something like ``` my-domain error:4.2.1 Mailbox read-only, not accepting messages ``` At the beginning of the backup process, the backup program would write the line into `/etc/postfix/transport` and remove that line after the backup has been completed. Is that approach possible? Better ideas? Specific questions: - I would like to encode the status code 4.2.1 acc. to RFC 3463 Sec. 3.3 into the error response. Is the shown syntax of `/etc/postfix/transport` correct? - Which Postfix daemon uses `transport_maps` and how fast does the daemon pick-up changes to the map? Do I need a `postfix reload` or is `postmap /etc/postfix/transport` enough? - Does Postfix keep the mails in it own deferred queue and delivers the deferred mail later or does Postfix bounce the mail back to the original sender? Bests and thank you for any help in advance, Matthias -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Why does Postfix evaluate relay restrictions despite an early permit in recipient restriction?
Am Samstag, 11. November 2023, 18:51:04 CET schrieb Bill Cole via Postfix-users: > Nope. Review the restriction list docs. PERMIT only short-circuits the > current restriction list. Later restriction in the same list are > skipped, but later lists are still run. DENY or DEFER acts immediately. Thanks for clarification. What happens if Postfix find a PERMIT in an earlier restriction list (which shortcuts that list), but then finds a DENY in a later restriction list? What takes precedence? The earlier PERMIT or the later DENY? -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Why does Postfix evaluate relay restrictions despite an early permit in recipient restriction?
Hello all, I am running Postfix 3.8.1. Postfix serves port 25 for incoming mail from other MTAs and port 587 for authenticated MUAs. Postfix is supposed to check SPF for mails from other MTAs on port 25, but not for mails from authenticated MUAs on port 587. To this end, there is a SPF check inside „recipient_restrictions“, but authenticated clients are already permitted by an early „permit_sasl_authenticated“ inside „relay_restrictions“. According to my understanding, Postfix should stop evaluation of the access rules as soon as a final decision has been made. I thought, Postfix evaluates 1. client restrictions 2. helo restrictions 3. sender restrictions 4. recipient restrictions 5. relay restrictions 6. data restrictions 7. end-of-data restrictions in that order until either a final PERMIT, DENY or DEFER is found. But even though step 4 permits authenticated clients, step 5 performs the SPF check even for authenticated clients. Maybe someone could shed some light on what is happening here and where I am erring. My `master.cnf` (essential entries only) ``` # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (no)(never) (100) # == smtp inet n - y - - smtpd submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o cleanup_service_name=header_cleanup -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_relay_restrictions=$mua_relay_restrictions header_cleanup unix n - - - 0 cleanup -o header_checks=regexp:/etc/postfix/submission_header_cleanup.cf ``` The idea of the configuration above is that smtpd on port 587 (submission) should use some special configuration for the access rules. My `main.cf` (again, essential entries only) ``` smtpd_delay_reject = yes smtpd_client_restrictions = reject_unauth_pipelining, reject_unknown_client_hostname mua_client_restrictions = reject_unauth_pipelining smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname mua_helo_restrictions = reject_invalid_helo_hostname strict_rfc821_envelopes = yes smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain mua_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain reject_plaintext_session, reject_sender_login_mismatch smtpd_relay_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination mua_relay_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_sasl_authenticated, reject smtpd_recipient_restrictions = check_policy_service unix:private/policyd-spf, permit policyd-spf_time_limit = 3600 ``` The idea is that `mua_relay_restrictions` unconditionally permits authenticated clients and rejects everything else. This means for authenticated clients access control should stop there. This is also the reason why `smtpd_recipient_restrictions` exists only for clients on port 25 and there is no corresponding `mua_recipient_restriction`, because Postfix should never reach that point. But my logs show that Postfix also evaluates `smtpd_recipient_restrictions` for authenticated clients which have already been accepted by a previous `mua_relay_restrictions` and the SPF check fails. I can work around the issue, if I add an extra ``` mua_recipient_restrictions = permit_sasl_authenticated, reject ``` to `main.cf` and add `-o smtpd_recipient_restrictions=$mua_recipient_restrictions` to `master.cf`. Why is this necessary to prevent the spurious SPF check for authenticated clients? Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: When using LDAP over socket, „smtpd_sender_login_maps“ requires an LDAP socket relative to chroot in contrast to other map configurations (potential bug?)
Dear Viktor, dear Wietse, Viktor, you recommend to use proxymap in combination with LDAP, especially if all LDAP lookups use the same connection. Indeed, this is the case for my setup. The LDAP server, the bind DN and bind passwd are the same. Only the search base, the query filter and the result is different depending on the specific lookup. I tried to read the man page for proxymap (8). Do I understand correctly, that I only have to add „proxy:“ in front of all my „ldap:“ lookups and that‘s it? No further configuration is required? Does proxymap somehow cleverly detect if two LDAP queries use the the same connection options and then re-uses the same connection? I excpected that I had to configure each connection which I would like to run through the proxy with proxymap, but this doesn‘t seem to be the case. Wietse, you say that Postfix cannot control when the LDAP client library opens a connection to the LDAP server, but at the same time you say that difference in LDAP client behaviour is caused by differences in Postfix main.cf/master.cf settings and differences in Postfix LDAP configuraton files. I can assure you that the only difference is the config file to which „ldap:...“ points, i.e. my config file contains virtual_mailbox_maps = ldap:/etc/postfix/ldap/virtual-mailboxes.cf virtual_alias_maps = ldap:/etc/postfix/ldap/virtual-aliases.cf smtpd_sender_login_maps = ldap:/etc/postfix/ldap/sender-login.cf There is not very much else I could do differently in the config file. The three LDAP configuration files are identical in terms of host and binding settings. They only differ in query filter and result attribute (obviously). Nonetheless, Postfix behaves differently with repect to whether it opens the LDAP connection before or after chrooting. While it is technically correct that the LDAP client library opens the connections, it is still Postfix which calls the the client library and obviously it does so for „virtual_mailbox_maps“ and „virtual_alias_maps“ before it chroots, but for „smtpd_sender_login_maps“ after it chroots. This is something which Postfix can control. If this difference in behaviour is not easily fixable or even intended by design, it should at least be mentioned in the docs. It caught me by surprise and it also makes „portmap -q“ less useful. For „smtpd_sender_login_maps“ the LDAP configuration must be written from the chroot perspective which is not handled by „portmap -q“. Here is another rather old thread (https://groups.google.com/g/list.postfix.users/c/JZxZiOMmgKk) which never got an answer. I bet the author encountered the same problem. Bests, Matthias Am Samstag, 4. November 2023, 22:33:48 CET schrieb Wietse Venema via Postfix-users: > Viktor Dukhovni via Postfix-users: > > On Sat, Nov 04, 2023 at 09:48:32AM -0400, Wietse Venema via Postfix-users > > wrote: > > > > > To be precise: Postfix opens your LDAP configuration file and asks > > > the LDAP library to create an LDAP client instance, before entering > > > the chroot jail and before accepting any SMTP client commmands. > > > > > > HOWEVER, Postfix does not connect to LDAP sockets before entering > > > the chroot jail and before accepting any SMTP client commmands. The > > > LDAP library decides when it wants to do that. > > > > IIRC there we were once upon a time requeting immediate connections to > > LDAP, but that was not ideal: > > > > - It complicated connection sharing across multiple tables with > > the same underlying backend server, that differ only in the > > query deails. > > > > - It also (when chrooted) meant automatic reconnect on error > > to an alternative server, ... would not necessarily work. > > > > - ... > > > > IIRC, the is in principle a way to perform an early, rather than delayed > > LDAP bind, but the OP should instead use: > > > > proxy:ldap:... > > > > with "proxyread" not chrooted. This further improves connection sharing > > and is a best practice. > > Confirmed. proxy:ldap improves sharing and can sidestep chroot issues, > as long as the read-only 'proxymap' service is not chrooted in master.cf. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > -- Matthias Nagel Dachtlerstr. 2, 40499 Stuttgart Festnetz: +49-711-25295180, Mobil: +49-151-15998774 E-Mail: matthias.h.na...@posteo.de, Skype: nagmat84, Threema: 86VM8KN7 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] When using LDAP over socket, „smtpd_sender_login_maps“ requires an LDAP socket relative to chroot in contrast to other map configurations (potential bug?)
Hello all, I am using Postfix 3.8.1 on Ubuntu 23.10. Per distribution default, Postfix runs chrooted. I have setup LDAP lookups for most maps. OpenLDAP is only listening via UNIX socket on ldapi:///var/run/slapd/ldapi. For all but one LDAP lookup the corresponding Postfix configuration file looks like root@h12345678:~ # cat /etc/postfix/ldap/virtual-mailboxes.cf server_host = ldapi:///var/run/slapd/ldapi bind = yes bind_dn = ... bind_pw = ... The path to the socket is absolute. Absolute socket paths work for "virtual_mailbox_maps", "virtual_alias_maps", etc. and all other directive except for „smtpd_sender_login_maps“. "smtpd_sender_login_maps" requires a *relative* path to the LDAP socket and the LDAP socket must be located within the chrooted environment. With an absolute path I get the following error logs my-host.my-domain.tld postfix/submission/smtpd[341439]: >>> START Sender address RESTRICTIONS <<< my-host.my-domain.tld postfix/submission/smtpd[341439]: generic_checks: name=reject_authenticated_sender_login_mismatch my-host.my-domain.tld postfix/submission/smtpd[341439]: ctable_locate: leave existing entry key jane@receiver.tld?sen...@my-domain.tld my-host.my-domain.tld postfix/submission/smtpd[341439]: dict_ldap_lookup: In dict_ldap_lookup my-host.my-domain.tld postfix/submission/smtpd[341439]: dict_ldap_lookup: No existing connection for LDAP source /etc/postfix/ldap/sender-login.cf, reopening my-host.my-domain.tld postfix/submission/smtpd[341439]: dict_ldap_connect: Connecting to server ldapi:///var/run/slapd/ldapi my-host.my-domain.tld postfix/submission/smtpd[341439]: dict_ldap_connect: Actual Protocol version used is 3. my-host.my-domain.tld postfix/submission/smtpd[341439]: dict_ldap_connect: Binding to server ldapi:///var/run/slapd/ldapi with dn ... my-host.my-domain.tld postfix/submission/smtpd[341439]: warning: dict_ldap_connect: Unable to bind to server ldapi:///var/run/slapd/ldapi with dn ... my-host.my-domain.tld postfix/submission/smtpd[341439]: warning: ldap:/etc/postfix/ldap/sender-login.cf lookup error for "sen...@my-domain.tld" my-host.my-domain.tld postfix/submission/smtpd[341439]: maps_find: smtpd_sender_login_maps: sen...@my-domain.tld: search aborted my-host.my-domain.tld postfix/submission/smtpd[341439]: NOQUEUE: reject: RCPT from dial-up.client.provider.tld[x.y.w.z]: 451 4.3.0 : Temporary lookup failure In order to make it work, the configuration file for "smtpd_sender_login_maps" must look like root@h12345678:~ # cat /etc/postfix/ldap/sender-login.cf server_host = ldapi://private/ldapi bind = yes bind_dn = ... bind_pw = ... Note, that there is only a double slash (//) after the protocol specifier, not a tripple slash (///) to form a relative path. I also had to make OpenLDAP listen on that additional socket (obvisouly). With that modified configuration, LDAP lookup for „smtpd_sender_login_maps“ does work. However, and that is annoying, postmap stops working for this particular map, i.e. postmap -q sen...@my-domain.tld ldap:/etc/postfix/ldap/sender-login.cf returns an error, because postmap does not chroot postmap does not find the LDAP socket. - Why does „smtpd_sender_login_maps“ behave differently than all other configuration options which allow LDAP lookup? - Is this an oversight? Is it an „bug“ in the Postfix software? All other LDAP connections seem to opened by Postfix before chrooting. - Did I miss something in the docs? If this is not a bug, but intended behaviour, there should at least a hint in the docs that „smtpd_sender_login_maps“ is special with respect to LDAP configuration Bests, Matthias ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
