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

[hanscees]

Hi,
I want to know if outgoing email to a specific email address/domain is being send encrypted by TLS.

In the qmail logfile I can find what messages are send
tail -n 100000 /var/log/qmail/current | tai64nlocal | egrep "2017-07-17 21:"

2017-07-17 21:33:32.317251500 info msg 653933: bytes 92302 from <test@whatever.nl> qp 16797 uid 5003
2017-07-17 21:33:32.318022500 starting delivery 1798: msg 653933 to local alias-localdelivery-@hanscees.net
2017-07-17 21:33:32.318023500 status: local 2/20 remote 0/20
2017-07-17 21:33:32.318023500 delivery 1797: success: did_1+1+0/qp_16797/
2017-07-17 21:33:32.318024500 status: local 1/20 remote 0/20
2017-07-17 21:33:32.318024500 end msg 653590
2017-07-17 21:33:32.334592500 new msg 653590
2017-07-17 21:33:32.334593500 info msg 653590: bytes 92419 from <test@whatever.nl> qp 16800 uid 400

But this is not very informative.

I want to something like this:
Authentication-Results: hanscees.net; auth=none; spf=none smtp.mailfrom=lists.redbarn.org; dkim=none
Received: from util.redbarn.org (HELO util.redbarn.org) (24.104.150.212)
 by hanscees.net (qpsmtpd/0.96) with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); Tue, 18 Jul 2017 10:21:21 +0200

Does email log this at all for outgoing email?

[Daniel B.]

Then you should check your qpsmtpd/sqpsmtpd logs. This is where emails are being submitted to your SME Server (well, there are cases where emails can be injected directly into qmail, but only from apps running on SME itself, where SSL/TLS makdes no sense)
Emails seen in sqpsmtpd logs have been submitted using SSL. For those in qpsmtpd, you need to check if STARTTLS was used.
This is only for emails from your users to your SME Server. Emails from your SME Server to a remote address are not encrypted in any way if sent directly. It might be encrypted between your SME and your smarthost (if using a smarthost, and authentication against this smarthost)

[hanscees]

Then you should check your qpsmtpd/sqpsmtpd logs. This is where emails are being submitted to your SME Server (well, there are cases where emails can be injected directly into qmail, but only from apps running on SME itself, where SSL/TLS makdes no sense)
Emails seen in sqpsmtpd logs have been submitted using SSL. For those in qpsmtpd, you need to check if STARTTLS was used.
This is only for emails from your users to your SME Server. Emails from your SME Server to a remote address are not encrypted in any way if sent directly. It might be encrypted between your SME and your smarthost (if using a smarthost, and authentication against this smarthost)

So email from SME to a remote system are never encrypted? Seriously? Can somebody verify this?

[Daniel B.]

Yes, seriously. You can check yourself if you don't trust me (run a tcpdump on port 25 and open it with wireshark). Email is insecure by definition. If you need confidentiality, then you must use end-to-end encryption (PGP/MIME or S/MIME). Even if SME supported encrypted outgoing SMTP, it would not bring a lot of security, because:

• Server to server encryption can only be oportunistic. It means it'll only protect against passive eyesdropping; not active ones because there's no way to check the remote certificate (well, there are some mechanisms like DANE which can help, but not very popular, not even sure they are standards)
• There's no way to tell the email will be encrypted all along the way to the mailbox of your recipient. Yes, you could ensure it's encrypted up to the next SMTP hop. But then, you have no control over this. The email might be routed through several other servers before it reaches your recipient, and this can (and often will) be in cleartext

So again, if security matters, there's only one solution: end-to-end encryption, so either PGP/MIME or S/MIME (with all the constraints those solutions come with)

[hanscees]

Yes, seriously. You can check yourself if you don't trust me (run a tcpdump on port 25 and open it with wireshark). Email is insecure by definition. If you need confidentiality, then you must use end-to-end encryption (PGP/MIME or S/MIME). Even if SME supported encrypted outgoing SMTP, it would not bring a lot of security, because:

• Server to server encryption can only be oportunistic. It means it'll only protect against passive eyesdropping; not active ones because there's no way to check the remote certificate (well, there are some mechanisms like DANE which can help, but not very popular, not even sure they are standards)
• There's no way to tell the email will be encrypted all along the way to the mailbox of your recipient. Yes, you could ensure it's encrypted up to the next SMTP hop. But then, you have no control over this. The email might be routed through several other servers before it reaches your recipient, and this can (and often will) be in cleartext

