Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 3:35 PM, Slavko via mailop wrote: Yes, but you miss important part: "..., because i cannot believe, that i will receive what you send me." I'm not finding what you're quoting. Please elaborate or re-quote. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

You could also allow the TLS connection and then fail some percentage of mail attempts after that with a 5xx message to tell your admin to upgrade their encryption strength. Failing the TLS negotiation typically has really terrible debuggability as the other thread about SHA1 on Gmail speaks to.

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Moin On Thu, Aug 04, 2022 at 12:51:29AM +0100, Stuart Henderson via mailop wrote: > I think when acting as SMTP-over-TLS clients, most MTAs out there are > not checking the server's certificate in any really meaningful way; they > can usually be configured to do so but, last time I looked, there

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 3.08.2022 o godz. 19:51:24 Jarland Donnell via mailop pisze: > Either allowing an end user to negotiate a secure connection, to which their > software absolutely acknowledges it as a secure connection, is either sane > or it isn't. Ignore the protocol. Ignore the software. Either it's sane

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 3 August 2022 23:43:36 Taavi Eomäe via mailop You can't consider it a lie if nobody is asking the question in the first place. Gmail might show when an email was delivered in plaintext as insecure it does not display transport-encrypted emails as secure. What displays transport encryption

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

The (very important) thing is that NO email can be considered "secure" unless it is end-to-end encrypted (eg PGP), without any third party service knowing the encryption key, or you personally know and trust all the mail administrators of all the mail servers involved. Exactly the point I

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Am 03.08.22 um 13:34 schrieb Sidsel Jensen via mailop: We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for MTA to MTA communication, and based on the numbers we've seen so far, it doesn't look that far fetched. What's the common consensus in the mail community about

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dňa 3. augusta 2022 22:03:49 UTC používateľ Bill Cole via mailop napísal: >> A remote SMTP server should not be told "This is a secure line" when it >> isn't, > >And it never is. Nothing ever says "This is a secure line" in TLS. The 2 >participants negotiate a specific set of security

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

> Am 03.08.2022 um 13:48 schrieb Sidsel Jensen via mailop : > > We were having a discussion on the possibility to disable TLS 1.0 and 1.1 > for MTA to MTA communication, and based on the numbers we've seen so far, it > doesn't look that far fetched. As long as the MTA in question supports

[mailop] Google still using SHA1 (and forcing it)?

I ran into an issue at $DAYJOB where we had a hard-coded TLS version and ciphersuite set connecting to Google (specifically aspmx.l.google.com). The problem turned out to be a library upgrade had disabled SHA1, so the TLS hello handshake failed. Here's an example to reproduce it with gnutls-cli:

[mailop] Looking for a Yahoo/SBC/AOL/etc. Contact

Is anyone on here from the Yahoo! admin group? One of our customers has a relatively new (7 months) domain/rebrand and it seems to be getting accepted then bounced with code “PH01” for almost every message. It isn’t a very large volume domain so I would imagine it is related to some kind of

Re: [mailop] Google still using SHA1 (and forcing it)?

