O365 and encrypted mail to other email systems
-
Zix = painful for everyone
Excahnge = Painful for almost no one -
Does the email bounce back if it can't make a secure connection?
-
@Dashrender said in O365 and encrypted mail to other email systems:
I suppose, in this case, Faxing is given a pass that it, as a technology, does not have to fit within the requirements of HIPAA's stated laws.
If that were true, faxing would be listed as an exception. But it is not. The rules are simply lax enough that faxing and therefore email are allowed.
-
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
-
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
Frame it more like this, at least to yourself:
TLS Pros Compared to Zix: Cheaper, Standard, Nearly all customers get an effortless experience.
Zix Pros Compared to TLS: None
Disagree Zix does have one Pro: able to send notice of desire to communicate, but TLS isn't available, so you must use another more painful means.
Regarding failure to send TLS. Just because it fails does not mean you have no way to communicate the need to contact the office. You have a couple of options here.
With the sole purpose of being used to send an email to failed parties telling them that you were unable to securely email them and that they need to contact the office, you can do this:
2.a Setup a simply Gmail/Outlook.com account for the practice
2.b Setup a basic Linux box and make use of the built in Postfix to send email (via some application probably) from your own domain. Basically a second email server that does not have the TLS restriction.
2.c Possibly have a single email account on your Exchange server that is immune form the TLS requirements. Not even sure if this is possible when you set TLS as wildcard required.I tend to agree, I don't think Exchange will allow you to make a single account immune.
and yes, an external account to your main domain would be the way to solve this, for the notice at least, then you have to find another way to actually get the data to them.
-
What happens if the customer gives you a wrong phone number for fax? Or if they give you a wrong address? What is your responsibility to delivering the message if you don't have the correct information?
-
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
Disagree Zix does have one Pro: able to send notice of desire to communicate, but TLS isn't available, so you must use another more painful means.
Nope, you can make rules for TLS that allow you to send notification but not the payload.
You just repeated what I said. Now, since Zix doesn't give a shit about TLS, it only ever uses it's secure portal (to the best of my knowledge) all secure messages are sent using their painful method, but a notice about that message is sent via to the client over whatever, TLS or not is available to the server.
But you can do that with Exchange, too. But never have the uselessly painful portion.
That's interesting - so you know that exchange can have a second transport option created that will send a generic notice to a NON TLS recipient and not send the original email? That would be cool. Still need a solution for the actual message content at that point, but that's for another discussion.
-
@coliver said in O365 and encrypted mail to other email systems:
Does the email bounce back if it can't make a secure connection?
I would assume the Exchange user in this case would get a delivery denied notice.
haven't confirmed yet. -
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
-
@coliver said in O365 and encrypted mail to other email systems:
What happens if the customer gives you a wrong phone number for fax? Or if they give you a wrong address? What is your responsibility to delivering the message if you don't have the correct information?
And unlike email which is "untappable" locally, fax is trivial to tap at either end. Even if you secure your own end (you can't) you have zero control over the other end and their fax can be intercepted because they even know that you tried to send one.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
Disagree Zix does have one Pro: able to send notice of desire to communicate, but TLS isn't available, so you must use another more painful means.
Nope, you can make rules for TLS that allow you to send notification but not the payload.
You just repeated what I said. Now, since Zix doesn't give a shit about TLS, it only ever uses it's secure portal (to the best of my knowledge) all secure messages are sent using their painful method, but a notice about that message is sent via to the client over whatever, TLS or not is available to the server.
But you can do that with Exchange, too. But never have the uselessly painful portion.
That's interesting - so you know that exchange can have a second transport option created that will send a generic notice to a NON TLS recipient and not send the original email? That would be cool. Still need a solution for the actual message content at that point, but that's for another discussion.
I know that it has "TLS Transport Rules" so that it only requires TLS in certain circumstances.
-
@coliver said in O365 and encrypted mail to other email systems:
What happens if the customer gives you a wrong phone number for fax? Or if they give you a wrong address? What is your responsibility to delivering the message if you don't have the correct information?
In the case of a wrong fax - 99.9% of the time it will fail, so the data would go no where. As for Postal Mail - it's in a sealed envelope, and assuming the incorrect receiver put a return to sender, wrong address label on it, we'd get it back intact.
So in most cases there is little to no concern. Mail isn't covered by the HIPAA as fair as digital data goes, so it's not my concern..
-
@Dashrender said in O365 and encrypted mail to other email systems:
In the case of a wrong fax - 99.9% of the time it will fail, so the data would go no where. As for Postal Mail - it's in a sealed envelope, and assuming the incorrect receiver put a return to sender, wrong address label on it, we'd get it back intact.
Um yeah, postal mail doesn't work that way
-
@Dashrender said in O365 and encrypted mail to other email systems:
Mail isn't covered by the HIPAA as fair as digital data goes, so it's not my concern..
Nor is faxing, it's analogue.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
-
@Dashrender said in O365 and encrypted mail to other email systems:
Mail isn't covered by the HIPAA as fair as digital data goes, so it's not my concern..
Depends, do you have an account number on the paper? That would be digital data.
-
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
Disagree Zix does have one Pro: able to send notice of desire to communicate, but TLS isn't available, so you must use another more painful means.
Nope, you can make rules for TLS that allow you to send notification but not the payload.
You just repeated what I said. Now, since Zix doesn't give a shit about TLS, it only ever uses it's secure portal (to the best of my knowledge) all secure messages are sent using their painful method, but a notice about that message is sent via to the client over whatever, TLS or not is available to the server.
But you can do that with Exchange, too. But never have the uselessly painful portion.
That's interesting - so you know that exchange can have a second transport option created that will send a generic notice to a NON TLS recipient and not send the original email? That would be cool. Still need a solution for the actual message content at that point, but that's for another discussion.
I know that it has "TLS Transport Rules" so that it only requires TLS in certain circumstances.
Eh? you mean every circumstance?
I suppose, IF, and only IF Exchange's transport rules can act upon things within the message itself, then a rule could be made - when a message subject line contains secure that the message can only be sent via TLS otherwise fail it. But I haven't seen that type of option available to the Rules.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
It's for HIPAA, not for security.