So again, if security matters, there's only one solution: end-to-end encryption, so either PGP/MIME or S/MIME (with all the constraints those solutions come with)

I indeed did a tcpdump and saw port 25 traffic, thats why I asked.
Technically you are right that email is never fully secure. In my work environment we use an Mftp server, that works something like we-transfer.

However, email with TLS is less insecure than without TLS. So at home I will set up a postfix forwarder anyway.
As a professional CISM I would not accept any email-server that does not user TLS if it can. Sorry.


 



 

[Daniel B.]

There's a NFR for this (can't remember the bug number right now). But, IMHO, using TLS for sending emails is more about marketing BS than about security. For the reasons I already explained: even if you use TLS for the outbound, you can't guarantee anything after the first hop (and because of the oportunistic encryption only). So, yes, it's a bit better. But just marginaly better

[ReetP]

However, email with TLS is less insecure than without TLS. So at home I will set up a postfix forwarder anyway.
As a professional CISM I would not accept any email-server that does not user TLS if it can. Sorry.

As Dan already said that is totally and utterly irrelevant as you cannot control which servers your mail goes through.

So it may go:

SME -> ISP -> a.n.other -> and.a.n.other -> Destination

There is no way you can control ANYTHING beyond the first hop. After that it is anyone's guess. So you may be as professional as you like but it will make absolutely zero difference unless you can absolutely guarantee the connection directly end to end.

You have two options.

1. Use encrypted mail
2. Change the RFC for SMTP services to add TLS to EVERY SMTP server on the planet.


Setting up a postfix forwarder is just a complete and utter waste of your valuable time unless you force it to connect directly to the destination SMTP server (which could be a forward facing relay/proxy/whatever with plain SMTP connected servers behind, which you cannot tell)

I'm sorry but you are chasing rainbows here.

B. Rgds
John

[hanscees]

As Dan already said that is totally and utterly irrelevant as you cannot control which servers your mail goes through.

So it may go:

SME -> ISP -> a.n.other -> and.a.n.other -> Destination

There is no way you can control ANYTHING beyond the first hop. After that it is anyone's guess. So you may be as professional as you like but it will make absolutely zero difference unless you can absolutely guarantee the connection directly end to end.

I doubt if my answer will persuade such an almost religious respons. But with dnssec, free TLS certificates and lots of other methods we are getting to a situation where your mailserver knows what the authoritive mailserver of another organization is. If the sending email-server delivers directly and encrypted to that server by European law the other side is now responsible for security and privacy.
I am not saying encrypting the payload isn't better, cause it is obviously, only few people do that.

But since inter-mail-server security is improving my opinion is that to send email willingly without TLS, even if TLS it is accepted by the receiving email server is unresponsible and unexcusable

I am sure you disagree, but please lets respect different views.

[Daniel B.]

But with dnssec, free TLS certificates and lots of other methods we are getting to a situation where your mailserver knows what the authoritive mailserver of another organization is.

Unlike https, there are some more complications with SMTP, where my compagny.com can have an MX entry like mail.mycompagny.com which points in fact on an ovh.com SMTP server. How do you, as a sender, check this ? You'll connect on mail.mycompagny.com which will present a certificate with something.ovh.com CN. And you have no way to tell if this is OK or not. That's why it'll only be oportunistic.

my opinion is that to send email willingly without TLS

It's not willingly. SME's MTA (qmail) does not support outbound TLS natively. It's just that no one yet implemented it. And no one yet implemented it because no one with the required skills, time, resources think it worths it (until now ?)

even if TLS it is accepted by the receiving email server is unresponsible and unexcusable

You're welcome to implement, or sponsor the feature

[ReetP]

I doubt if my answer will persuade such an almost religious response.

It's not religious (I don't do religion!!). I'm not saying it is a good thing. It is just based on the current state of affairs in the world today. We don't want users thinking that if it was added to SME it would be some kind of magic fix and the the entire email chain would be secure.