Dňa 4. augusta 2022 15:12:27 UTC používateľ Chris Adams via mailop napísal: > >| TLSv1.2: >| ciphers: >| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A >| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A >| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) -

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dnia 4.08.2022 o godz. 12:51:21 Gellner, Oliver via mailop pisze: > > A TLS encrypted SMTP connection protects against eavesdropping or altering > of messages through MITM attacks, which can be either passive or active: No. As long as certificates are not checked (and on MTA-to-MTA connections

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 2:28 AM, Bastian Blank via mailop wrote: And even if you had verifiable certificates: which ID would you use to verify it? I would naively use the name that you are connecting to. E.g. my MTA is connecting to the FQDN in the MX record or in a B2B configuration. The name of the MX

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On Wed, 3 Aug 2022, Hans-Martin Mosner via mailop wrote: Disabling support for less secure transport encryption protocols doesn't increase security if the senders can then switch to unencrypted transport as a fallback. We seem to be assuming that this is about protecting the current message.

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 12:25 AM, Paul Smith via mailop wrote: Attacks against TLS1.0 work using HTTP. I am not aware of any viable attack method which can be made using SMTP I do think it behooves people to learn from attack vectors of other protocols (e.g. HTTP) to make sure that main protocol of focus

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 2:24 AM, Taavi Eomäe via mailop wrote: Nobody (and rightfully so) displays transport encryption as secure, which invalidates the original premise of someone being lied to in the first place. I question the veracity of that. Gmail has a "security" line in the drop down which shows

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 3:38 AM, Slavko via mailop wrote: In SMTP (the historically) the autentification is missing, thus MTA are possible target of MtM attack, but that is only because MTA often doesn't do it, not because it is useless or impossible. Eg. recent Debian enables certificate verification by

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

One of the things I find interesting here is that the question is whether to disable the protocol version. We’re not limited to just enable/disable for those versions to get the attention of the sender (assuming they’d even notice if they were going clear-text). A receiver could also impact

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Like others who have commented, we believe weak encryption is worse than no encryption, so we have disabled TLSv1 and TLSv1.1 everywhere in our email systems, allowing only TLSv1.2 and TLSv1.3. Best regards to all, Mark _ L.

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

It appears that Brotman, Alex via mailop said: >-=-=-=-=-=- >-=-=-=-=-=- >One of the things I find interesting here is that the question is whether to >disable the protocol version. >We’re not limited to just enable/disable for those versions to get the >attention of the sender (assuming

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 1:10 PM, L. Mark Stone via mailop wrote: Like others who have commented, we believe weak encryption is worse than no encryption, so we have disabled TLSv1 and TLSv1.1 everywhere in our email systems, allowing only TLSv1.2 and TLSv1.3. I do not understand why people think / believe

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Gmail has a "security" line in the drop down which shows more information about the sender, recipients, etc.  I have many messages in a mailbox that state:    security:  Standard encryption (TLS) Learn more With a padlock icon in front of Standard and Learn more being a link. So there is

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

On 8/4/22 11:03 AM, Taavi Eomäe via mailop wrote: You're correct. My perspective on the UI might be different because of how S/MIME encrypted (or signed) letters look like in Gmail. I see a white check mark in a green circle for S/MIME signed messages below the sender's name near the from:

Re: [mailop] Google still using SHA1 (and forcing it)?

Once upon a time, Lukas Tribus said: > No, you didn't just disable SHA1. You disabled all MACs except SHA256 > and SHA384, including the crucial AEAD MAC for modern GCM ciphers. Ahh, my mistake, sorry. The code in question is actually Java and sets a list of ciphers, which both openssl s_client

Re: [mailop] [E] Looking for a Yahoo/SBC/AOL/etc. Contact

Please contact me off list. thanks! *Lili Crowley* she/her Postmaster On Thu, Aug 4, 2022 at 12:52 PM Rob Heilman via mailop wrote: > Is anyone on here from the Yahoo! admin group? One of our customers has a > relatively new (7 months) domain/rebrand and it

Re: [mailop] Google still using SHA1 (and forcing it)?

On Thu, 4 Aug 2022 at 17:12, Chris Adams via mailop wrote: > > I ran into an issue at $DAYJOB where we had a hard-coded TLS version and > ciphersuite set connecting to Google (specifically aspmx.l.google.com). > The problem turned out to be a library upgrade had disabled SHA1, so the > TLS hello

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

It appears that Bastian Blank via mailop said: >MTA-STS is supposed to fix that, by providing a secure way to translate >from domain to MX via a medium break. > >So is DANE, which requires DNSSEC on the whole thing and translates from >domain -> MX -> key via DNSSEC validated DNS. I do both on

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

Dňa 4. augusta 2022 19:47:32 UTC používateľ Grant Taylor via mailop napísal: >This seems to me like you are saying "if you can't meet our encryption >standards, then you don't get to use any encryption at all". Yes, but you miss important part: "..., because i cannot believe, that i will