Wietse Venema via Postfix-users:
> Viktor Dukhovni via Postfix-users:
> > On Fri, Jan 17, 2025 at 08:57:02AM +0100, Tobi via Postfix-users wrote:
> >
> > > > That would be unexpected. I'm implementing support for REQUIRETLS
> > > > (RFC 8689) and that code is supposed to try multiple MXes before it
> > > > gives up.
> > > >
> > > > Have you perhaps configured smtp_mx_session_limit=1 ?
> > > >
> > > > postconf smtp_mx_session_limit
> > > postconf smtp_mx_session_limit
> > > smtp_mx_session_limit = 2
> >
> > How many *IP addresses* (IPv4 and IPv6) does the primary MX have? If it
> > is more than 1, the behaviour is as expected.
>
> Indeed. If the primary MX is dual-stack, and that server can handle
> SMTP sessions, then with "smtp_mx_session_limit = 2", the Postfix
> SMTP client will not visit alternate MXes.
>
> A simple workaround is to increase smtp_mx_session_limit.
> Even "smtp_mx_session_limit = 3" would make a difference.
>
> Postfix has multiple worst-case workarounds (balancing IPv4 versus
> IPv6, randomizing the order of equal-preference IP addresses, and
> even limiting the number of IP addresses to consider).
>
> But there was no workaround for the case that a multi-homed server
> is available but not "good enough". Maybe Postfix could skip IP
> addresses with the same (primary) MX name after a mid-session failure
> (TLS to weak, or any error that would result in mail being deferred).
>
> If this is as simple as I think it may be (one been_here() call
> with the MX hostname) then it might even go into the stable relases.
> Otherwise I'd consider changing the Postfix default to
> "smtp_mx_session_limit = 3".
Another straightfoward workaround is to not count this as a mid-session
failure. If we treat a TLS handshake failure as an SMTP handshake
failure, then the session will not count towards smtp_mx_session_limit.
> > Enforcing dane-only for a domain that does not publish TLSA RRs for
> > all MX hosts imposes a monitoring burden, and willingness to use
> > work-arounds, such as filtering the list of MX hosts you're willing
> > to accept for the domain perhaps via "smtp_dns_reply_filter".
> >
> > The real solution is to co-ordinate with the domain owner to either
> > enable DANE on all MX hosts, or set up non-DANE secure channel
> > via some suitable set of trust anchors, ...
>
> Sure, but Postfix could also be a little smarter about the impact
> of "smtp_mx_session_limit = 2" and hosts with multiple IP addresses.
>
> Or we could rearrange the Postfix TLS stack and skip a host when
> DANE is required but trust anchors are unavailable.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
