Scarab, thank you for suggesting this. I have added it to our discussion items list.

Hello,

Has there been any progress here? How can we implement this with SmarterMail?

I am curious whether anyone has already implemented this by using an open source product as an incoming gateway. 

 If so, has it helped to block unwanted mail?   

What types of exception rules were needed to handle special situations?  

This last question is a personal hot button because too many products have implemented SPFand DMARC as on-off switches with too little consideration for exception handling.

Does SmarterMail support  MTA-STS (MTA Strict Transport Security) and SMTP TLS Reporting? 

Short answer, No.   This discussion includes my solution for TLS reporting.

You may find this other discussion helpful on the problems with TLS1.2 enforcement
https://portal.smartertools.com/community/a94059/smartertools-e-mail-about-tls.aspx

But nothing seems to have happened on MTA-STS.  SmarterMail has had their hands full shaking down problems with MAPI and IMAP.   But as I indicated in my note on this topic, if this is a regulatory requirement for you, you should be able to comply by implementing an incoming and outgoing gateway using another product, probably postfix.   We would all be interested in your results.

Hey @smartertools team! 

Do you have a status on the addition of MTA-STS checking and SMTP TLS Reporting?

It may be worth breaking this into two pieces:   incoming and outgoing.

For incoming traffic, the required components are a DNS entry and a data analysis component for evaluating reports.  The analysis service is not dependent on any particular email system.  A quick web search for "smtp tls reporting service free"  turned up one free service option (which I have not used.)

For outgoing traffic, MTA-STS ensures that the traffic is encrypted if the destination says that it should be.  It does not ensure that encryption happens on all outbound traffic, so you need to think about what your organization needs.   We decided that all outbound mail needed to be encrypted, which is enforced by our third-party outbound gateway.   Email which cannot be delivered by TLS is blocked, the rest is redirected to the vendor's secure web relay solution.  

Secure web relay defined:  The message is redirected and sent with encryption to the vendor's secure website.   The user receives a replacement message telling him to log onto that website to pick up the message, and that session uses HTTPS encryption.   The message is also stored encrypted on the vendor's website, so it is encrypted in transit and encrypted at rest until delivered to the intended user.  Many organizations use this feature for mail that contains sensitive or regulated content.   Zixmail seems to be the best known brand name for this functionality.   

There are theoretical problems with secure web relay:  if all messages to a user are being intercepted, then the notification message is also being intercepted, so the attacker can impersonate the recipient on the vendor website.   But the concept seems to be acceptable to regulators and is widely used.  

(Digression: S/MIME and PGP do not have the problems of impersonation, but they require too much advance setup by both sender and receiver, which makes them unsuitable for many situations.   Additionally, content that is end-to-end encrypted will be unscannable by an incoming spam filter, so you don't want untrusted senders to be able to send encrypted content to you. )

Overall, secure web relay is an important capability for many organizations.   If you have that capability, and if it can be adapted to enforce outbound TLS, then you have a better solution than MTA-STS alone.