Routing of outgoing mail to dedicated TLS Mailserver for specific domains

I have run into a similar problem and need to find a workable permanent solution for this.

We are using our UTM as our outbound mail relay for our web application servers to prevent availability issues and other service disruptions if our Exchange servers are offline.  This works for the most part, but we have an email-to-fax service that is reached using a custom subdomain, and the only way I've found to re-route outbound email through the UTM is to create a custom SMTP profile that is routed to the fax server.  The problem with this is that it technically creates an open relay to these destinations, which we'd prefer to be unreachable from the Internet.  (They're not published, so someone would have to have extensive information about our organization or really good luck to exploit it, but either way, it's a gap we need to close.)

We also have *many* partners with whom we are required to configure mandatory TLS, and many of them use products like Office 365 that have somewhat ephemeral destination gateways... we really need to be able to configure outbound TLS enforcement at the domain name level, not just the SMTP host.

Let's return to the original thread topic:  do you really need guaranteed TLS?   I say NO.

Begin by separating legal from technical issues.  Many of us have a legal, regulatory, or contractual obligation to protect sensitive data from disclosure to unauthorized persons.    This responsibility falls primarily on the sender, because by definition the sender is the data custodian at the start of the transaction.   The sender's employees have the obligation to determine if a particular message contains sensitive data, and to choose an appropriate delivery method if it is sensitive.   This means that employee training is the most important part of the equation.   It also means that email is almost never the appropriate vehicle for communicating the information.   Sender responsibility also means that enforcing encryption of incoming mail is not really your problem.  The medical and health insurance industries transfer vast amounts of protected personal data, and on a trivial fraction of the total flows using any form of email.

To comply with the privacy requirement, you really need user-to-user data privacy, including protection of data-at-rest.   If you are send something to Office 365 securely using TLS, you have done nothing to protect the sensitive data from the Office 365 system administration staff.   Even within an organization, the sensitive data should be protected from prying eyes of employees who do not need to know, including the IT staff.   There are a variety of tools to accomplish this, all of which have weaknesses, which is exactly why email is usually the wrong solution.

Many of the options involve putting the sensitive data in an attachment and protecting the attachment:   SPX is a sophisticated form of protection using passwords, but Word, Excel, and Adobe Acrobat can do passwords as well.   S/MIME, PGP, and PKI-encrypted mail are other options. 

Web-based relay is another strategy, of which Zixmail is the one that I have encountered most often.  Web relay has legitimate objections, because it is impossible to prove that data is protected at rest, and because it is vulnerable to the same eavesdropping attacks that create a desire for encryption in the first place.  Nonetheless, it is probably the one most widely used.

If you are communicating with an organization that expects to receive sensitive material by email, they will be equipped to accept TLS.  Presumably you have configured UTM to send using TLS whenever possible.   So the reality is that you can be pretty sure that the message will flow encrypted, as long as you actually connect to the correct mail server.   Defending against diversion to a rogue server, or other forms of man-in-the-middle attacks, will involve a whole bunch of other defenses, particularly DNS SEC and certificate verification.   TLS for EMail generally does not worry about certificate verification.   Without it, you don't know that the remote server is who he claims to be.   With it, you only validate the name of the mail server, but you do not validate that it is really the host you should be using for a particular mail domain.

Defense-in-depth says to use multiple strategies together.  Use TLS along with password-protected attachments.

Bottom line:   if you need a guaranteed-secure channel to company X, you need to establish a VPN tunnel, and route your mail for them through that tunnel.   If you need user-to-user protection, you need something more.

Yeah, Doug, I probably should have responded to the TLS question in this thread and asked him to post the other question separately.

If you don't want to send emails to MTAs that can't communicate using TLS, drag the Any network object into 'Require TLS Negotiation Hosts/Nets' on the 'Advanced' tab of 'SMTP Proxy'.  If you want to reject mail from senders that can't do TLS, put *.* into  'Require TLS Negotiation Sender Domains'.

Is that what you were trying to accomplish?

Cheers - Bob

Yeah, Doug, I probably should have responded to the TLS question in this thread and asked him to post the other question separately.

If you don't want to send emails to MTAs that can't communicate using TLS, drag the Any network object into 'Require TLS Negotiation Hosts/Nets' on the 'Advanced' tab of 'SMTP Proxy'.  If you want to reject mail from senders that can't do TLS, put *.* into  'Require TLS Negotiation Sender Domains'.

Is that what you were trying to accomplish?

Cheers - Bob