When sending email messages, there are many best practices for ensuring optimal deliverability.   I.e., for getting your messages into your recipients’ Inboxes and for staying off black lists.  One very important factor in deliverability is “IP reputation.”

Good reputation: If your server is known to send lots of good quality email (email that people do not consider spam-like), then your server’s address (its “IP Address”) is looked on favorably by ISPs (such as Yahoo!, Google, Microsoft, etc.) and you can send large quantities of good email and have it all delivered.  Your server has a good reputation and your server’s IP address is “warm” (think warmed up and humming a long).

Bad reputation: If your server is a known source of junk or malicious email (according to the recipients of the email — it doesn’t matter what you think about the email quality), then you will have a hard time getting your email delivered and many ISPs will throttle your email, accepting only a few messages a time.  Your server has a poor reputation and work will need to be done to repair it.

No reputation: If you just got a new server, it may not have been sending any email for a while.  Or, if you have a server but it has been idle for a long time (e.g, months).  In either case, your server’s address may have “no reputation.”  ISPs are very skeptical about email from servers with no reputation or recent history of good email sending.  A typical sign of a spammer is when a server with little or no reputation suddenly starts sending large quantities of email.  ISPs will detect this and they tend to quickly throttle or block such servers…. moving them from “no reputation” towards “bad reputation”. Read the rest of this post.

Gartner reports that just 13% of global enterprises are using cloud services today, although this percentage is forecasted to rise. A HIMSS Analytics survey of cloud adoption in healthcare organizations reveals that 83% of IT executives use cloud services, mostly running SaaS-based applications in the cloud. In the complex healthcare sector burdened by regulations, there may be some hesitancy to trust the cloud to secure business email, particularly messages containing private/personal health information (PHI).

However, reputed cloud email security providers can do a far better job of ensuring the confidentiality and availability of your email than what your organization may be able to manage, especially if you are cost-constrained.

Here are seven things you should know about cloud-based email security. Read the rest of this post.

Many healthcare organizations prefer using email for business communication as it leaves a paper trail and can be a more secure solution than mobile messaging. When large volume transactional emails need to be sent every month, healthcare organizations face the challenge of ensuring that any financial and personally identifiable data sent by email is secured to avoid data misuse. The good news is that the email security challenge can be overcome by using a high bulk email platform that safeguards the confidentiality of the information.

Here’s what you should look for when selecting an email platform for transmitting large volumes of transactional information regularly: Read the rest of this post.

It happens at least every few years: system administrators need to update the security configuration of their servers to keep up with the latest best practices and to close newly found security issues(i.e., via changes to recommended TLS ciphers and protocols).  These updates can be rocky. Change often introduces incompatibilities that prevent certain systems or programs from being able to connect to the updated systems.

In this article we are going to look at what email program an web browser incompatibilities arise when you migrate from using the “old standard:” TLS v1.0+ and the ciphers recommend by NIST 800-52r1 to using either TLS v1.0+ and the new NIST 800-52r2 ciphers or TLS v1.2+ and the new NIST 800-52r2 ciphers.

Why?

1. PCI requires that servers that need to be PCI complaint use only TLS v1.1+ (which really means v1.2+) by the end of June, 2018.
2. NIST 800-52r2 is in draft, but its updated cipher list removes many ciphers from revision 1 that are now considered “weak” and introduces a number of new, better ciphers.  Administrators should be moving towards NIST 800-52r2 cipher support as a best practice.
3. Organizations that require HIPAA compliance should also follow the NIST guidelines and prepare NIST 800-52r2 support and, where possible, eventually eliminate pre-TLS 1.2 support. See: What level of TLS is required for HIPAA compliance?

Read the rest of this post.

SSL and TLS are not actually monolithic encryption entities that you either use or do not use to connect securely to email servers, web sites, and other systems.  SSL and TLS are evolving protocols which have many nuances to how they may be configured.  The “version” of the protocol you are using and the ciphers used directly impact the level of security achievable through your connections.

Some people use the terms SSL and TLS interchangeably, but TLS (version 1.0 and beyond) is actually the successor of SSL (version 3.0). … see SSL versus TLS – what is the difference?  In 2014 we saw that SSL v3 was very weak and should not be used going forward by anyone (see the POODLE attacks, for example); TLS v1.0 or higher must be used.

