Re: AW: Postfix 3.4.14 - Dovecot SASL - strange/buggy behavior in combination with compatibility_level
Podskubka, Stefan: > Wietse Venema: > > The error happened because the hostname "dovecot" did not resolve. > > > > This may be affected by how compatibility_level is set, because > > compatibility_level is processed before Postfix's chroot feature makes some > > files inaccessible. > > Wow, I was completely thrown off the right track by the error message, thanks > for clearing the confusion up so quickly. Indeed. Instead of "dovecot/666" it should logged dovecot:666 because that is what it was actually using. Fixed in Postfix 3.7. I don't think that change is going to break working systems. Wietse > So, to summarize: > > With compatibility_level=0 the chroot default is yes. > My smtpd process for port 25 runs chrooted because chroot=- while the smtpd > process for port 465 does not run chrooted because chroot=n (I totally > overlooked this small difference between my two smtpd processes in > master.cf). > When the smtpd process runs chrooted it doesn't have access to /etc/hosts and > /etc/resolv.conf, which prevents any host name resolution, so it cannot > connect to the Dovecot SASL. > > With compatibility_level=2 the chroot default is no. > This causes both of my smtpd processes to not run chrooted, so the hostname > resolution works in both. > > Sorry for suspecting a buggy implementation! > I'm actually a software developer myself so I should know better than to > quickly jump to conclusions. > > Thanks Wietse! > > Best regards > Stefan >
AW: Postfix 3.4.14 - Dovecot SASL - strange/buggy behavior in combination with compatibility_level
Wietse Venema: > The error happened because the hostname "dovecot" did not resolve. > > This may be affected by how compatibility_level is set, because > compatibility_level is processed before Postfix's chroot feature makes some > files inaccessible. Wow, I was completely thrown off the right track by the error message, thanks for clearing the confusion up so quickly. So, to summarize: With compatibility_level=0 the chroot default is yes. My smtpd process for port 25 runs chrooted because chroot=- while the smtpd process for port 465 does not run chrooted because chroot=n (I totally overlooked this small difference between my two smtpd processes in master.cf). When the smtpd process runs chrooted it doesn't have access to /etc/hosts and /etc/resolv.conf, which prevents any host name resolution, so it cannot connect to the Dovecot SASL. With compatibility_level=2 the chroot default is no. This causes both of my smtpd processes to not run chrooted, so the hostname resolution works in both. Sorry for suspecting a buggy implementation! I'm actually a software developer myself so I should know better than to quickly jump to conclusions. Thanks Wietse! Best regards Stefan smime.p7s Description: S/MIME cryptographic signature
Re: Postfix 3.4.14 - Dovecot SASL - strange/buggy behavior in combination with compatibility_level
Podskubka, Stefan:
> Aug 10 19:39:14 4097ff109d16 postfix/smtpd[112]:
> xsasl_dovecot_server_connect: Connecting
> Aug 10 19:39:14 4097ff109d16 postfix/smtpd[112]: fatal: host/service
> dovecot/666 not found: Device or resource busy
This error message is from inet_connect():
if ((parse_err = host_port(buf, , "localhost", , (char *) 0)) !=
0)
msg_fatal("%s: %s", addr, parse_err);
if ((aierr = hostname_to_sockaddr(host, port, SOCK_STREAM, )) != 0)
msg_fatal("host/service %s/%s not found: %s",
host, port, MAI_STRERROR(aierr));
It means that you must have specified "inet:dovecot:666", because
host_port() was successful.
The error happened because the hostname "dovecot" did not resolve.
This may be affected by how compatibility_level is set, because
compatibility_level is processed before Postfix's chroot feature
makes some files inaccessible.
The warning could be improved by doing this:
msg_fatal("host or service %s not found: %s",
addr, MAI_STRERROR(aierr));
Wietse
Postfix 3.4.14 - Dovecot SASL - strange/buggy behavior in combination with compatibility_level
Dear Postfix experts!
Although I have found a solution/workaround for the problem mentioned here, for
what it's worth, I still wanted to make the effort to report it as a possible
bug.
Summary
===
I have a test setup on my local machine where I am running Postfix and Dovecot,
each in a separate container, for a specialized purpose (not as a public e-Mail
server).
The Postfix container is based on Debian Buster with Postfix 3.4.14 installed
from the default Debian apt repository.
The Dovecot container, reachable via hostname 'dovecot', has an open TCP port
666 for Dovecot SASL, which should be used by Postfix for SMTP Authentication.
Postfix has two smtpd processes configured in master.cf, one for SMTP (port 25,
with STARTTLS) and one for SMTPS (port 465, with implicit TLS).
In main.cf I have configured postfix to use the Dovecot SASL via
smtpd_sasl_path=inet:dovecot:666.
Also, the configuration was initially migrated from an older Postfix version
and was still missing the compatibility_level setting (so default value 0).
Now, when I test the connection using 'openssl s_client' I get two different
behaviors:
* the connection with implicit TLS to port 465 works without a problem, I can
connect incl. TLS handshake, I receive the server greeting and am able to
authenticate
* the connection with explicit TLS (STARTTLS) to port 25 has an issue: I can
connect, the initial EHLO and STARTTLS commands are sent, the TLS handshake is
done, then Postfix aborts the connection.
Solution: When I add compatibility_level=2 to main.cf the connection to port 25
is not aborted after STARTTLS and the TLS handshake and everything works fine.
Initial Configuration
=
postfinger - postfix configuration on Tue Aug 10 19:28:18 UTC 2021
version: 1.30
--System Parameters--
mail_version = 3.4.14
hostname = 3e6c12d24f52
uname = Linux 3e6c12d24f52 4.19.128-microsoft-standard #1 SMP Tue Jun 23
12:58:10 UTC 2020 x86_64 GNU/Linux
--Packaging information--
looks like this postfix comes from deb package: postfix-3.4.14-0+deb10u1
--main.cf non-default parameters--
alias_database =
alias_maps =
append_dot_mydomain = no
biff = no
debug_peer_level = 5
debug_peer_list = 0.0.0.0/0
enable_long_queue_ids = yes
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
maillog_file = /dev/stdout
maximal_queue_lifetime = 100d
message_size_limit = 52428800
mydestination =
protocol_destination_recipient_limit = 1
recipient_bcc_maps = pcre:/etc/postfix/bcc_maps
smtp_host_lookup = native
smtp_tls_loglevel = 2
smtpd_banner = $myhostname ESMTP test server
smtpd_recipient_restrictions = check_recipient_access
pcre:/etc/postfix/bcc_reject
smtpd_relay_restrictions = permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = inet:dovecot:666
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/hub.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams2048.pem
smtpd_tls_exclude_ciphers = ADH aNULL
smtpd_tls_key_file = /etc/pki/tls/private/hub.key
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = $smtpd_tls_ciphers
smtpd_tls_mandatory_exclude_ciphers = $smtpd_tls_exclude_ciphers
smtpd_tls_mandatory_protocols = $smtpd_tls_protocols
smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_preempt_cipherlist = yes
transport_maps = pcre:/etc/postfix/bcc_transport_maps
proxy:pgsql:/etc/postfix/pgsql-transport_maps.cf
virtual_alias_maps = pcre:/etc/postfix/bcc_alias
virtual_mailbox_domains =
proxy:pgsql:/etc/postfix/pgsql-virtual_mailbox_domains.cf
virtual_mailbox_maps = proxy:pgsql:/etc/postfix/pgsql-virtual_mailbox_maps.cf
virtual_transport = lmtp:inet:dovecot
--master.cf--
smtp inet n - - - - smtpd
# Messages received via SMTP should be forwarded to the content filter.
-o content_filter=filter:dummy
# Automatic BCC to protocol should not happen here (only after the content
filter).
-o receive_override_options=no_address_mappings
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
# Messages received via SMTP should be forwarded to the content filter.
-o content_filter=filter:dummy
# Automatic BCC to protocol should not happen here (only after the content
filter).
-o receive_override_options=no_address_mappings
pickupunix n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace
