16
Force encryption on TLS
Idea shared by Charles - 8/13/2014 at 7:48 AM
Under Consideration
Hello
 
just read this:
https://www.agwa.name/blog/post/starttls_considered_harmful
 
Is there any way in smartermail to force TLS encryption (i.e. not to accept any unencrypted connection on an SMTP TLS port) for both incoming and outgoing connections?
 
Otherwise I am tempted to only have an SSL port open but it's a shame to downgrade to an older, less secure protocole to make up for the lack of such an option.
 
Charles
 
 

30 Replies

Reply to Thread
0
I'm also wondering this:
 
Is there away to force send and receive on SSL or TLS for SM 12x,  This would essentially stop traffic to or from an unsure email server.
J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273
0
Well, if you only open an SSL port, I presume the connection has to be crypted, so it would always be secure. The problem is that it is an older protocol and wikipedia says it's not secure anymore.
 
One interesting comment on the article (I think on hacker news) is that most smtp agents don't bother checking the validity of the certificate, so that undermines a little bit the value of encryption. But it can't be worse than having emails going through unencrypted.
0
Actually I would be also curious to know if the smartermail smtp client checks the validity of certificates on outgoing traffic.
2
Employee Replied
Employee Post
At this time it is currently not possible to force SmarterMail to only accept SMTP connections that specify STARTTLS. 
 
We do not recommended changing your SMTP port running on 25 to SSL instead of TLS as this will break communications to your server from other MTA's that follow the RFC standard for SMTP as most mail servers will not be able to establish a connection to your mail server unless directly instructed to do so over your desired encryption method. 
 
We have discussed adding the ability to reject connections that do not first pass the STARTTLS command to SmarterMail as this would benefit mail admin's that must comply with certain security and encryption policies. This feature will likely make it's way into a future version of SmarterMail, as a result I've marked this as an Idea instead of a question for further review by our developers.
 
I hope this helps.
0
Employee Replied
Employee Post
This is possible.

What you will need to do is configure your standard SMTP Port (25) to use SSL instead of None or TLS. This will then require the e-mail clients and servers connecting to your SmarterMail installation over port 25 to specify SSL as the connection method. There is currently not a way to force TLS encryption upon the connection handshake within SmarterMail, enabling a TLS port makes it so that the StartTLS command must first be passed in order for the encryption to take place.
1
Hi, If this is implemented, would it be possible for this to be configurable by domain? We have a client who would benefit from this but other clients on the same server would not and may see it as a burden. Thanks, Joe
1
Just checking in on this to see if there was any update, or if this was on a roadmap for development?  I do a lot of work in the medical industry and this would be clutch.
 
Brian Shrift
Precision Business Solutions
 
 
 
 
 
1
I'm running the newest version of 13.x and TLS enabled still allows the STARTTLS to be ignored by the incoming connection. 
I did find a workaround via a third party hardware vendor that allows a firewall to send the STARTTLS commands and not allow a connection to your SmarterMail unless it is TLS. 
You will still have all your standard ports open for this. 
Google + is +MurrayW if you need the link and equipment list just in case it's edited out. 
 
I'm using the Watchguard XTM 330 Firewall fireware 11.9. The configuration is at 
www.mysmallcloud.com/build-your-own/micro-enterprise-config/watchguard-xtm-330/smtp-incoming
 
Combine the SmarterMail server with fireware 11.9 and TLS becomes a Full Time connection.
2
Up to the current 14.x release it is still not possible to force the use of STARTTLS.
 
The number of client who we have to explaine to that it is not yet possible is growing.
 
When do you plan to add this security feature into SM?
 
Carsten
3
+1 for this functionality.  A missing tooth for organizations who want to enforce basic security principles.
1
Any chance this feature will be added to the next version?
1
+1. With new focus on security maybe this will get more attention?
1
any update on this?
2

Can you guys implement a Forced/Enforce TLS option for incoming and outgoing specific domains?

G Suite has this ability and so does Exchange

