O365 and encrypted mail to other email systems
-
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
-
Good point. Dollars to donuts you get very, very few.
-
@Dashrender Another idea might be to have separate delivery MTAs. Use one for ePHI and another for anything else.
On the ePHI-assigned MTA gateway, configure Force TLS, DNSSEC, DKIM signing, SPF, etc..
Route to the ePHI MTA gateway either by rule or by configuration (e.g. if ePHI info is only sent from a known number of systems, configure those to use the MTA gateway that has Force TLS configured on it).
Note that the data at rest that you keep on your side also has to be encrypted, if I interpret correctly the requirements.
On the other hand, you should really consider hiring a Certified HIPAA Security Expert and get a professional audit on the as-is, recommendation, implementation followed by an audit on the new implementation. -
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender Another idea might be to have separate delivery MTAs. Use one for ePHI and another for anything else.
On the ePHI-assigned MTA gateway, configure Force TLS, DNSSEC, DKIM signing, SPF, etc..
Route to the ePHI MTA gateway either by rule or by configuration (e.g. if ePHI info is only sent from a known number of systems, configure those to use the MTA gateway that has Force TLS configured on it).
Note that the data at rest that you keep on your side also has to be encrypted, if I interpret correctly the requirements.
On the other hand, you should really consider hiring a Certified HIPAA Security Expert and get a professional audit on the as-is, recommendation, implementation followed by an audit on the new implementation.At rest encryption is not required.
As for the split MTAs it's a though, but nearly everyone in the company deals with PHI, and needs to be able to send and receive PHI, so there would be so few people on the non PHI side as it make the effort not worth making.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
The other cool thing. These two technologies aren't mutually exclusive. You can try one, with minimal work, and see if that meets your needs. If it doesn't, backtrack and deploy the second solution.
Again, you will probably find that the first solution will have such a low bounce rate as to be unnoticeable.
-
@coliver said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
The other cool thing. These two technologies aren't mutually exclusive. You can try one, with minimal work, and see if that meets your needs. If it doesn't, backtrack and deploy the second solution.
Again, you will probably find that the first solution will have such a low bounce rate as to be unnoticeable.
I agree - it's just getting the boss to accept that a few failures will happen and then an acceptable resolution solution for those failures.
-
Tangential question: will the TLS to TLS connection work if the remote server does not have a trusted certificate?
I'm trying to figure out how to get a handle on all of our communication and what we actually need to do to be compliant and secure in our communications with customers. Unfortunately the DoD and related subagencies do not use certificates trusted by any other authority. Therefore, O365 will not trust the certificate of the remote server.
-
@Kelly said in O365 and encrypted mail to other email systems:
Tangential question: will the TLS to TLS connection work if the remote server does not have a trusted certificate?
I'm trying to figure out how to get a handle on all of our communication and what we actually need to do to be compliant and secure in our communications with customers. Unfortunately the DoD and related subagencies do not use certificates trusted by any other authority. Therefore, O365 will not trust the certificate of the remote server.
By default, yes. Can you require that it be trusted? Yes you can.
-
@Dashrender said in O365 and encrypted mail to other email systems:
I agree - it's just getting the boss to accept that a few failures will happen and then an acceptable resolution solution for those failures.
I would just explain that the alternative, the Zix method, is a failure "every" time. And not a failure to you, but a failure to the other end. Instead of you getting notified that things didn't work once in a while (or maybe never), your recipient gets notified that things didn't work through email every, single, time.
So it is a huge win in two ways:
- Failures are uncommon and unexpected instead of common and expected
- Failures are invisible to customers instead of invisible to you
-
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
I agree - it's just getting the boss to accept that a few failures will happen and then an acceptable resolution solution for those failures.
I would just explain that the alternative, the Zix method, is a failure "every" time. And not a failure to you, but a failure to the other end. Instead of you getting notified that things didn't work once in a while (or maybe never), your recipient gets notified that things didn't work through email every, single, time.
So it is a huge win in two ways:
- Failures are uncommon and unexpected instead of common and expected
- Failures are invisible to customers instead of invisible to you
Man, that's one weird way to look at it - I don't consider being told to go get your encrypted file from some server on the internet as a failure, but I do understand why you do.
-
@Dashrender said in O365 and encrypted mail to other email systems:
Man, that's one weird way to look at it - I don't consider being told to go get your encrypted file from some server on the internet as a failure, but I do understand why you do.
From a customer service perspective, it's a huge failure, but getting a bounce back because someone can't receive an encrypted package isn't. In one case you are telling the customer that you have their file but... they can't receive it. In the other, if they can't receive it, you know before it becomes a failure to them. In both cases, IF transparent email doesn't work, you work around that with something other than email. In one case, it's a failure every time, in the other, it works nearly every time.
-
A similar way of thinking is "financial loss events." What is a financial loss event? Well, an outage for example. If your servers go down for an hour, you lose money (presumably.) That's a FLE.
You know what else is an FLE? Paying too much for a risk mitigation solution like HA that doesn't work. It's not an outage, per se, but it loses money just like an outage.
So thinking in terms of FLEs being anything that causes you to lose money unnecessarily makes for better decision making.
Same with the email versus Zix. Zix acts identically to a failure in TLS sending. Sure, because you "forced it" it's not technically a failure, because you didn't even try. But the results are the same.
-
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
Man, that's one weird way to look at it - I don't consider being told to go get your encrypted file from some server on the internet as a failure, but I do understand why you do.
From a customer service perspective, it's a huge failure, but getting a bounce back because someone can't receive an encrypted package isn't. In one case you are telling the customer that you have their file but... they can't receive it. In the other, if they can't receive it, you know before it becomes a failure to them. In both cases, IF transparent email doesn't work, you work around that with something other than email. In one case, it's a failure every time, in the other, it works nearly every time.
I don't look at it as bleakly as you do. You in no way told the receiver they couldn't receive it, you told them they have to use a different method to receive it. Is it a good experience - I'm not going to argue that point, frankly I don't care as long as it works.
But, I'm also not trying to find the best/most secure method to deliver something either, Instead I'm trying to find a HIPAA compliant solution, the the Force TLS setup provides that.
-
@Dashrender said in O365 and encrypted mail to other email systems:
I don't look at it as bleakly as you do. You in no way told the receiver they couldn't receive it, you told them they have to use a different method to receive it. Is it a good experience - I'm not going to argue that point, frankly I don't care as long as it works.
But you did... you sent them an email and the email didn't include the payload, it told you to go look in another system for the payload that didn't arrive (the princess is in another castle.) Why did you need the email if email isn't delivering the message? It's obviously similar to failure... two systems are being used for a single thing. All they want is the payload, not a message telling them about a payload elsewhere.
-
T travisdh1 referenced this topic on
