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)
