On Tue, Aug 25, 2020 at 07:06:29PM +0200, Steffen Nurpmeso wrote:
> |because:
> |
> | 1. The server indicated support for SASL in its EHLO response.
> | 2. The client chose to perform SASL auth.
> |
> |If you want clients to skip SASL auth, configure them to not use
> |SASL auth (no passwords, no EXTERNAL, just a client cert).
>
> That does not work. Oh. Yes, it does!
Naturally...
> |The protocol flow is:
> ...
> | 250 AUTH PLAIN GSSAPI ...
> | C: !!! chooses to perform or skip SASL !!!
> | --- possible SASL handshake here ---
>
> Yes, but, you know, _if_ the server announces AUTH then of course
> any automatic software will choose AUTH! Because, why would the
> server announce AUTH if it would not need it?
Because it is advertising a *capability* not a mandate. Lots of
servers advertise AUTH even when only some clients need to or
choose to use AUTH. Of course you can always set up a dedicated
MSA on some IP:port combination which only accepts client certs,
and is configured to NOT offer AUTH. That's your choice.
And for a client to initiate SASL AUTH it has to be configured with
suitable credentials, and told to use them with the server in question.
Clients don't (implementation incompetence aside) just automatically
send their passwords to some random server that happens to include
"AUTH" in its EHLO response.
> This does not make sense!
It makes sense to me. You intuition is misleading you in various
non-productive directions. Try to set some preconceptions aside
and take in a new perspective.
> |The relative order of the relay and recipient restrictions is somewhat
> |in flux at the moment, it changed in Postfix 3.3, but the docs have
>
> (Must be that, then.)
No, that's just a pedantic side comment, not relevant to your situation,
needed only to avoid a small inaccuracy.
--
Viktor.
