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
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:
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
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
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
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
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.
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
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
> 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
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
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
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
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
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
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
It appears that Sidsel Jensen via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hi MailOps
>
>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
Am 04.08.22 um 00:03 schrieb Bill Cole via mailop:
A MTA that can't get STARTTLS to work will retry (or even continue in the same
session) without encryption, as it SHOULD per the standard.
Erm, no, it doesn't. And that's not how RFC 3207 defines things, anyway:
After receiving a 220
On 8/3/22 6:51 PM, Jarland Donnell via mailop wrote:
I cannot believe that I am in a mailing list full of professional
admins that is universally speaking up on this topic to ONLY state
that there is zero merit to a best security practice of disallowing
insecure SSL protocols and ciphers for
A generic "confirmation of a secure connection" is not a part of any
MTA-MTA interaction.
I mean if our standard is so high that it needs to be a flashing neon
sign then neither does a web browser or any other piece of software. I
cannot believe that I am in a mailing list full of
Moin,
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.
[…] but have you also disabled it for MTA to MTA
On 2022/08/03 14:01, Jarland Donnell via mailop wrote:
> > The MTA-MTA encryption is weak at best: because the client doesn't
> > (can't, actually) verify that the certificate is appropriate for that
> > MTA, any MITM attack is easily accomplished. End users get virtually no
> > indication that
On 2022-08-03 at 17:32:56 UTC-0400 (Wed, 03 Aug 2022 16:32:56 -0500)
Jarland Donnell via mailop
is rumored to have said:
Firefox does not speak MTA, so you are talking about a completely
different problem. MTA is oportunistic TLS, web is required TLS.
Are equivalencies a bad thing though?
On 2022-08-03 at 14:33:36 UTC-0400 (Wed, 03 Aug 2022 13:33:36 -0500)
Jarland Donnell via mailop
is rumored to have said:
Genuine question though: What differentiates a client from a remote
SMTP server besides emotional attachment?
See RFC821. It uses "receiver-SMTP" and "sender-SMTP" rather
Why are there any efforts to remove old TLS versions from every major
software application and operating system? Are all of these security
experts and corporations just playing a game with TLS versions, or is
there perhaps something to this security practice?
Because browsers won't fall back
Firefox does not speak MTA, so you are talking about a completely
different problem. MTA is oportunistic TLS, web is required TLS.
Are equivalencies a bad thing though? I'm talking about a general
acceptance of the idea that a user should not be given a false sense of
security by being
On Wed, Aug 03, 2022 at 03:05:43PM -0500, Jarland Donnell via mailop wrote:
> > You clearly see what TLS version and what ciphers were used. So you know
> > if
> > it was "secure" in your opinion or not.
> I don't understand why Firefox did this:
>
Dňa 3. augusta 2022 19:46:06 UTC používateľ Jarland Donnell via mailop
napísal:
>You have SSL because you want to not only know that the server you are
>connecting to is who they say they are, but also to secure the packets as they
>transmit to your ISP, to their upstream, to the next
Dnia 3.08.2022 o godz. 14:46:06 Jarland Donnell via mailop pisze:
> > But you must take into account the difference between web and e-mail.
> > With
> > HTTPS, the connection is directly between your browser and the server,
> > so if
> > it's secure, it's secure (as long as you trust the server).
On 03/08/2022 21:05, Jarland Donnell via mailop wrote:
> I don't understand why Firefox did this:
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
>
> Clients can clearly click the lock, check the details, and see which SSL
> version they're using. So if the site says it's
On Wed, Aug 03, 2022 at 02:46:06PM -0500, Jarland Donnell via mailop wrote:
> You have SSL because you want to not only know that the server you are
> connecting to is who they say they are, but also to secure the packets as
> they transmit to your ISP, to their upstream, to the next upstream,
On 8/3/22 12:33 PM, Jarland Donnell via mailop wrote:
Else, why are there even any articles about old versions being insecure?
Why are there any efforts to remove old TLS versions from every major
software application and operating system?
There is nothing wrong with striving for better.
But
On 8/3/22 1:46 PM, Jarland Donnell via mailop wrote:
This leans on faulty logic. If the browser is on the screen of a laptop
plugged directly into the server, sitting in the middle of that place
that sounds suspiciously like an airport, then this would be true. But
then, if you trust the
You clearly see what TLS version and what ciphers were used. So you
know if
it was "secure" in your opinion or not.
I don't understand why Firefox did this:
https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
Clients can clearly click the lock, check the details, and see which
On 8/3/22 1:26 PM, Jaroslaw Rafa via mailop wrote:
But you must take into account the difference between web and
e-mail. With HTTPS, the connection is directly between your browser
and the server, so if it's secure, it's secure (as long as you trust
the server). Period.
Sadly, I don't think
On 8/3/22 12:14 PM, Jarland Donnell via mailop wrote:
Roger that. So this:
;-)
It's about proper documentation, expectation, and communication. The
most secure line is the actual secure line,
I can't agree.
I suspect we can agree that security is not binary / black & white.
Stock DES was
But you must take into account the difference between web and e-mail.
With
HTTPS, the connection is directly between your browser and the server,
so if
it's secure, it's secure (as long as you trust the server). Period.
This leans on faulty logic. If the browser is on the screen of a laptop
Dnia 3.08.2022 o godz. 14:28:43 Jarland Donnell via mailop pisze:
> > There's nothing that requires you to log a TLS 1.0/1.1 connection as
> > being secure. You could choose to log it as if it were plaintext. It's
> > likely to be logged with the protocol and cipher information.
>
> What you log
On Wed, 3 Aug 2022 13:34:02 +0200 (CEST), Sidsel Jensen via mailop
wrote:
>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.
Our analysis states that the most
There's nothing that requires you to log a TLS 1.0/1.1 connection as
being secure. You could choose to log it as if it were plaintext. It's
likely to be logged with the protocol and cipher information.
What you log it as isn't as important as what the other party logs it
as. Sure if it were
Dnia 3.08.2022 o godz. 13:14:07 Jarland Donnell via mailop pisze:
>
> It's about proper documentation, expectation, and communication. The most
> secure line is the actual secure line, the least secure line is the one that
> says "I am secure" and isn't. This might sound confusing because most
On 03/08/2022 20:01, Jarland Donnell via mailop wrote:
> End users get headers which is admittedly not useful to most, but the
> "lock" on Gmail is at least fast becoming an accepted thing, seeing more
> email clients latch onto that is a bit slow but is happening. Of course,
> it should only
On 03/08/2022 16:46, Jarland Donnell via mailop wrote:
> It's a pretty big and well respected security practice to consider plain
> text to be more secure than insecure SSL for one reason: A plain text
> connection isn't logged or reported as a secure connection. Both being
There's nothing
The MTA-MTA encryption is weak at best: because the client doesn't
(can't, actually) verify that the certificate is appropriate for that
MTA, any MITM attack is easily accomplished. End users get virtually
no indication that the message was or wasn't encrypted in transit, and
there is no
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 this currently?
I don't really see the point, unless
Genuine question though: What differentiates a client from a remote SMTP
server besides emotional attachment?
A remote SMTP server should not be told "This is a secure line" when it
isn't, in just the same way and for the same reasons, that a client
shouldn't be told "This is a secure
On 8/3/22 12:11 PM, Andrew C Aitchison via mailop wrote:
What you mean by "actual security differences" may be significant.
I figured that there were things that I wasn't aware of. Hence playing
the part of the fool to learn.
IIUC the "No STARTTLS" people have found that, when connecting a
Roger that. So this:
Specifically "plain text to be more secure than insecure SSL".
It's about proper documentation, expectation, and communication. The
most secure line is the actual secure line, the least secure line is the
one that says "I am secure" and isn't. This might sound confusing
On 2022-08-03 at 13:37:56 UTC-0400 (Wed, 03 Aug 2022 12:37:56 -0500)
Jarland Donnell via mailop
is rumored to have said:
>> If you must divulge your SSN over the phone (for reasons) do you just
> blurt it out at normal volume indifferent to who is around? Or do you
> walk to a secluded corner
On Wed, 3 Aug 2022, Grant Taylor via mailop wrote:
On 8/3/22 6:26 AM, Taavi Eomäe via mailop wrote:
Lastly, RFC8314 (re)defines port 465 as implicit TLS SMTP submission port.
Implicit TLS is considered a significantly better approach than upgrading
connections. Do you support that?
There
On 8/3/22 11:34 AM, Jarland Donnell via mailop wrote:
I mean, do you honestly want to admit publicly that you don't understand
why it's a good security practice to disable insecure SSL protocols and
ciphers? I shouldn't even have to point to that, you should have to
already know that to be
If you must divulge your SSN over the phone (for reasons) do you just
blurt it out at normal volume indifferent to who is around? Or do you
walk to a secluded corner of the room and cup your hand around the
mouth piece? Even questionable security is better than no security in
many cases.
No,
I mean, do you honestly want to admit publicly that you don't understand
why it's a good security practice to disable insecure SSL protocols and
ciphers? I shouldn't even have to point to that, you should have to
already know that to be given root to anything.
On 2022-08-03 12:03, Grant
On Wed, Aug 3, 2022 at 10:07 AM Grant Taylor via mailop
wrote:
> On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote:
> > It's a pretty big and well respected security practice to consider plain
> > text to be more secure than insecure SSL for one reason: A plain text
> > connection isn't logged
On 8/3/22 6:26 AM, Taavi Eomäe via mailop wrote:
Lastly, RFC8314 (re)defines port 465 as implicit TLS SMTP submission
port. Implicit TLS is considered a significantly better approach than
upgrading connections. Do you support that?
There are times that I question the actual security
On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote:
It's a pretty big and well respected security practice to consider plain
text to be more secure than insecure SSL for one reason: A plain text
connection isn't logged or reported as a secure connection.
What‽‽‽
Please elaborate. Please
Disabling support for less secure transport encryption protocols
doesn't increase security if the senders can then switch to unencrypted
transport as a fallback.
It's a pretty big and well respected security practice to consider plain
text to be more secure than insecure SSL for one reason: A
Ahoj,
Dňa Wed, 3 Aug 2022 13:34:02 +0200 (CEST) Sidsel Jensen via mailop
napísal:
> Hi MailOps
>
> 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
On Wed, 3 Aug 2022, Sidsel Jensen via mailop wrote:
Hi MailOps
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
Heho,
We did some measurements on this recently, see:
https://www.usenix.org/system/files/atc22-holzbauer.pdf
At the moment, I’d say that you still lose _some_ destinations (and delivering
MTAs) by forcing TLS (~10% of smaller providers). This is _any_ TLS; Numbers
for disabling 1.0/1.1
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.
And what about PLAIN - do you still allow that as the fallback option
or are you also considering disabling
My main question would be: what do you hope to gain?
There are some legit senders who still use non-encrypted mail. And as long as
we don't want to take on the tedious task of educating those senders or
convincing our users that they don't want to get mail from those senders, we
need to allow
62 matches
Mail list logo
