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

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