On Sun, Aug 10, 2025 at 03:23:06PM -0600, James Feeney wrote:
> Well, the example in Postfix Configuration Parameters suggests using the
> "smtpd_client_restrictions" stage for configuration, as:
> ----
> To reject all SMTP connections from unauthenticated clients, specify
> "smtpd_delay_reject = yes" (which is the default) and use:
>
> smtpd_client_restrictions = permit_sasl_authenticated, reject
> ----
It *does* clearly state to have "delay reject" set to "yes". Ignoring
that advice has consequences, and one needs to first take the time to
understand them.
Anyway, that's all about the timing. As for questions that are actually
about SASL, some of that documentation could likely be better. But
you'll need to take the time to be sure that the new advice isn't unduly
biased by the specifics your specific configuration and choices of
mechanisms.
General advice about Cyrus SASL needs to work not only for PLAIN and
LOGIN, but also for e.g. GSSAPI, where the concepts of "domain" and
"realm" have separate meanings, and the authenticated SMTP client name
is "username@REALM" or "hostname/service@REALM", ...
Though if you're focused specifically on "saslauthd", IIRC that is
indeed limited to verification of input password strings, but I usually
delegate that work to PAM ("saslauthd -a pam"), which offers a more
familiar and reasonably flexible interface.
Though my real advice is to use "dovecot" auth on the server side, even
for GSSAPI, where its support for keytabs is in some ways more flexible
than than of Cyrus SASL (supports "$ALL" for the server principal name,
for example).
This is a somewhat complex topic, and there's no royal road to getting
there. If you're lucky you'll find an well design example that meets
your needs, otherwise some effort is needed to research the building
blocks. :-(
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
