Topic: Howto check if outgoing email is sent with TLS or not? No logging?

[hanscees]

I wonder the same thing. One person here is using words like "unresponsible", "unexcusable" and "silly", implying that SME dev are unprofessional, and claiming without a proof that SME is not complying with EU's laws. On the other hand, I exposed simple facts. Verifiable facts. Yes, SME does support inbound TLS, and outbound TLS when using a smarthost. This is neither false, nor silly. Now please, stay respectful with others. Nobody has insulted you here. Only you are.

Very well, let me try to explain. The Gdpr is a new privacy law in the Eu. It compells organizations to use encryption in many cases. I think this blog explains it pretty well:

https://blog.gemalto.com/security/2016/04/25/gdpr-summary-encryption-other-measures-now-must/

If organizations use (store or send) data about persons (PI or personal information), they must take measures to project this information so other parties cannot get to that data. Part of any basic protection must be encryption.
Encryption can be used for data at rest, but also in transit; so of course it is compulsory to encrypt all data sent over internet, but also to encrypt data on your lan for instance.

Organizations that do not use PI won't have to use these measures but since even Ip-adresses are PI and lots of other stuff is too encryption in transit will be a standard measure to take in all cases.

Since fines are enormous, European organizations will use encryption in all transit scenario's.

Still, Tls is not waterproof, because of the hop-nature of the email-protocol, but not using Tls under #gdpr when you can is a risk.

Hope this helps.

[ReetP]

Very well, let me try to explain. The Gdpr is a new privacy law in the Eu. It compells organizations to use encryption in many cases. I think this blog explains it pretty well:

Yes we in the EU know full well what GPDR is.

It does NOT compel you to encrypt data - though it does compel you to report data breaches if stored data was not encrypted. In general it is much more complicated. It's primary purpose is the protection of the storage of large quantities of client data, and the ability for people to find out exactly what data is held about them (no bad thing) and said data is looked after properly. I think you are confusing that that with the transmission of say a single email to a single person who actually wants to receive said email. If that mail is hacked, how much data is lost ? That is completely different to say Google replicating millions of customers details across multiple data centres. Which they used to do in the clear if I remember correctly.

I could go on ad nauseum about it, but I digress, and I think you should really go and read a bit more first before making sweeping statements.

Quite frankly if it DID require instant encryption of every single piece of data everywhere, all the time, how many companies do you think could comply ? I very much doubt that ANY would. Not now, and not in May next year either. I am sure the forthcoming years will provide a lot of case law on the subject.

Note that you are really making a mess of your own argument about TLS in email. If you think that GPDR requires secure end to end encryption then why aren't you using the only reasonable guaranteed method with PGP instead of a system that really guarantees nothing ?

If you want encryption on disks by default on SME, if you want encrypted mail etc etc, then by all means dig in and start helping. Quite frankly this sort of topic is better discussed on the developers mailing list.

Please stop throwing up 'information' that is inaccurate, irrelevant or misguided because it potentially misleads users with less experience.

Again, I am NOT saying we shouldn't look closer at the subject. But I think we really need to understand the 'problem' and the potential benefits of 'fixing' it.

Thank you

Rgds
John

[hanscees]

Yes we in the EU know full well what GPDR is.

It does NOT compel you to encrypt data - tho

.... I think you are confusing that that with the transmission of say a single email to a single person who actually wants to receive said email. If that mail is hacked, how much data is lost ? That is completely different to say Google replicating millions of customers details across multiple data centres. Which they used to do in the clear if I remember correctly.

I could go on ad nauseum about it, but I digress, and I think you should really go and read a bit more first before making sweeping statements.
.

Note that you are really making a mess of your own argument about TLS in email. If you think that GPDR requires secure end to end encryption then why aren't you using the only reaso.

Please stop throwing up 'information' that is inaccurate, irrelevant or misguided because it potentially misleads users with less experience.

My statements are accurate, but you don't realize it yet. I know #gdpr very well, but was trying to explain to the layman that encryption is very much a #gdpr thing.

