We recently changed hosting for our perimeter MTAs and also switched to
SMTPS, based recent standards-track RFCs. As I can "solve the problem"
by going with STARTTLS, this is more of a bug report than a request to
solve the problem. (I'm now aware that the opinions on wrapper vs.
STARTTLS vary.)
We started noticing that incoming mail from a single sender (mailing
lists, perhaps just netdev, from vger.kernel.org) to a single recipient
(l...@mydomain.com) on our relay_domains list would occasionally end up
in the deferred queue at the perimeter MTA rather than be delivered to
the interior MTA for local delivery.
The deferred message queue listing indicates "(server unavailable or
unable to receive mail)"
The logs show, for example
2025 Apr 11 00:27:36.696 -07:00 mx1 warning: postfix/relay/smtp[69584]:
warning: smtp_tls_wrappermode requires "smtp_tls_security_level =
encrypt" (or stronger)
2025 Apr 11 00:27:36.703 -07:00 mx1 info: postfix/relay/smtp[69584]:
E12F731C5D: to=<l...@mydomain.com>, relay=none, delay=228559,
delays=228559/0/0/0, dsn=4.3.0, status=deferred (server unavailable or
unable to receive mail)
Looking at logs with `smtp_tls_loglevel = 2` suggests that there is no
connection attempt made.
`tcpdump` confirms that no outgoing packets are sent.
The relayhost is set in main.cf and connections for apparently all other
sender-recipient pairs, as well as this one for most other messages
(netdev is relatively active, with 17 delivered in the last hour). The
consistent pattern supports that this is not a network issue.
Holding and requeueing the message does not change the outcome.
Outgoing mail to Amazon SES seems to be sent over smtps with the smtp
agent without this deferral problem.
Previous configuration using `relay_transport = smtp:[fd83:<internal
MTA>]:smtps` also suffered this problem.
To the best of my knowledge, there are no transport maps in play.
On perimeter MX
main.cf:
relayhost = [fd83:<internal MTA>]:smtps
default_transport = smtp:[email-smtp.us-west-2.amazonaws.com]:smtps
smtp_tls_loglevel = 2
smtp_tls_security_level = encrypt
smtp_tls_wrappermode = yes
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
The smtp_tls_wrappermode and smtp_tls_security_level were confirmed in
the output of `postconf -n`
Modifying master.cf as follows did not resolve the issue
relay unix - - n - - smtp
-o
syslog_name=${multi_instance_name?{$multi_instance_name}:{postfix}}/$service_name
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
-o smtp_tls_wrappermode=yes
-o smtp_tls_security_level=encrypt
[jeff@mx1 ~]$ freebsd-version
14.2-RELEASE-p2
[jeff@mx1 ~]$ pkg info | fgrep postfix
postfix-sasl-3.10.0,1 Secure alternative to widely-used
Sendmail (with Cyrus SASL support)
[jeff@mx1 ~]$ openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)
If someone decides to chase this inconsistent behavior down and needs
more information, please let me know.
Jeff
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