Until ALL servers offer end to end encryption you are always going to be fighting an uphill battle. Even then, you don't know how a client connects to a server to retrieve mail...... so the receiving server is all secured up,  but still allows people to collect mail with say IMAP or POP (over which you have no control)? The whole chain is broken with just one weak link. Daniel has also provided you with some other points.

In reality the entire mail transport system should probably be re thought and re designed from the ground up taking into account todays security requirements.

I am sure you disagree, but please lets respect different views.

I respect your view, but your argument is flawed due to the systems currently in place around the world.

I'm not saying for one moment that this shouldn't be changed. I am just pointing out the reality of the current situation, as has Daniel.

The only real way, here and now, to guarantee mails are secure end to end is with PGP (and even that assumes the spooks can't crack it).

That doesn't mean there isn't room for improvement, but there is limited manpower and a long list of jobs to do. You can of course help by working on some code.

The bug is here I beleive:

https://bugs.contribs.org/show_bug.cgi?id=9349

B. Rgds
John

[Knuddi]

I agree with most, but if you check how many hops you will have with your normal business partners, then its most often 0 or 1. 0 (zero - direct) because many uses Gmail or Office365 or have local AV/Antispam (such as a SME server) or 1 hop if you use an external mail filtering service. Yes, I agree some uses their ISP a an extra hub, but that can be eliminated with a professional ISP (subscription). So as much as I agree with the fact that you cannot 100% guarantee and control, then sending with TLS/SSL enabled will in most cases result in an end-to-end encryption I would think.

So, obviously the SME should be enhanced to enable TLS in qmail and there is a NFR somewhere for that.

[hanscees]

The bug is here I beleive:

https://bugs.contribs.org/show_bug.cgi?id=9349

B. Rgds
John

The bug sums it up nicely.

One could add a patch on qmail, or replace the qmail code with postfix as the fix suggests. Since what is qmail still doing if you use different packages for both incoming and outgoing email.

However with the least trouble you could:

• keep running qmail
• let it sent its email to postfix on localhost on another port
• let postfix send email, using all its sophisticated TLS features

I did just this, only used another host to serve postfix as a smarthost (only used to sent email to internet).

Links on TLS and how dane work can be found here: http://www.postfix.org/TLS_README.html#client_tls_levels

I use a simple transport table to sent all email for internal domains back to SME server as the internal server:

vi /etc/postfix/transport
#relay all email for domain to internal mailserver []
hanscees.com smtp:[192.168.0.1]
.hanscees.com smtp:[192.168.0.1]
* smtp

logging on outgoing smtp is something like this:

### logging example

#Jul 20 20:29:09 core postfix/qmgr[26579]: BF14F201D3: from=<root@example.net>, size=297, nrcpt=1 (queue active)
Jul 20 20:29:10 core postfix/smtp[26610]: Untrusted TLS connection established to bak.ab-groep.nl[212.135.11.120]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)



then the main postfix config

############################## main.cf
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
delay_warning_time = 4h

readme_directory = no

# TLS parameters for receiving email
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# use TLS when sending email
smtp_tls_security_level = may
smtp_tls_loglevel = 1


# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination =
local_recipient_maps =
Local_transport = eror:local mail delivery is disabled
relayhost =
mynetworks = 127.0.0.0/8 192.168.0.0/24
mailbox_size_limit = 0
recipient_delimiter =
inet_interfaces = all
myorigin = /etc/mailname
inet_protocols = ipv4
transport_maps = hash:/etc/postfix/transport

[CharlieBrady]

So email from SME to a remote system are never encrypted?

Not quite. If you use a smarthost which requires authentication, then it probably requires TLS as well. So in that case, all outgoing email will be encrypted for the first hop. Whether it is encrypted from the ISP's mail server to the destination is beyond your control. It is also beyond your ISP's control - many destinations don't accept encrypted connections.

If you don't use a smarthost, qmail on SME server always uses port 25, and doesn't use TLS. This has *always* been the case.

[hanscees]

Not quite. If you use a smarthost which requires authentication, then it probably requires TLS as well. So in that case, all outgoing email will be encrypted for the first hop. Whether it is encrypted from the ISP's mail server to the destination is beyond your control. It is also beyond your ISP's control - many destinations don't accept encrypted connections.

If you don't use a smarthost, qmail on SME server always uses port 25, and doesn't use TLS. This has *always* been the case.