0
There are a couple of different issues involved here.
1) Does lack of encryption indicate a spammer?
I support a pretty large user base, and have analyzed the logs from my spam filter to evaluate this question,   My though was that absence of encryption should be given a negative weight in the spam scoring process.  We block a lot of traffic on static criteria, including source IP, reverse DNS, and sender email address.   So I only considered messages that were processed by the spam scoring engine.
 
The surprise conclusion:   Presence or absence of an encrypted connection had no correlation with spam status,because the percentage of blocked traffic was nearly identical in both the encrypted and unencrypted groups.    
 
0
Employee Replied
Employee Post
Hi everyone, 
 
Just a quick update... This post is still on our radar, and we'll be discussing its possible implementation in a future version of SmarterMail. There are some things to be carefully considered, specifically: If you accept only TLS connections, you may lose out on A LOT of legitimate emails. There are many servers that start with plain text then try to initiate STARTTLS after they've connected. So that, among others, is something to take into consideration to ensure a proper implementation. 
 
I don't believe this would make it into the initial release of SmarterMail 17.0, or if this is a small enough feature that could be added into a minor release down the road. It may be something that needs to wait until our next major release. That said, we will post updates here as they become available.
 
Thank you for your participation and feedback! We appreciate it. 
4
Please, if you do implement this, don't take the simple route and just allow it to be set on or off for the whole server because that is pretty much useless in most circumstances.  Rather, take the Exchange model and also allow forcing of TLS for incoming and/or outgoing email with specific domains.  Better yet, allow each domain administrator to specify their own forced TLS for incoming and/or outgoing email with specific domains.  You can also set up IP based forcing of TLS in order to cover things like email gateways/gateway services, both incoming and outgoing.  That's the Exchange model and it's well thought out IMO.
1
This is exactly what I requested in my comment above. Enable Forced TLS for specific domains, not entire server. Microsoft and Google has this option.
1
Yes, but allow each domain on the server to set up their own forcings, and allow this to be done also by IP address. The devil is in the details. Likewise, it would be good to have both server-wide forcings as well as domain-wide forcings. This would give almost everyone the ability to configure things appropriately regardless of whether you are a service provider or a business with a dedicated server.

I have had two customers that have demanded this functionality and I haven't been able to provide it. Banking regulators as well as security protocols in other industries have been moving from Zix type systems over to forced TLS for communications. It's a real issue, and a real need! Granularity is necessary to meet the need.
0
Likewise, we also had 2 customers that demanded this.
0
Employee Replied
Employee Post
Thanks for the feedback, guys!
0
Following up on my earlier incomplete posts:   
 
Requiring TLS outbound from SM to BigBank is pretty straightforward -- The MX list provides a limited number of servers to which you might need to connect, so you can validate the connection quickly during the cutover.   So the implementation only needs to ask for the domain for TLS enforcement, whether to enforce certificate verrifcation, and possibly whether to apply the rule to all subdomains.
 
Requiring TLS Inbound is much more difficult, because BigBank has a hard time knowing everyone that is sending email on their behalf.  This is why they need DMARC feedback to help them figure out what is happening in the mail world.   The "real" bank mail may be done with TLS on their outbound traffic, but they probably have a marketing service which is using their name and not encrypting (because encrypting add to their overhead, and it makes a big difference when emailing to millions of addresses per day.)   
 
Maybe your particular BigBank will have all of this sorted out, and their marketing vendor will use a different mail domain or use TLS.   The only way to find out is to wait for mail to be blocked, so you should camp out on your inbound mail logs.
 
One of my mail gateways can configure inbound TLS enforcement by domain.  This is easiest to configure, which works as long as BigBank has all of their mail senders using TLS, now and in the future.   This product has no exception mechanism if they do not.   
 
My other spam filter does inbound TLS enforcement by server IP address.   In theory, this allows you to mandate TLS encryption from the servers associated with critical bank functions, while ignoring encryption for the third-party marketers that are using the bank's name.   But knowing which servers should be in the list is problematic, and likely to change without notice, so it is a bad design.   
 
