On 10/12/2022 20:13, Slavko via Exim-users wrote:
> Dňa 10. decembra 2022 17:01:52 UTC používateľ Jeremy Harris via Exim-users <exim-users@???> napísal:
>
>> Yes, for SNI it have to be after the first bit of the TLS startup
>> exchange.
>
> Now i am confused. I read that commit (docs changes), but it
> is not clear for me, will have $tls_in_* variables values in
> connect ACL? I guess that no, but if so, please can you mention
> that somewhere?
No; since the TLS startup has not been done, the TLS client Hello
has not yet ben seen by the TLS library and Exim has had no
opportunity to fill in $tls_in_*
> I am using the SNI variable in connect ACL, to filter rogue
> connections eg. with my MX name or no SNI at all (465).
Doing that never would have worked for non- TLS-on-connect,
and now it won't work ever. Your 465 operations will need
rethinking in this respect.
> Also, you previously mention using not valid certificate for wrong
> SNI name to get TLS failed (or so). It is not clear for me if you mean
> certificate with not valid name or file which is not certificate (eg.
> /dev/null).
The latter. Logged error messsages become a little abstruse, but
it does what's needed (the TLS startup fails).
> Please, can you elaborate more what you mean by that? + some
> example if appropriate.
tls_certificate = ${if eq {$tls_in_sni}{disliked_sni} {/dev/null} {my_good_certfile}}
>>> When i recently tried to use "encrypted=" ACL condition in helo ACL
>>> i got error, thus while fully equivalent, they are not interchangable
>>> in all related ACLs and it was not documented.
> LOG: ... temporarily rejected EHLO or HELO ...:
> cannot test encrypted condition in EHLO or HELO ACL
Ah, ok. There has always been a specific lockout against trying
to use that ACL condition in that circumstance, because it make no
sense for STARTTLS. And TLS-on-connect wasn't thought of.
Sorry to have misled you.
--
Cheers,
Jeremy
