@Dashrender said in [O365 and encrypted mail to other email systems](/topic/9231/o365-and-encrypted-mail-to-other-email-

I believe Barracuda, from their web interface after you log in and decrypt you email, gives you a Deliver option, that will deliver the unencrypted version to the original destination.

Totally bypassing the whole point and tricking the sender into thinking that they secured something that they did not.

yeah, that's a pretty horrible option if it's really there.

Right, it would be more like 2-step authentication and less about maintaining consistent security.

@Dashrender said in O365 and encrypted mail to other email systems:

But I will capitulate to the fact that once the email is delivered to the remote server, it's no longer my concern, the question is.. is it my responsibility to ensure that the admin of the remote server can't read it as well? If the answer is yes, then you still can't send plain text messages through the TLS pipe.. it still needs to be encrypted itself so that only the receiver can open it.

The answer is no. It made to a receiving SMTP gateway with all the proper TLS stamps. Your job is 100% done.

@scottalanmiller said in O365 and encrypted mail to other email systems:

I'm getting confused Scott - Data at rest isn't currently a requirement to be encrypted, but damn, when the next rounds of legislation come, I'm sure it will be.

It literally cannot be. If they did that, every medical practice would just back up and be done. You can't control data at rest for transferred data, ever. Period, it's actually a crime to try to do that as you'd have to hack their systems.

The only resolution to legislation like that would be for the hospital to keep everything on-prem. Nothing would be transferred. Patients would log into a message box on their datacenter. This is currently how EHR applications with patient logons provide other information to patients.

(edit - provide, not deliver)

I believe Barracuda, from their web interface after you log in and decrypt you email, gives you a Deliver option, that will deliver the unencrypted version to the original destination.

@Dashrender said in O365 and encrypted mail to other email systems:

how is this any different than setting up a Zix account? or a Barracuda one?

You get a barracuda account so you can log in to un-encrypt your email. You get a MS account so you can be tracked/get sold/receive spam.

@Dashrender said in O365 and encrypted mail to other email systems:

In all honesty I don't think that could ever happen. The judge would be putting unlawful burden on an organization and the appeal would last about 3 minutes.

I could only hope you're right. But well you know.... 'merica.

Hey if you're part of a corporation fighting against a little guy, America is JUST the place you want to be lol.

@scottalanmiller said in [O365 and encrypted mail to other email systems](/topic/9231/o365-and-encrypted-mail-to-other-email-the user almost certainly does not have a Microsoft account and instead of sending them their data we've are forcing them to sign up with a third party vendor who is holding their data until they get them as a customer (even if only as a free one.)

Yeah, the fact that it has to be an entire MS account on the part of the recipient would be a dealbreaker for me.

@Dashrender said in O365 and encrypted mail to other email systems:

But then also comes the part when the first time some one is sued because you emailed their PHI to them, and they didn't secure it, and because it was sitting unencrypted in their easy to guess gmail account - the courts will sadly rule against us saying that we're the ones with the money so we should be the ones making sure they secure their shit.. SIGH

In all honesty I don't think that could ever happen. The judge would be putting unlawful burden on an organization and the appeal would last about 3 minutes.

@scottalanmiller I might understand the O365 offering wrong then. I thought it was like

1. Sender chooses to encrypt via 3rd party O365 service.
2. Email sends securely over TLS. The recipient receives a link.
3. Recipient clicks link, verifies their identity via a MS account, and can interact with the email in the cloud. The email contents never touch their local email service.

@Dashrender see my note above regarding compliance. You can compare it to FAX.
If I send PHI over fax to a fax machine in a remote location, it is the responsibility of the remote party to keep it secure.

This compares to something like Barracuda Mail Encryption. It's shining point isn't really around mail in transit, but mail at rest at the destination. TLS is great until that email sits unencrypted in a recipients gmail box that 80 hackers and your kids have the password to. It's a legitimate concern as a business owner... you want it to be secure end to end.

That said, there is no requirement, HIPAA or PCI or otherwise, that places the burden of safety of that email in your hands. Once it's over the wire encrypted, it's no longer your problem. But I do understand it's value; we used Barracuda email encryption whenever we would (be forced to) send PHI to another doctor office.

the DFSRoots folder is created automatically when you add that server as a namespace server. It only contains links to targets; you generally don't touch it. This plays into the best practice that you don't want to populate any actual data in your DFS Roots. Always create folder targets on separate volumes/servers, so the root links and target locations are separate.

I would say it's not possible. If they insist, I'd keep the email of them signing off on your concerns. Then when restoring a failed VM takes the SAN over the brink and causes your restore to also fail, you'll have something to show them.

Glad you got it. I'd recommend adding every DC as a namespace server. It provides redundancy for remotely connected machines. DFS lives in the domain, so you want to give clients as many ways in as you can.

@BBigford Look at the fileshares DFS root from the DFS console. Is there a DC that is a namespace server?

Hmm maybe just give it some time. Whenever I add a DC as a namespace server for my domain-based namespace, it eventually shows up.

There it is. Looks like it just took a bit?

@JaredBusch Is the DC on which you set up the example your %logonserver%?

Remember that when you browse to your domain, all you're really doing is browsing DFS namespaces/links that exist on the DC that you're logged into... like SYSVOL is DFS.

DFS Namespace servers just serve up the namespace and links, not the actual data, so there is no disadvantage to making all of your DC's namespace servers.

If you add a domain controller as a namespace server, then your /DFSRoot/ will show up when you browse to your domain namespace.