If the data is PI GDPR compells an krganization to protect it well and compells you to prove you did. How well depends on a risk analysis, and on what  measures are affordable and doable.
But regardless of that you should ALWAYS take measures that are simple to take, like using TLS in data transit.

If information is really precious you shouldnt mail it at all presumably, but use an MFTP server or other point-to-point solutions with strong authentication.
Using PGP on email is stronger than email with TLS of course, but Mftp is probably often stronger, since an adversary cannot get to your encrypted data.

However, the point is you should should both use PGP AND Tls in certain circumstances. It is not a choice between, but Tls should be an addition. PGP can protect the data in the email, but not the meta-data in many cases, from adversaries that are sniffing data.

Since Tls is better than no Tls and its cheap and easy you should always use it when sending PI. In a world where #Gdpr is the standard, all email in transit will become TLS based is my prediction.

Therefore any e-mail server should use it wnenever possible.

This is the argument I am trying to present. I am trying to do that without making it too complex.

[ReetP]

My statements are accurate, but you don't realize it yet. I know #gdpr very well, but was trying to explain to the layman that encryption is very much a #gdpr thing.

You seem to assume that we are all too dumb too know what we are talking about and I find that a little rude.

If the data is PI GDPR compells an krganization to protect it well and compells you to prove you did. How well depends on a risk analysis, and on what  measures are affordable and doable.
But regardless of that you should ALWAYS take measures that are simple to take, like using TLS in data transit.

And as I have said, it does not compel you to encrypt everything all the time as you alluded. For the benefit of other readers you really must be more careful about statements that you make.

If information is really precious you shouldnt mail it at all presumably, but use an MFTP server or other point-to-point solutions with strong authentication.
Using PGP on email is stronger than email with TLS of course, but Mftp is probably often stronger, since an adversary cannot get to your encrypted data.

None of that makes a case that TLS will automatically make everything OK. If information is precious then it is a no brainer to use secure methods, but once again, making SME send outgoing emails via TLS is NOT going to guarantee that.

However, the point is you should should both use PGP AND Tls in certain circumstances. It is not a choice between, but Tls should be an addition. PGP can protect the data in the email, but not the meta-data in many cases, from adversaries that are sniffing data.

Since Tls is better than no Tls and its cheap and easy you should always use it when sending PI.

You still ignore the fact that TLS guarantees you nothing unless all servers run it, which currently they do not, and that all clients connecting use secure protocols, which they currently do not.

The only reasonable, consistent way of guaranteeing email content gets securely from you to the recipient is using PGP. And if you don't want it sniffed at all then use a VPN where you know where the endpoints are. You could use my IPsec contribs for that if you want. Or Daniels excellent OpenVPN systems. You could of course use your own, if you had written anything.

In a world where #Gdpr is the standard, all email in transit will become TLS based is my prediction.

Since when did GPDR become a "world standard" ? You are really stretching the bounds of believe here.

I'm sure that TLS will become standard at some point in the future. But that isn't here and now. SME is not the last system to adopt it, and I doubt it will be. But as I have pointed out, the ratio for the time expended vs benefit is not good right now.

Therefore any e-mail server should use it wnenever possible.

So please go ahead and add your code to SME.

This is the argument I am trying to present. I am trying to do that without making it too complex.

For the second time in one post you assume we are dumb. Thanks.

In the meantime rather than waste any more of my time on arguing with someone who really is really wishing on a star, I'm off to do something more productive like some coding. I suggest your time would be better spent doing likewise.

Rgds
John

[Daniel B.]

there are patches for qmail that do this, and as it's been in the public domain for years, there's no impediment to distributing a patched binary package.

To reply to this specific part: yes, there are patches for qmail (netqmail) to add TLS support. We'd "only" need the qmail-remote part, not the qmail-smtpd one. That's probably the quickest path to achieve this. But it still requires work: port the patch which probably do not apply cleanly on our already patched qmail, then adapt all the required e-smith/smeserver packages to link to the certificate, provides templates for the new tls related control files, and: test, test test. There are so many ways in which it can introduce delivery problems, that I'm a bit reluctent to push this during the lifecycle of a stable SME Server.