Brian Shrift
Precision Business Solutions
 

 

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

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

G Suite has this ability and so does Exchange

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.    

 

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. 

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.

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.

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.

 

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.

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:

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.

+1