Hey Viktor On Sat, 2025-08-09 at 15:26 +1000, Viktor Dukhovni via Postfix-users wrote: > The solution for "permit_sasl_authenticated" is to evaluate it in the > sender restrictions or later, with "smtpd_delay_reject = no", both the > client and helo restrictions are too early for what should be obvious > reasons.
Ha! Everything is obvious in retrospect. I was rather amused with the YouTube video of present-day college students tasked with making a phone call from a dial telephone. They failed. After a little more testing, I see that, not only must the restrictions be placed at the correct stage, and *no matter whether smtpd_delay_reject is yes or no*, at any stage, the restrictions must *also* be placed in the correct sequence, within that stage. So then, for my port 465 use case: ---- -o smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination ---- will work, but: ---- -o smtpd_relay_restrictions=reject_unauth_destination,permit_sasl_authenticated ---- will fail with "554" and "Relay access denied;". Your summary would be a useful addition to the SASL documentation - though better without the "for what should be obvious reasons" bit. On Mon, 2025-08-11 at 13:42 +1000, Viktor Dukhovni via Postfix-users wrote: > General advice about Cyrus SASL needs to work not only for PLAIN and > LOGIN, but also for e.g. GSSAPI, ... A bit of a tangent, I was surprised to see this at https://web.mit.edu/darwin/src/modules/passwordserver_sasl/cyrus_sasl/doc/sysadmin.html ---- The LOGIN mechanism (not to be confused with IMAP4's LOGIN command) is an undocumented, unsupported mechanism. It's included in the Cyrus SASL distribution for the sake of SMTP servers that might want to interoperate with old clients. Do not enable this mechanism unless you know you're going to need it. When enabled, it verifies passwords the same way the PLAIN mechanism does. ---- Not that it should matter if LOGIN is allowed. But then, I also was wondering about the part that followed there: ---- The Cyrus SASL library also supports some "shared secret" authentication methods: CRAM-MD5 and its successor DIGEST-MD5. These methods rely on the client and the server sharing a "secret", usually a password. The server generates a challenge and the client a response proving that it knows the shared secret. This is much more secure than simply sending the secret over the wire proving that the client knows it. ---- Sure enough. Using: ---- -o smtpd_sasl_mechanism_filter=plain,login,CRAM-MD5,DIGEST-MD5 ---- gnome evolution supports CRAM-MD5 - though DIGEST-MD5 was not allowed - and it works. That is on Arch Linux with libsasl 2.1.28-5. In the SASL README, some people may also be interested in the included Kerberos link: ---- You may want to consult the GSSAPI Tutorial. https://web.mit.edu/darwin/src/modules/passwordserver_sasl/cyrus_sasl/doc/gssapi.html ---- I have not tried that myself, and in Arch Linux, there is a separate package, cyrus-sasl-gssapi. Actually, in Arch, several other mechanisms also require separate packages, including: cyrus-sasl-sql, cyrus-sasl-ldap, and in the AUR, cyrus-sasl-xoauth2-git, and gsasl-ntlm. As you say, "This is a somewhat complex topic." Also, more generally: ---- https://web.mit.edu/darwin/src/modules/passwordserver_sasl/cyrus_sasl/doc/index.html Cyrus SASL library, version 2.0 ---- James _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
