" email Archives - Page 5 of 9 - LuxSci

Posts Tagged ‘email’

Ask Erik: Is misaddressed email a HIPAA breach?

Friday, December 8th, 2017

Read the rest of this post »

A Comparison of Email Backup Policy of Popular Email Services

Wednesday, November 1st, 2017

Do you use email backup in your practice? Make a smart choice by comparing the backup policies of popular email solution providers.

Privacy concerns are constantly rising especially following the revelations by Edward Snowden. Now, the big question is “Do the popular email services in the US retain your data forever?” In order to find an appropriate answer, we examined the email backup policies of 7 popular providers.

Data breaches and privacy concerns make headlines for they have a direct impact on an individual’s private life. Going by the news of mass surveillance by government authorities, it is natural for you to be extra cautious about protecting your privacy. After all, nobody wants to get exposed although a bit of exhibitionism resides in each of us.

The US government is pressing technology giants to reveal what they have in their “box” (or your inbox). Apple reported that it received the highest number of security requests for data from the US government this year.

Considering the “attacks” from both the government and hackers, it is imperative for you to learn how these email services ensure that your data remain safe.

Read the rest of this post »

What exactly is ePHI? Who has to worry about it? Where can it be safely located?

Friday, September 15th, 2017

There is often a great deal of confusion and misinformation about what constitutes ePHI (electronic protected health information) and how to protect it under HIPAA requirements. Even once you understand ePHI and how it applies to you, the next question becomes, where is ePHI permitted? What is secure and what is not?

We will answer the “what is ePHI” question in general and the “where can I put it” question regarding web and email hosting and Secure Form processing at LuxSci.

Read the rest of this post »

DMARC: The State of Domain-based Email Authentication – Part 2

Monday, September 11th, 2017

Building a safer email ecosystem with DMARC

In our previous post, we described two techniques for authenticating an email sender:

  • Sender Policy Framework (SPF), IETF RFC 7208, which verifies if the sending MTA is indeed authorized to send mail on behalf of a domain; and
  • DomainKeys Identified Mail (DKIM), IETF RFC 6376, where a domain shows “ownership” of a mail it sends by signing portions of it so that critical aspects cannot be forged by intermediaries.

Like most technologies, these are just individual weapons in the arsenal for fighting phishing and spam. Weapons, like all tools, need to be properly used if they are to be effective. Unfortunately, as we described in the earlier post, both SPF and DKIM are deployed in a manner that reduces their usefulness. With SPF, the validation policy set by the sender is often chosen in a manner that leaves handling authentication failures at the discretion of the recipient. DKIM, on the other hand, does not even have an explicit policy directive set by the sender. Moreover, in a heterogeneous mail environment, some perfectly legitimate MTAs might not be capable of signing messages.

Building a safer email system with DMARC

Thus, receivers in actual deployments tend to “soft fail” any SPF and/or DKIM validation failures as there are reasonable situations when legitimate mail can fail such checks. A common example is forwarded mail (which fails SPF), or mail sent via a mailing list (which fails DKIM). Mail providers consider it better to deliver most mail (even if some are fake or spammy) rather than risk dropping legitimate mail. Thus, neither of these techniques individually or combined provide clear guidance to receivers, and the resulting actions can be inconsistent.

Read the rest of this post »

Is email message transport over MAPI or HTTPS secure?

Tuesday, September 5th, 2017

Our latest “Ask Erik” question involves understanding what email headers save about secure message transport … especially when they list MAPI or HTTPS instead of TLS.

Read the rest of this post »