Thank you Charlie.
My post here above shows howto set up exactly such a smarthost with postfix that sends with TLS when possible.
My argument is that SME would improve in safety for its users if such a smarthost would be incorporated in the server. Please read the posts above for the argumentation.

While setting up the smarthost for outgoing smtp with postfix it turned out to be not that hard.
If it would help I could write a design document how that would fit into SME. I am not good enough as a programmer to set up and maintain a package though.

regards

[guest22]

While setting up the smarthost for outgoing smtp with postfix it turned out to be not that hard.
If it would help I could write a design document how that would fit into SME.

That would be helpful. You can use the wiki for that if you wish. Thanks!

[Daniel B.]

My post here above shows howto set up exactly such a smarthost with postfix that sends with TLS when possible.

Charlie was talking about the already existing smarthost support, using smtp-auth-proxy

[hanscees]

That would be helpful. You can use the wiki for that if you wish. Thanks!

In what part would a design-document fit?

[guest22]

There is a 'mail' category: https://wiki.contribs.org/Category:Mail

[DanB35]

I have trouble with the thought process that goes, "we can't make it perfect, so we shouldn't even try."  Yes, encryption enroute for email has a number of challenges, and it's going to be opportunistic at best.  So is it better that we encrypt some traffic, or none at all?  It seems obvious to me that "some" is better than "none," and we wouldn't need to bring yet another MTA into the mix to make it happen--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.

I can appreciate that the juice might not be worth the squeeze--that our limited development resources might be better spent elsewhere.  But that doesn't sound like what's being said here.

[Daniel B.]

I can appreciate that the juice might not be worth the squeeze--that our limited development resources might be better spent elsewhere.  But that doesn't sound like what's being said here.

I've explained my POV already. Yes, it'd be better, but only marginally. And the advantages don't worth the effort IMHO (I mean, the real, technical advantages, not the marketing BS). Replacing qmail with postfix (and I really mean replace, not complement) is something we should do ultimately, not only for outbound TLS. But it's far from a trivial task

[ReetP]

This was my point.

I'm not saying it can't or shouldn't be done but.....

1. It still does not guarantee an end to end encrypted solution
2. Cost vs benefit... very limited hands reduce the choices available. This would be a lot of work and yet produce a system that still doesn't gurantee anything.

There are dozens of things users would like to see in SME, but not enough bodies to do them all, so hard choices have to be taken.

Regrettably people are often happy to leap in and criticise the distro for lacking features, but rarely leap in and contribute some code. Ever it was thus.

If someone feels this really should be in SME before other things then as Dan pointed out, provide some code or sponsor the work.

[CharlieBrady]

My post here above shows howto set up exactly such a smarthost with postfix that sends with TLS when possible.

Note that that guarantees you nothing. Anyone who is able to create a MiTM attack can downgrade any connection to plaintext.

[hanscees]

This was my point.

I'm not saying it can't or shouldn't be done but.....

1. It still does not guarantee an end to end encrypted solution
2. Cost vs benefit... very limited hands reduce the choices available. This would be a lot of work and yet produce a system that still doesn't gurantee anything.

There are dozens of things users would like to see in SME, but not enough bodies to do them all, so hard choices have to be taken.

Regrettably people are often happy to leap in and criticise the distro for lacking features, but rarely leap in and contribute some code. Ever it was thus.

If someone feels this really should be in SME before other things then as Dan pointed out, provide some code or sponsor the work.

I cannot judge what other stuff this feature competes with, thats really upto you.
But I do object to the line of thought that this does not guarantee anything. It does not guarantee protection against mitm attack: that is certainly true.

But it does guarantee that more and more email-delivery sent from an SME server cannot trivially be intercepted and scanned by numerous intermediate ip-hosts that are in between the origin server and receiving email-server. The encryption of all internet-traffic is an important task.
Therefore this change add non-trivially to the privacy protection of users of the server.

Now you may find privacy important or not, but please do not downplay the privacy factor.
Privacy is not the same as security.

For instance my server is in the netherlands. All mail to Gmail is scanned by at least NSA and UK secret service. When its encrypted, they cannot routinely read it. When its not encrypted they can. Surely they can mitm my server, but in practice they wont do that with most servers.

[ReetP]

I cannot judge what other stuff this feature competes with, thats really upto you.

