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 ?

Nothing.  ;)  Hm.  I think i have misread the documentation
anyhow, this is totally false: i have also thought that
check_ccert_access is used to enable permit_tls_clientcerts.  Hm.
I have to reread it all, i did so first and last in 2015, for my
server VM, and that is simple, allows no logins at all!

Thanks for pointing this out.

I think i have real shortcomings understanding the syntax above,
actually.  I thought the above is worked sequentially, and some
actions are "insertions", for example there is "sleep SECONDS",
which is then performed when walking the chain of tests, at the
very position of the chain, in place.  I thought this
check_ccert_access is like that, too, loading the according DB, to
enable permit_tls_clientcerts.  Obviously wrong.

So the check_ccert_access check makes the test login succeed when
there is a client certificate, the remains of the chain are not
evaluated at all, but the SASL login is then performed as
a totally different step because i have smtpd_sasl_auth_enable?
This has nothing to do with the permit_sasl_authenticated in the
chain above, thus.  But no, here smtpd_sasl_auth_enable is used to
enable permit_sasl_authenticated in chains, says the
documentation.

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.

I better go now. :)

I really have to try out reject_unauth_pipelining.  Hm!

 |Emmanuel.

Au revoir.

 --End of <ca89a3dc-097f-3b35-481c-6d5d3463a...@external.thalesgroup.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Reply via email to