Am 06.07.23 um 21:39 schrieb Viktor Dukhovni via Postfix-users:
So the service provider advertises, but fails to implement "PLAIN", that
sounds like a bad idea. Open a bug report. They should not do that.
I did have one open. More for cram-md5 than plain, of course. The issue
is: For older accounts created with them cram-md5 (an plain?) still do work.
Currently there are still two accounts left, where I may (or rather have
to) use the old method (cram-md5).
If I were to change the passwords of those two accounts (or alter them
in any other way), they would need to switch to login. That is true for
both their pop3 as well as smtp service. Both of which, from their
perspective, are intended to be used with mail clients, not postfix or
fetchmail.
While this may be a questionable way of doing things, it surely is
intentional, so they won't fix it. It is part of their migration path, I
assume.
Having dedicated server for either methods would have been better in my
account. But it is how it is
So technicalls their smtp server still does support cram-md5 - and
therefore supposedly also plain - just not for all accounts. As
confirmed by their (rather questionable) support.
What consequences this may have, remains to be seen. WIP.
changing back to login:
There are no "superset mechanisms" in SASL. Just discrete method names,
however for purposes of options there are some required mechanism
properties that one configure in the SASL security options. Postfix
supports:
forward_secrecy
mutual_auth
noactive
noanonymous
nodictionary
noplaintext
There also these days no "kerberos" mechanism, just "gssapi".
Thanks for that comprehensive list. But it confirms my confusion:
noplaintext is no sasl mechanism, but it is a superset of at least two
mechanisms (to disallow): login and plain.
It is the way postfix does it, and may make sense from a security
perpective, but when I was trying to read the documentation, I was
focued on how to tell postfix what to do and not, what not to do. The
last four in your list are starting with "no"
That is why I have gotten the sasl filter initially completely wrong.
smtp_sasl_security_options are focused on metasets (as noplaintext, on
what I of course have been focussed), while the
smtp_sasl_mechanism_filter uses concrete sasl mechanism.
If you know it, you figure, as it already states it in the name, but I
did not get the logic initially.
Therefore again a big, big thanks for your time and help and explanations.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