Neither is it up to me. If you feel it is important then do something. Try to help fix it ? You have the bug reference. Please add to it.

But I do object to the line of thought that this does not guarantee anything. It does not guarantee protection against mitm attack: that is certainly true.

And that effectively stops your argument in its tracks. It will currently guarantee nothing. It may help. It may make encrypted connections to some servers, and equally it may not.

But it does guarantee that more and more email-delivery sent from an SME server cannot trivially be intercepted and scanned by numerous intermediate ip-hosts that are in between the origin server and receiving email-server. The encryption of all internet-traffic is an important task.

Only if you can control the entire chain between your server and the receiving server.

And currently you cannot do that. As I mentioned before, you also make the assumption that the receiving server is actually the final link in the chain. There may be other private servers behind the public server that you can't see.

Yes it MAY help. No guarantees.

Therefore this change add non-trivially to the privacy protection of users of the server.

I never said it was a non trivial issue.

Now you may find privacy important or not, but please do not downplay the privacy factor.

I find it very important, and hence trying to ensure other users reading this don't think they would have a water tight solution. This about clarity, nor personal opinion.

Privacy is not the same as security.

They tend to go hand in hand.....

For instance my server is in the netherlands. All mail to Gmail is scanned by at least NSA and UK secret service. When its encrypted, they cannot routinely read it. When its not encrypted they can. Surely they can mitm my server, but in practice they wont do that with most servers.

So you worry about transmitting mail to Gmail? And don't worry that a) it's read by Google and b) the spooks can get to it if they want to anyway (I would imagine it's easier to read it IN Google than hacking an encrypted connection...... I believe with the rise in encryption that attacking endpoints is more important to them these days.)

The only system to reasonably guarantee encrypted communications between two people is with PGP. And then you have to assume the spooks can't control you phone.... or Google, or Apple or.....

Yes, it may well be nice to add encrypted mail transport to SME, and I too wish the world would get a move on with this. However with the state of play in the world at the minute, adding it to SME is not going to cure every connection. It will be a hit and miss affair depending on intermediate servers and the receiving server.

Currently that is a lot of work for not a lot of guarantees. Security is only as good as the weakest link, and other users need to understand this.

Note I am extremely conscious of both privacy and security. I worked with Dan Brown to integrate Letsencrypt into SME server. I have built RPMS for IPsec and L2TPD/IPsec vpn to secure my own communications.

My point is that this may help. It may be a nice add on. But it is not currently the panacea that you think it is.

[Stefano]

John, I'd love, really, to have a "one billion likes" button here, right now
I agree with you 120%

[hanscees]

I will write a change-document as requested further above. I will add that to a bugnote as well.

I do not think tls on outgoing email is a panacee. I do think the ability to use Tls on outgoing or incomjng email is a minimal requirement for any email-server to be compliant to the European #gdpr. At the moment I could therefore not recommend Sme-server to any European organization.

The change I will describe is not big and a first step toward incorporating postfix, which is not a bad idea anyway.

You can find some of my publications on security and privacy here if you like:
https://www.hanscees.com/pubs.html

[Daniel B.]

I do think the ability to use Tls on outgoing or incomjng email is a minimal requirement for any email-server to be compliant to the European #gdpr. At the moment I could therefore not recommend Sme-server to any European organization.

SME server does support TLS on inbound, and TLS on outbound when using a smarthost, all of this out of the box. And a lot of attention is taken on having a good implementation (regarding TLS handshake version, enabled ciphers etc.). So I'm pretty sure it has much more than the minimal requirement to be compliant with the GDPR. If you have links which proves otherwise, please share it with us.

[hanscees]

SME server does support TLS on outbound when using a smarthost,

This is silly. Our car has breaks if you use the breaks of another car. I don't know why the reactions here are so extreme: it is clear you lack a minimal feature. Fix it or be outdated.
This was my last post on this issue.

[Stefano]

This is not silly..
In any case, if you really need this features, help US (all of us) with code or money..
You said this is not difficult to achieve and we'd move to postfix
Said that it won't change much the situation, 'cause you have no control on what's going outside your lan, please provide some code, start helping US
Everything seems easy until you don't put your hands in the mud...

[Daniel B.]

I don't know why the reactions here are so extreme

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.

[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.