On Mon, Aug 11, 2025 at 03:25:51PM -0600, James Feeney wrote:
> 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;".
For what should be obvious reasons. :-) A restriction grammar without
rule order/precedence is unusable. Either all the deny rules are
useless, or none of them can be preëmpted by specific exclusions.
> Your summary would be a useful addition to the SASL documentation -
> though better without the "for what should be obvious reasons" bit.
Got to get those said before the gate is shut. :-)
> ----
> 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.
> ----
LOGIN is rather outdated. PLAIN is quite sufficient, my MSA does not
support LOGIN.
> ----
> 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.
> ----
Don't. They address completely the wrong threat model. Transmission
confidentiality is better handled with TLS. And with PLAIN the server
stores only password hashes, while while CRAM-MD5 it stores password
cleartext. So unless your users are issued strongly random
server-specific passwords (like all my "PLAIN" users) that they'd never
reuse for any other purpose, you should avoid CRAM-MD5, ... and stick to
PLAIN.
> 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.
It works, but you don't want to use it.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