One option would be to enforce based on domain, with exclusions by server.  But mass mailing companies typically use a lot of different servers.   So I suggest that the design use enforcement by domain with exceptions based using IP, Reverse DNS hostname (server1.mailcompany.com), or Reverse DNS suffix (.mailcompany.com).   Of these, exception by Reverse DNS Suffix is probably the most important.
 
0
Bulk mail providers during the SMTP handshaking will use a Mail From value that almost always is a different domain than the From address in the actual message, provided that From address uses their client's own domain. The reason for this is VERP (Variable Envelope Return Path). VERP addresses are designed to cross-reference the recipient address in an internal database. You need to be able to capture bounce messages for tracking unsuccessful deliveries, and only the bulk mail service provider can make use of VERP, not a normal mail server. So there is almost always domain separation between the client's own domain and the SMTP envelope, and therefore TLS enforcement is a non-issue.

The only place where this is really an issue is with things like email scripts on websites that don't have TLS enabled in their SMTP server. Naturally any bank should be using solutions everywhere that support TLS outside of their networks, and a failure there would be totally their fault if they asked partners to force TLS.
0
As a generalization, your statements may be correct. It would be a valuable exercise to load 90 days of non-blocked message history into a database, and test whether it holds true or not. I did that exercise awhile back, and was surprised that I could not require TLS for a major health insurance company, and decided to do nothing with TLS enforcement. This discussion may motivate me to repeat the exercise. This was only possible because I had a log source other than SmarterMail.

However, the critical question right now is what solution should SmarterMail build to meet this requirement. I suggest that it would be foolhardy to build a solution that does not include an exception process, and I have tried to lay out the considerations of what that exception process should look like, based on my experience with email management.
0
This discussion also points to an issue that I tried tor address in a different post:   mail servers and spam filters are each specialized skill sets, and it is difficult to be the best at both.   
 
If you have an immediate need for TLS Enforcement, you have plenty of options for spam filters devices that can sit in front of SmarterMail, as a smart host, to provide this capability.
 
If you shop carefully, you will probably find that the extra investment will produce lower levels of spam getting through to your users.   You can still use all, or nearly all, of SmarterMail's defense features as a backstop to the smart host device.   I say "nearly all", because some features, such as graylisting, are only effective if implemented on the perimeter device.
0
With Zixmail, you do not have the possibility of mail forwarding.   When you rely on TLS enforcement, auto-forwarding introduces the possibility of non-encrypted transmission.  This can be addressed with a mix of business policy and technology:
  • Prohibit off-server auto-forward and train about the risks of manual forwsrd.
  • Ensure that auto-forward destinations are configured for at least outbound TLS enforcement.
  • Obtain a Smartermail feature that detects insecure auto-forward and takes corrective action, either rejecting the inbound message as undeliverable or forwarding to a designated admin destination instead of the requested one.
0
Typically you only force TLS on outbound email, not on incoming email. If both sides are doing this, then you are both using TLS. You shouldn't force TLS unless the sender requires it. Forcing TLS on incoming email is primarily only done between a gateway and the mail server, and done by IP address. If you are smarthosting outbound email, you may want to force TLS on outbound to a specific IP of the service/device.

I've been providing spam blocking services for over a decade and am very familiar with bulk email services. All the major providers use VERP and a domain name dedicated to bulk email for the SMTP envelope. SmarterMail will record the SMTP envelope Mail From address at the top of the message headers or in the logs. This address is what TLS enforcement should be done on. Definitely not the From address in the headers.
0
Of course, SmarterMail features to prevent an insecure auto-forward would only work it were the perimeter device. A smart host would prevent it from making a correct decision about what constitutes an insecure auto-forward
0
We would also like to see this option for domain users who require this security.

A related issue: If the remote server have an expired certificate the TLS connection are also dropped and eventually the mail are delivered without encryption. Encryption with an expired certificate would be better then unencrypted in our opinion.
0
+1
Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Reply to Thread