On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote:
> Emmanuel Fusté wrote in
> <ca89a3dc-097f-3b35-481c-6d5d3463a...@external.thalesgroup.com>:
> |Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
> |> Something else, maybe.
> |> I do not understand why my (stupid) config
> |>
> |> smtpd_sender_restrictions =
> |> check_ccert_access hash:/etc/postfix/relay_clientcert,
> |> permit_tls_clientcerts,
> |> reject_unknown_sender_domain,
> |> #reject_sender_login_mismatch,
> |> permit_sasl_authenticated,
> |> reject
> |>
> |> succeeds only if reject_sender_login_mismatch is commented out
> |> _unless_ i pass a valid client certificate. I.e., even if
> |> anything is ok except for with/out client certificate:
>
> |Just for this part : what is your content of the map configured by
> |smtpd_sender_login_maps ?
>
> I am confused. That makes no sense. To reiterate, if i pass
> a valid client certificate check_ccert_access matches, the rest of
> the chain is skipped, but SASL authentication is still performed,
> permit_sasl_authenticated still matters! If i do not pass a valid
> client certificate, reject_sender_login_mismatch triggers because
> .. but the map is empty! Also for this test the order of the
> chain cannot matter, because SASL authentication happens later.
> Whatever. Note the error happens after authentication was
> reported as being successful.
What you're actually confused about has little to do with client certs
and to some extent SASL.
First and foremost you need to understand that a "permit" action in the
sender restrictions is NOT final, it just short-circuits the *sender*
restrictions, the rest of restrictions, and in particular the "relay"
and "recipient" restrictions are still processed.
Therefore, the "check_ccert_access" you actually care about is the one
in "smtpd_relay_restrictions" and/or "smtpd_recipient_restrictions".
Your other point of confusion is that you're imagining that the
restriction processing determines the SMTP protocol control flow, such
that SASL authentication only happens when "permit_sasl_authenticated"
or similar is evaluated.
In fact, by the time (especially smtpd_delay_reject=yes, the strongly
recommended default) that the restriction processing is happening, the
SASL authentication handshake is long in the past. It happens
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).
The protocol flow is:
C: SYN
S: SYN-ACK
C: ACK
S: 220 greeting
C: EHLO <clientname>
S: 250-<servername>
...
250 STARTTLS
C: STARTTLS
S: 250 make my day...
C: TLS client hello
S: TLS server hello
<both>: ... sound and fury of TLS handshake ...
---- Channel is now TLS encrypted ----
C: 250 EHLO <clientname>
S: 250-<servername>
...
250 AUTH PLAIN GSSAPI ...
C: !!! chooses to perform or skip SASL !!!
--- possible SASL handshake here ---
C: MAIL FROM:<sender> BODY=8BITMIME SIZE=...
S: 250-OK
C: RCPT TO:<recipient> ORCPT=...
S: --- evaluates *ALL* restrictions here! ---
client restrictions -- might look at cert or SASL login
helo restrictions -- might look at cert or SASL login
sender restrictions -- might look at cert or SASL login
recipient restrictions -- might look at cert or SASL login
relay restrictions -- might look at cert or SASL login
S: 250 OK (or 5XX go spam someone else)
C: DATA
S: ---- evaluates data restrictions here -- might look at cert or SASL login
354 Go ahead (or 5XX go spam someone else)
C: <message body>
.<CRLF>
S: ---- evaluates end of data restrictions here -- might look at cert or
SASL login
S: 250 OK (or 5XX go spam someone else)
C: QUIT
S: 221 Goodbye
With this in mind, you'll have an easier time to understand where
SASL and client certs fit into the picture.
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
not caught up, and I hope it will change again 3.6, provided you set
the compatibility level high enough. But this is unlikely to matter
terribly much in most cases.
--
Viktor.