Among the many configuration nuances of TLS, protocol versions supported (e.g., 1.0, 1.1, or 1.2) anf which “ciphers” are permitted have the greatest impact on security.  A “cipher” specifies encryption algorithm to be used,  the secure hashing (message fingerprinting / authentication) algorithm to be used, and other related things such as how encryption keys are negotiated.   Some ciphers that have long been used, such as RC4, have become weak over time and should never be used in secure environments.  Other ciphers provide protection against people who record a secure conversation from being able to decrypt it in the future if somehow the server’s private keys are compromised (perfect forward secrecy).

Given the many choices of ciphers and TLS protocol versions, people are often at a loss as to what is specifically needed for HIPAA compliance for an appropriate and compliant level TLS security.  Simply “turning on TLS” without also configuring it appropriately is likely to leave your transmission encryption non-complaint.   Read the rest of this post.

GDPR, the General Data Protection Regulation which asserts and enforces protections on the personal information of EU citizens is on everyone’s minds these days. This is because it impacts any company anywhere in the world that interacts with citizens of the European Union (EU), even if that only means sending email messages to them.  The kicker … if you are found to be in non-compliance you could earn yourself a fine of 20 million euros or 4% of your gross annual revenue, whichever is higher.

As an email security company, we receive a lot of questions around the intersection of email and GDPR.  There is a whole lot of confusion out there and ambiguity in the regulations.  In this post, we answer 10 of the most prominent and important questions on GDPR and email that we have seen.  The answers are at times surprising and even enlightening.  However, if you are unaware of the answers to these questions, you are almost certainly out of compliance with GDPR. Read the rest of this post.

On the 25th of May 2018 a new data protection law, the General Data Protection Regulation (GDPR), will take effect in the European Union. The GDPR aims to strengthen the data protection and privacy for all individuals within the EU and brings with it the most significant changes to data protection law in two decades. Based on privacy-by-design and taking a risk-based approach, the GDPR has been designed to meet the requirements of the digital age.

The 21^st Century brings with it broader use of technology, new definitions of what constitutes personal data, and a vast increase in cross-border processing. The new Regulation aims to standardize data protection laws and processing across the EU; affording individuals stronger, more consistent rights to access and control their personal information.

To ensure that LuxSci is ready for the GDPR, we have updated our Privacy Policy and Master Services Agreement (MSA) to comply.  There is now a “GDPR Data Privacy Addendum” to our MSA that is automatically included in all contracts with existing and future customers and which, together with LuxSci’s participation in and certified compliance with the EU-US Privacy Shield,  provides the required contractual framework for ensuring that our customers are GDPR compliant when using LuxSci as a data processor.   The changes to LuxSci’s privacy policy and MSA are effective as of May 23rd, 2018. Read the rest of this post.

Your eCommerce customer, Paul, has ordered a special mattress for his bed. He’s put the item into the cart, and paid for it. Now you send a confirmation of purchase email.  But, instead of just a note stating that “we’ve received your payment, and your item has been posted for shipment…” or whatever boilerplate many companies send, you include that message and add photos of three sheets-and-pillowcases products that fit the mattress you just sold him. Paul has his own sheets, but has been thinking about replacing them – now your confirmation email makes him decide to buy them.

All eCommerce companies have to send transactional email, a type of email sent to facilitate an agreed-upon transaction between the sender and the recipient. Common transactional email use cases include doctor appointment reminders, account creation emails, password resets, purchase receipts, account notifications, medical lab results, and social media updates like friend and follower notifications.

What makes transactional email different from ordinary marketing email is that they are sent as part of doing actual business with people – not just chatting with, marketing to, or selling to a customer. In this respect, they are also different from so-called “triggered” emails which may be generated by a number of customer actions – not just transactions.

Transactional emails are opened eight times more than traditional marketing messages, according to a study by EPSILON.  So it only makes sense to adapt your transactional email for marketing, to take advantage of this unparalleled opportunity to reach your customer with a personalized offer. Read the rest of this post.

SSL versus TLS

TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications and servers in scenarios where that data is being sent across an insecure network, such as checking your email (How does the Secure Socket Layer work?). The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1. With this said though, is there actually a practical difference between the two?

See also our Infographic which summarizes these differences.

Read the rest of this post.

If you are a healthcare organization and have to abide by HIPAA regulations, you may be struggling with HIPAA-compliant email marketing.  Besides getting patient consent, there is the whole concern that the marketing email messages need to be secured, as in many cases the marketing messages plus the addresses or list being used imply something about the recipients … something ePHI-related.

It is a best practice to use a HIPAA-compliant email marketing service to send healthcare-related email marketing messages, newsletters, appointment reminder emails, etc.  Such a service signs the required HIPAA Business Associate Agreement with you, takes care of your data, and ensures that your email messages go securely to your recipients.

Read the rest of this post.