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!