On Wed, Jul 05, 2023 at 02:42:54PM +0200, Ede Wolf via Postfix-users wrote:
> I am having a weired issue. My provider for the relayhost switched to
> SSL - which is fine by itself - but that also changed the authentication
> scheme.
What SASL mechanism was used before that? You're in fact generally
better off with SASL "plain", because the risk of password compromise
is higher when password-equivalent material is stored on the server,
rather than some sort of one-way hash, which requires the client to
send the "plain" password for verification.
There are of course in the cryptography literature various "PAKE"
algorithms, that make it possible for the client to prove knowledge of a
password without sending it to the server, and without the server
storing password-equivalent material, but such mechanisms are not IIRC
at all widely supported by SASL implementations, and are not easy to
configure.
So most likely switching from, say, CRAM-MD5 or similar to PLAIN is
likely progress. As is enabling TLS, regardless of whether the SASL
mechanism is challenge-response based.
> So SASL, what worked for over a decade, does not work any more, instead
> I need to send plain text username/pw. Confirmed by the providers support.
Possibly a case of the blind leading the blind, but probably correct.
> Wether this is good or braindead is not a matter of debate on the short
> term. It is, what it currently has become.
See above, this is likely progress. I do hope they scrubbed the
cleartext passwords in the process and now store just the hashes.
> So now I am wondering, wether or how this could be accomplished with
> postfix?
>
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:$meta_directory/smtp_auth
> smtp_sasl_security_options =
> #smtp_sasl_security_options = noanonymous
>
> But I am not sure, how to convert this into simple plain text auth.
> Google advised to leave the smtp_sasl_security_options
> empty, but that did not do the trick.
That's not quite the whole story, the relevant documented defaults are:
smtp_sasl_security_options (default: noplaintext, noanonymous)
smtp_sasl_tls_security_options (default: $smtp_sasl_security_options)
smtp_sasl_tls_verified_security_options (default:
$smtp_sasl_tls_security_options)
But you need at least the last of these to admit "plaintext" (i.e. not
specify "noplaintext"). The correct (security-minded) configuration is:
# smtp_sasl_security_options = noplaintext noanonymous
# smtp_sasl_tls_security_options = $smtp_sasl_security_options
smtp_sasl_tls_verified_security_options = noanonymous
Use a custom "default_transport" with an explicit "nexthop" relay,
instead of just "relayhost". This makes it possible to specify
appropriate TLS policy settings without resorting to a TLS policy table.
main.cf:
# Possibly with a ":port" suffix
default_transport = isprelay:[smtp.provider.net]
master.cf:
# Note, no chroot!
isprelay unix - - n - - smtp
-o { smtp_tls_security_level = secure }
-o { smtp_tls_CAfile = /etc/postfix/ispcas.pem }
The "ispcas.pem" file (or pick another pathname) can list just the CAs
you trust and expect to issue the ISPs certificate (ideally less than
the entire browser CA/B forum CA "bundle").
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
