Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 05:51:19AM -0800, Doug Hardie wrote: > > An interesting question in your case is what fraction of the TLSv1 > > connections are non-spam. Perhaps you're able to correlate the TLSv1 > > connections with legitimate vs. junk email. > > Results for 3 weeks of log files: > > TLSv1 spam = 1182 ham = 1147 > TLSv1.1 spam = 74 ham = 6 > TLSv1.2 spam = 24355 ham = 10461 > TLSv1.3 spam = 4453 ham = 2305 > > Note, that the definition of spam is there is a NOQUEUE entry for that > IP address in the log files. Hence this is an approximation as it is > possible that the RBLs entries could have changed during those 3 > weeks. Also, I don't know what emails the recipients considered spam. > Only 2 users have mailboxes on my servers. The others are elsewhere. Thanks for the data points. So TLSv1 is not all spam, and so still likely best left enabled a bit longer. Unless it was all Postfix list traffic. :-) The folks at Cloud9 have not been keeping up with the Joneses with their TLS stack versions, some day soon TLSv1 will actually be turned off more broadly, and they'll have to upgrade or disable TLS entirely... -- Viktor.
Re: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. Results for 3 weeks of log files: TLSv1 spam = 1182 ham = 1147 TLSv1.1 spam = 74 ham = 6 TLSv1.2 spam = 24355ham = 10461 TLSv1.3 spam = 4453 ham = 2305 Note, that the definition of spam is there is a NOQUEUE entry for that IP address in the log files. Hence this is an approximation as it is possible that the RBLs entries could have changed during those 3 weeks. Also, I don't know what emails the recipients considered spam. Only 2 users have mailboxes on my servers. The others are elsewhere. -- Doug
Re: Disabling TLSv1
On 06.03.20 00:11, Daniel Ryšlink wrote: I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at the beginning of the year (since there were advisories that anything older than 1.2 is considered weak and broken), and it did not end well, there were numerous complaints from what turned out to be still supported LTS version of Windows 8 that is supported till 2023 whose Outlooks still uses the obsolete versions of TLS and their handshakes will fail. note that there's difference between disabling tls1.0 and tls1.1 on ports with mandatory encryption (smtps/465 and submission/587) and different on port 25 where mail servers will connect to. enabling older TLS versions might be better for old servers as low encryption may be better than no encryption on port 25, where fallback when TLS can't be established is common - you do want to receive mail from the internet, don't you? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse
Re: Disabling TLSv1
Hello!
Viktor Dukhovni schrieb am 05.03.20 um 18:52:55
Uhr:
> On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:
>
> > I have just too TLSv1 connections this month:
> > ...
> > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
> > 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
> > 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
> > 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> > 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> > 8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
> > 8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
> > 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
> > 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
> > 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
> > 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
> > 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
>
> That's two out of not very many total, are these actual message
> deliveries, or just probes (tests)?
That were two probes without deliveries.
On another machine I use for communicating with this maillingist I
have 25 TLSv1-connections, 23 from and 2 to connections, all with this
mailinglist.
> > > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > > perhaps prod the senders to upgrade first, before you prevent them
> > > from establishing TLS connections to your MTA.
> >
> > internet.nl says TLS 1.1 should be phased out and criticises this.
>
> Just because they say it, doesn't mean it is actually the wise thing to do.
>
> > It also critcises the key exchange paramert DH-4096 as insufficient
>
> See above.
>
> > I just created that key and made it available with
> > smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
>
> Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
> supported in some client stacks.
Went back to DH-2048.
> > Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> > for now.
>
> You can keep an eye on your logs and decide when it is time to drop
> support. The most important thing is supporting stronger options that
> most clients will negotiate. Removing weaker options is less of a
> priority except when they enable a downgrade attack.
>
> In the case of TLSv1 there's no known (to me anyway) downgrade attack
> from TLSv1.2. SMTP MTAs don't do TLS version fallback, like browsers
> used to do. There's no urgent need to drop support TLSv1 inbound.
Would it to any harm if I drop TLSv1 outbound? Will this cut off the handshake
with this mailinglist for example?
> Just make sure that you support at least TLSv1.2, and ignore the
> checklists that try to shame you for leaving TLSv1 enabled.
yes, ok.
--
Andreas
Re: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. The code to scan the logs is a bit convoluted. I have it running, but there are 44K connections to check so it will undoubtly run all night. It has completed 1200 so far in about 11 minutes. So it will take over 6.5 hours to complete. -- Doug
Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 02:16:42AM +, Allen Coates wrote: > Virtually all my TLSv1 connections come from this mailing list... > > Would there be any mileage in disabling OUTBOUND TLSv1 connections while > accepting inbound for a little while longer? You can certainly configure each direction as appropriate. In the outbound direction you also have the choice of per-destination policy. So yes, it is not unreasonable (though not that compelling, or worth much effort) to disable TLSv1 by default, and then perhaps enable it for just any sites where TLS handshakes start to fail. -- Viktor.
Re: Disabling TLSv1
Virtually all my TLSv1 connections come from this mailing list...
Would there be any mileage in disabling OUTBOUND TLSv1 connections while
accepting inbound for a little while longer?
Allen C
On 05/03/2020 20:08, ratatouille wrote:
> Hello!
>
> Don't know why TLSv1 is still offered on our servers running
>
> mail_version = 2.11.3
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
>
> but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
>
> I am not sure what's wrong. What do I miss?
>
> Other parameters I set:
> smtpd_tls_CApath = /var/lib/ca-certificates/pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
> smtpd_tls_ciphers = high
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
> EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1,
> ECDHE-RSA-DES-CBC3-SHA
> smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database =
> btree:/var/lib/postfix/smtpd_tls_session_cache
> smtpd_tls_session_cache_timeout = 3600s
>
> Regards
>
> Andreas
>
Re: Disabling TLSv1
On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > Small mail server with 3 weeks of logs: > >1761 TLSv1 > 18 TLSv1.1 > 20414 TLSv1.2 >6343 TLSv1.3 > > That's not what I expected. I thought v1 and v1.1 would be reversed. > There is a complete spectrum of ciphers being used with v1 including > some of the most recent. I am using the defaults for the protocols > and ciphers. The reversal is expected, the most widely used TLS implementations that support TLSv1.1 also support TLSv1.2, and so you see very little use of TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly never got to TLSv1.1 either. An interesting question in your case is what fraction of the TLSv1 connections are non-spam. Perhaps you're able to correlate the TLSv1 connections with legitimate vs. junk email. -- Viktor.
Re: Disabling TLSv1
> On 5 March 2020, at 15:26, ratatouille wrote: > > Viktor Dukhovni schrieb am 05.03.20 um 16:44:14 > Uhr: > >> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote: >> >>> Don't know why TLSv1 is still offered on our servers running >> >> Probably because you're not changing the configuration in the right >> place. Double-check that you're configuring the correct Postfix >> instance (if using multiple instances) and that there are no >> master.cf overrides that trump the main.cf settings. >> >>> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 >>> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 > > Found out if I want to disable TLSv1.1 too I just have to do so. > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > and suddenly it works ;) > >> Other than test TLS connections, do you still legitimate inbound email >> in your logs (looking over a week or more of logs) delivered with TLSv1? > > I have just too TLSv1 connections this month: > ... > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits) > 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits) > 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits) > 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) > 8 TLSv1.1 with cipher AES256-SHA (256/256 bits) > 8 TLSv1.1 with cipher AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits) > 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits) > 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits) > 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits) > 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits) > 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits) Small mail server with 3 weeks of logs: 1761 TLSv1 18 TLSv1.1 20414 TLSv1.2 6343 TLSv1.3 0 SSL That's not what I expected. I thought v1 and v1.1 would be reversed. There is a complete spectrum of ciphers being used with v1 including some of the most recent. I am using the defaults for the protocols and ciphers. -- Doug >
Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:
> I have just too TLSv1 connections this month:
> ...
> 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
> 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
> 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
> 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> 8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
> 8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
> 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
> 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
> 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
> 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
> 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
> 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
That's two out of not very many total, are these actual message
deliveries, or just probes (tests)?
> > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > perhaps prod the senders to upgrade first, before you prevent them
> > from establishing TLS connections to your MTA.
>
> internet.nl says TLS 1.1 should be phased out and criticises this.
Just because they say it, doesn't mean it is actually the wise thing to do.
> It also critcises the key exchange paramert DH-4096 as insufficient
See above.
> I just created that key and made it available with
> smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
supported in some client stacks.
> Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> for now.
You can keep an eye on your logs and decide when it is time to drop
support. The most important thing is supporting stronger options that
most clients will negotiate. Removing weaker options is less of a
priority except when they enable a downgrade attack.
In the case of TLSv1 there's no known (to me anyway) downgrade attack
from TLSv1.2. SMTP MTAs don't do TLS version fallback, like browsers
used to do. There's no urgent need to drop support TLSv1 inbound.
Just make sure that you support at least TLSv1.2, and ignore the
checklists that try to shame you for leaving TLSv1 enabled.
--
Viktor.
Re: Disabling TLSv1
Viktor Dukhovni schrieb am 05.03.20 um 16:44:14
Uhr:
> On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote:
>
> > Don't know why TLSv1 is still offered on our servers running
>
> Probably because you're not changing the configuration in the right
> place. Double-check that you're configuring the correct Postfix
> instance (if using multiple instances) and that there are no
> master.cf overrides that trump the main.cf settings.
>
> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
Found out if I want to disable TLSv1.1 too I just have to do so.
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
and suddenly it works ;)
> It is not yet a good idea to disable TLSv1 in SMTP. But if you must
> degrade[1] your SMTP security for some clients to make sure that all the
> check boxes come out green, then the above should be enough, provided it
> is set in the right place. I can confirm that bitclusive.de still
> supports TLSv1:
>
> $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de
> posttls-finger: Verified TLS connection established to
> smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with
> cipher ECDHE-RSA-AES256-SHA (256/256 bits)
>
> $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1
> bitclusive.de
> posttls-finger: Verified TLS connection established to
> smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA
> (256/256 bits)
>
> Other than test TLS connections, do you still legitimate inbound email
> in your logs (looking over a week or more of logs) delivered with TLSv1?
I have just too TLSv1 connections this month:
...
11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> perhaps prod the senders to upgrade first, before you prevent them
> from establishing TLS connections to your MTA.
internet.nl says TLS 1.1 should be phased out and criticises this.
It also critcises the key exchange paramert DH-4096 as insufficient
I just created that key and made it available with
smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
for now.
--
Regards
Andreas
Re: Disabling TLSv1
Hello,
I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at the
beginning of the year (since there were advisories that anything older
than 1.2 is considered weak and broken), and it did not end well, there
were numerous complaints from what turned out to be still supported LTS
version of Windows 8 that is supported till 2023 whose Outlooks still
uses the obsolete versions of TLS and their handshakes will fail.
--
S pozdravem,
Daniel Ryšlink
On 05-Mar-20 21:08, ratatouille wrote:
Hello!
Don't know why TLSv1 is still offered on our servers running
mail_version = 2.11.3
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
I am not sure what's wrong. What do I miss?
Other parameters I set:
smtpd_tls_CApath = /var/lib/ca-certificates/pem
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH,
EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1,
ECDHE-RSA-DES-CBC3-SHA
smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_tls_session_cache_timeout = 3600s
Regards
Andreas
Re: Disabling TLSv1
On Thu, Mar 05, 2020 at 09:08:43PM +0100, ratatouille wrote: > Don't know why TLSv1 is still offered on our servers running Probably because you're not changing the configuration in the right place. Double-check that you're configuring the correct Postfix instance (if using multiple instances) and that there are no master.cf overrides that trump the main.cf settings. > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1 It is not yet a good idea to disable TLSv1 in SMTP. But if you must degrade[1] your SMTP security for some clients to make sure that all the check boxes come out green, then the above should be enough, provided it is set in the right place. I can confirm that bitclusive.de still supports TLSv1: $ posttls-finger -c -Lsummary -p TLSv1 bitclusive.de posttls-finger: Verified TLS connection established to smtp.bitclusive.de[2a03:4000:33:430:d423:c2ff:fe3d:b540]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) $ posttls-finger -c -Lsummary -o inet_protocols=ipv4 -p TLSv1 bitclusive.de posttls-finger: Verified TLS connection established to smtp.bitclusive.de[92.60.38.182]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Other than test TLS connections, do you still legitimate inbound email in your logs (looking over a week or more of logs) delivered with TLSv1? If not, then perhaps disabling TLSv1 will be harmless, but if you do, perhaps prod the senders to upgrade first, before you prevent them from establishing TLS connections to your MTA. -- Viktor. [1] Some clients forced to send in clear text, because they don't do TLSv1.2.
