Hi J., 

 

This isn't available in the 17 BETA at this time. However, it is on our discussion list. I'll bring it up and let you know what feedback I hear. 

J.

 

I hope all is well. I wanted to open a dialogue with you to better assist us in understanding your business needs here. I'm a big advocate for this feature since I'm personally very privacy centric with my security best practices. Our CEO Tim and I have been discussing the idea of implementing a feature to restrict non-TLS connections however there have been a few concerns brought up.

 

Disabling the acceptance of non-TLS connections will cause a major drop in your mail volume since not all mail servers will be configured to send with TLS if the remote server advertises the STARTTLS capability. Our CEO is also expressing some concerns regarding how often this feature would be leveraged in the average SmarterMail environment. He believes this is something that would only be enabled in very controlled environments that have an explicit need for TLS restrictions due to certain internal policies, regulatory compliance, etc. 

 

In order for me to advocate on your behalf for this feature, do you mind providing me with a bit more information about your environment and why this setting would be implemented within your environment ? 

I would like to also mentioned RFC-7672 alone with this thread since the two go hand-in-hand.  This RFC discusses SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS).

 

"With opportunistic DANE TLS, traffic from SMTP clients to domains that publish 'usuable' DANE TLSA record in accordance with this memo is authenticated and encrypted. Traffic from legacy clients or to domains that do not publish TLSA records will continue to be sent in the same manner as before, via manually configured security, (pre-DANE) opportunistic TLS, or just cleartext SMTP" (Section 1).

 

We have DANE TLSA in our development backlog for future implementation.  However, if this is more viable and should be implemented in addition to the aforementioned idea, we can consider that too.  As Von stated, we're trying to have an open dialogue with our user base.

 

There is a related community thread pertaining to DANE TLSA support here.

Hi You all

 

Thanks for the responses. My clients are CPAs and Lawyers, and we have a File Share System. So 2 SM servers one for icfiles.com and one for business email.

 

So I was hoping for not a global setting but an email setting. Create Email/ Select Only Send if Encrypted/Send. Something like this.

 

I agree a Global setting would probably cause all kinds of delivery problems. But if is could be set per domain or per email this would allow the end user to choose according to email contents.

 

I'm assuming this would not work with SMTP services like mailchannels and sendgrid?

 

Robert would Dane TLSA deliver normally if TLS is not possible?