[Protocol filtering stops access to emails]

The last few days/weeks I've been in contact with Peter and he consulted the ESET dev team to solve my issue. We tried several things, I sent several logs and tried a patched version of the filtering part but it didn't help. Finally my issue disappeared after I removed some certificates from the 'Manage Certificates' config box in Thunderbird. This were certificates I (long ago) accepted due to self-signed certificates or test servers. Some servers I connect to now (which have now a valid certificate) had an certificate in that box (but not all). It looks like somehow something got confused by those certificates.

After deleting my own accepted certificates, I could enable the IMAPS check in ESET again and everything works fine. It doesn't explain where and why things went wrong and unfortunately I cannot reproduce it any more. You could try this too (and make a backup of the certificates first for debugging purposes).

[Protocol filtering stops access to emails]

30 minutes ago, itman said:

This is Linux/Unix based. Are you accessing this via the Win 10 Linux interface?

It is not a local e-mail server, this is a remote (public) server on CentOS.

[Protocol filtering stops access to emails]

Hmmm, but if Thunderbird works how it's configured, it shouldn't use SSL v2. So the setting shouldn't matter for me. In Thunderbird I have deprecated  TSL versions disabled and the value of security.tls.version.min is 3 (which should mean: TLS 1.2 is the minimum required encryption protocol.).

 

[Protocol filtering stops access to emails]

I just uploaded a new log to a private message thread chat with Peter and TomasP.

[Protocol filtering stops access to emails]

14 hours ago, Marcos said:

Have you tried rebooting the computer? Do you have the option to block SSL2 enabled?

Block SSL2 option was enabled. Disabled the block SSL2 option, no change. Completely rebooted the computer. No change. Enabled the SSL2 option. No change.

[Protocol filtering stops access to emails]

I got 1410.1 with the beta release, but unfortunately still no connection.

[Protocol filtering stops access to emails]

On 11/2/2020 at 10:07 AM, Peter Randziak said:

in case you still face the issue after the certificate re-generation  

I don't know what certificate re-generation you're talking about, but I just sent you a message with a link to a generated log.

[Protocol filtering stops access to emails]

11 hours ago, itman said:

Eset has a setting for SSL/TLS protocol scanning accessible via Advanced Setup that blocks SSL v2 traffic. I suspect this setting; possibly by mistake in ver. 14, is now blocking all SSL traffic. Disable this setting and see if e-mail connectivity to its server is resolved.

Thanks for the suggestion, but changing this setting doesn't resolve the issue for me.

[Protocol filtering stops access to emails]

1 hour ago, Marcos said:

Please try the following:

- switch to the pre-release update channel in the advanced update setup
- with TB closed, disable SSL filtering and click OK
- re-enable SSL filtering and click OK
- launch TB and check if the issue persists.

Done that, but no change. Got an update to ESET 14.0.22.0, no change.

For me every IMAP (remote) server fails with IMAPS scanner on (gmail, office 365, ....)

But...I just installed a new laptop with exactly the same software (Thunderbird profile is a file copy, so exactly the same) and that one has no problem at all. On my old laptop it suddenly appeared last week after turning on my computer. So there must be a special corner case....

[Protocol filtering stops access to emails]

I'm having the same problem. Since a few days my Thunderbird (78.4.0) won't connect to SSL IMAP accounts if IMAPS protocol filtering is enabled in ESET.

My mailserver responds:

Oct 28 11:02:39 srv212 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=..., lip=..., TLS handshaking: Connection closed, session=<RIV2Q7iyL/AgAQmCLKoAAbkEkhRHCuES>
Oct 28 11:02:39 srv212 dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=..., TLS: read(size=637) failed: Connection reset by peer, session=<7Px4Q7iyK/AgAQmCLKoAAbkEkhRHCuES>