" tls Archives - Page 2 of 10 - LuxSci

Posts Tagged ‘tls’

8 Ways to Maximize Email Throughput: Send More Email, Faster

Tuesday, September 5th, 2023

Sending high volumes of email messages is more complex than sending a quick message to a colleague. To reach a large contact list in a timely manner, it’s essential to understand ways to maximize email throughput. In this article, we lay out eight best practices for sending more emails faster.

person sending emails on laptop

1. Use Concurrent Connections

When sending an email message, the emailing program connects to the servers, establishes its identity, and passes the message through. When sending emails in bulk, connecting to the server can take up a lot of time. For example, if you send 1,000 messages, the program must connect to the server 1,000 times. Many sending programs can be configured to make more than one connection at a time. If you make ten connections simultaneously (e.g., concurrently), you could send those messages about ten times faster. That is a significant speedup.

However, you don’t want to make too many concurrent connections. The more connections you make at once, the harder the server must work to process the mail. The server will become overloaded at some point, and the average time to send a message will increase. You want to avoid pushing the server to the point where it struggles to keep up with sending, as that will only make it operate slower. Instead, use a modest number of concurrent connections to take advantage of parallel sending and allow the server to efficiently process all the messages.

We recommend keeping concurrent connections to ten or fewer if you use public cloud servers and share capacity with other bulk senders. Single dedicated servers can support between 20-30 concurrent connections (or more depending on the factors discussed below), and dedicated server clusters can support as many as you need (depending on how large a cluster you have).

2. SMTP Pipelining

The next way to maximize email throughput involves utilizing SMTP pipelining. First, let’s look at the regular way messages are sent via SMTP:

  1. Connect to the SMTP server
  2. Establish SSL or TLS encryption, if configured
  3. Authenticate the sender’s identity and permission to send
  4. Upload the list of recipients and message content
  5. Disconnect

When sending small messages, the time taken by steps 1, 2, 3, and 5 is very significant relative to the time it takes to upload the message data. With SMTP pipelining, the connection is reused for successive messages. For example, when sending three messages, the process looks like this:

  1. Connect to the SMTP server
  2. Establish SSL or TLS encryption, if configured
  3. Authenticate your identity and permission to send
  4. Message 1: Upload the list of recipients and message content
  5. Message 2: Upload the list of recipients and message content
  6. Message 3: Upload the list of recipients and message content
  7. Disconnect

Not repeating the connect-authenticate-disconnect steps for every single message saves time and sends messages faster. SMTP pipelining should always be used if supported by your email-sending program and outbound email service.

3. Multiple Recipients in One Message

Imagine sending the same message to 1,000 recipients. If you send these one at a time and it takes one second to process, it takes almost 20 minutes to send 1,000 messages. Instead, if you include all recipients in the BCC line of a single message, it will take only about 1-2 seconds to upload the message to the server (though it will still take the server some time to deliver it to those recipients).

Sending messages to multiple recipients using BCC allows you to upload messages to the server much faster.

There are two downsides to this method:

  1. The received message may appear more SPAM-like since the recipient would not see their email address as the “To” recipient. BCCs are more SPAM-like than messages individually addressed (because it is so much easier and faster to send this way).
  2. A single message sent to 1,000 recipients may take longer to be delivered as the mail server will not generally parallelize delivery to the recipients but will process them sequentially. This may not be important if the delivery time is not time-sensitive.

LuxSci’s Secure High Volume service allows you to send to up to 1,000 recipients in each message. Customers with dedicated servers and clusters can have this limit increased to suit their business needs.

4. Smaller Messages are Better

A significant factor in maximizing email throughput is reducing the time it takes to upload each message to the server. To see the difference, let’s look at an example — sending a one-megabyte PDF to 1,000 people in 1,000 separate messages.

Case 1 – The PDF is attached to the message, and it takes ten seconds to upload the large message to the mail server. It takes 10,000 seconds (almost 3 hours) to send 1,000 messages with the attachment (unless you use some of the other strategies for maximizing throughput mentioned above).

Case 2 – The PDF is placed on a website, and a link is included in each message. The email message is only ten kilobytes (100 times smaller than in Case 1) and can be sent about 100 times faster. That’s less than 2 minutes without any other optimization.

As you can see from the example, it is best to remove images and other attachments from bulk messages to decrease the message size. Images can be hosted on a website and displayed in the message by linking rather than including the image content every time. Attachments that are not sensitive can be similarly hosted on a website and linked to. Reducing the size of your email messages significantly impacts sending speed and helps maximize email throughput.

5. Clean Mailing Lists are Important

Email messages should only be sent to contacts who have opted into communications or with whom you have established business relationships. These are the standard terms for using any reputable bulk mailing service.

Even if you follow the rules, mailing lists get stale as people change addresses, domain names go defunct, etc. Removing invalid addresses and only sending messages to clean mailing lists is imperative. Why?

  • Bad Domains. Sending an email to an email address whose domain name is no longer valid can delay sending while the program determines if the domain is bad. Determining that the domain is good and the email should be delivered takes less time. The delay caused by expired domain names can slow down your sending.
  • Defunct Addresses. Sending emails to invalid email addresses looks like spamming. Recipient servers like Yahoo!, AOL, McAfee, etc., are very sensitive to the number of messages that come through to defunct email addresses. If they see a lot of these, they will either block emails or slow down the rate at which they process them. This will result in more delays and potential non-delivery to valid recipients.
  • Waste of Time. Attempting to send messages to invalid recipients also wastes time and money.

You should take advantage of tools available to track what recipient email addresses are failing and actively remove them from your mailing lists.

6. Insecure Sending is Faster than Secure

While encrypting your username, password, and message contents is always recommended, this encryption will slow down email sending. It requires extra processing by the server and the sending machine. Using encryption also requires more bandwidth to transmit the data.

So, if you want to maximize email throughput, we recommend not using TLS or SSL when connecting to your bulk SMTP server. However:

  • Ensure that the username and password used to authenticate the message sending is not used for anything else. It is not your administrator user, the password is not one of your “standard” passwords, etc. You must assume that this username and password could be compromised.
  • Do not grant this user any permission except for sending emails. At LuxSci, you can restrict it from using the web interface and any other services.
  • Change the password often- weekly is recommended.
  • Use tools to check that no one else is using this credential to connect to your SMTP service. LuxSci provides alerts and reports about logins, which you can use to be sure that no one else is accessing this user account.

If the credentials are compromised, and you have followed these guidelines, the worst thing that could happen is that someone could send email through your account until you change the password or hit your sending limits.

7. Use an Appropriate Email Program

Many programs that are good for regular email sending are terrible for bulk email messages. Don’t bother trying to use Outlook, Thunderbird, Apple Mail, Gmail, and similar programs to send high volumes of email if you are interested in sending speed or efficiency. Why? Such programs:

  • Generally, do not support concurrent connections
  • Might not support SMTP pipelining
  • Cannot efficiently handle large mailing lists (more than hundreds of recipients)
  • Get bogged down and can be very slow when sending many messages

These programs are not designed or optimized for high volume sending. Instead, use a program explicitly designed for bulk mailing, like LuxSci’s Secure High Volume or Secure Marketing, which supports maximizing outbound email throughput in the ways outlined above.

8. Increase Capacity

If you try the above solutions and still need faster delivery times, you may need to increase your outbound server’s sending capacity. At LuxSci, we offer tiers of capacity that allow you to create a fully custom solution to meet any throughput requirement:

  • Shared – Your account shares a single server with multiple other accounts. The server’s capacity is shared, and your sending throughput (i.e., maximum concurrent connections, maximum recipients/month, etc.) is restricted to maintain enough capacity for other customers. Your outbound IP reputation is also shared with others.
  • Dedicated – A dedicated server gives you complete control over the sending server resources and IP address. You get all the capacity to yourself and thus can attain a much higher throughput. Your IP address is not subject to other customer’s actions to help you maintain a good reputation.
  • Cluster – A dedicated server cluster may be a good solution if you need to send many messages very quickly. It consists of two or more outbound servers behind a load balancer. The more servers you put in the cluster, the higher your throughput can be. Another benefit of a dedicated server cluster is having multiple sending IP addresses for reputation management and failover to make your sending more resilient.

Which option is best? It depends on the number of recipients you want to reach per month. Also, if you need to send to large numbers of recipients in a very short time frame, you may need a dedicated or cluster solution. LuxSci’s team of email experts can help design the correct configuration to suit your throughput requirements. Contact us today to get started.

How to Secure SMTP Email Delivery with TLS

Tuesday, August 29th, 2023

Secure email sending is a priority for organizations that communicate sensitive data externally. One of the most common ways to send secure emails is with SMTP TLS. TLS stands for Transport Layer Security and is the successor of SSL (Secure Socket Layer). TLS is one of the standard ways that computers on the internet transmit information over an encrypted channel. In general, when one computer connects to another computer and uses TLS, the following happens:

  1. Computer A connects to Computer B (no security)
  2. Computer B says “Hello” (no security)
  3. Computer A says, “Let’s talk securely over TLS” (no security)
  4. Computers A and B agree on how to do this (secure)
  5. The rest of the conversation is encrypted (secure)

In particular:

  • The conversation is encrypted
  • Computer A can verify the identity of Computer B (by examining its SSL certificate, which is required for this dialog)
  • The conversation cannot be eavesdropped upon (without Computer A knowing)
  • A third party cannot modify the conversation
  • Third parties cannot inject other information into the conversation.

TLS and SSL help make the internet a more secure place. One popular way to use TLS is to secure SMTP to protect the transmission of email messages between servers.

hands on a keyboard sending secure email

Read the rest of this post »

HIPAA-Compliant Secure Email: Understanding Encryption

Tuesday, August 15th, 2023

Email encryption is an important topic to understand when evaluating HIPAA-compliant, secure email vendors. Encryption is an addressable standard for HIPAA compliance, but if you send sensitive information via email, encryption is the easiest way to meet the standard.

The two most common email encryption methods include SMTP TLS and Secure Portal Pick Up. This article will discuss their differences and guide users on selecting the right option for HIPAA-compliant secure email.

secure email sending

Read the rest of this post »

How to Overcome Email Encryption Challenges

Thursday, July 13th, 2023

If your business transmits sensitive information via email, encryption is often required to meet compliance standards. However, if encryption is difficult to use, employees and recipients alike may avoid secure channels and communicate sensitive information insecurely. Email encryption technology must be intuitive for employees to use and easy for recipients to decrypt to encourage adoption. In this article, we explore some of the main issues with email encryption and how to address them to improve the user experience.

man looking at computer frustrated by email encryption

Decrypting Messages is Too Difficult

If it’s challenging for recipients to decrypt messages, they go unread or deleted. Most users will not install new software or create new accounts to read an email message. They will delete the message and move on with their day. Encryption technologies like PGP and S/MIME are highly secure, but with that security comes a lack of usability. It’s essential to evaluate the message contents and select a level of encryption corresponding to the message sensitivity.

The User Experience is Poor

If reading encrypted messages requires the user to visit other websites, log in to other accounts, and verify their identity multiple times, it creates a poor user experience that drives individuals outside of secure channels to communicate. This defeats the purpose of using encrypted email and leaves people unsatisfied.

Email Encryption Technology isn’t Error-Proof

How many times have you forgotten to include an attachment when sending an important email? For users who need to send encrypted emails, remembering to type a keyword or press a button to enable encryption introduces risk, interrupts business processes, and generally limits productivity.

How to Improve the Email Encryption Experience

To address some of these issues, let’s look at a few ways that you can improve the email encryption experience for both senders and recipients.

Use TLS Encryption

Instead of using a secure web portal or exchanging S/MIME and PGP keys, use TLS as often as possible to encrypt emails. TLS is sometimes called “invisible encryption” because it provides a barely noticeable encryption experience for recipients. Emails sent with TLS encryption appear just like regular emails in the recipient’s inbox and do not require any additional steps to decrypt. TLS encryption is sufficient for most compliance requirements, including HIPAA, which makes it an excellent choice for many email communications.

Make Encryption Decisions Automatic

TLS is supported by over 80% of email clients, which means it’s appropriate in most situations. But what happens when TLS cannot be supported? For many encryption providers, that means they send the email without any encryption at all. For customers with compliance requirements, this is not an option. By choosing an email encryption provider like LuxSci, you can configure your encryption settings to automatically select a form of encryption that is compatible with the recipient’s email client. For example, if the recipient does not support TLS encryption, the email would be sent to a secure web portal to protect it. Users don’t have to run tests or make the right choice; LuxSci’s tool automatically chooses the right encryption option based on your configuration and the recipient’s settings.

Take Technology Choices out of Employee Hands

Make encryption opt-out instead of opt-in. By encrypting all emails automatically with TLS, employees do not need to decide if an email needs to be secured. As discussed above, TLS provides a user experience just like regular email, so it does not make it more challenging for the recipient to engage with messages. Encrypting all emails as a matter of policy reduces risk and does not slow down workflows.

Administrators can allow users to opt out of encryption if they choose to. This added step requires employees to think carefully about the message contents and ensure they are not sensitive before sending.

Conclusion

Email encryption does not have to be difficult to use. It’s possible to securely exchange information via email without negatively impacting the user experience. To learn more about how LuxSci’s SecureLine email encryption can help you protect sensitive data at scale, contact us today.

Infrastructure Requirements for HIPAA Compliance

Thursday, December 1st, 2022

If you are building a new environment that must comply with HIPAA, you may be surprised to find that the infrastructure requirements for HIPAA compliance do not require the use of any specific technology. This provides a lot of flexibility for developers and architects but can also introduce risk if you are unfamiliar with the requirements. This article outlines a few considerations to keep in mind as you build a HIPAA-compliant infrastructure or application.

infrastructure hipaa requirements

Dedicated Servers and Data Isolation

Reliability and data security are two of the most important considerations when building a healthcare application. Building an infrastructure in a dedicated server environment is the best way to achieve these aims. Let’s look at both.

Reliability

Hosting your application in a dedicated environment means you never have to share server resources with anyone else, and it can be configured to meet your needs exactly. This may also include high-availability configurations to ensure you never have to deal with unexpected downtime. For many healthcare applications, unexpected downtime can have serious consequences. 

Security

A dedicated environment isolates your data from others, providing an added security layer. Segmentation and isolation are crucial components of the Zero Trust security stance, and using a dedicated environment helps keep bad actors out. Hosting your application in a public cloud could put sensitive data at risk if another customer falls victim to a cyberattack or suffers a security incident.

HIPAA does not require the use of dedicated servers. Still, any host you choose must follow the HIPAA requirements associated with access controls, documentation, physical security, backups and archival, and encryption. Review our checklist for more details about HIPAA’s security requirements.

Encryption

It’s worth spending a minute discussing encryption because it’s an often misunderstood topic. Encryption is listed as an “Addressable” standard under HIPAA. Because it is not “Required,” this leads many to think that it is optional. The Rule states: “Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.” So, while HIPAA does not state that covered entities must use encryption, it does say that they need to ensure the confidentiality of any ePHI that is created, received, maintained, or transmitted.

The confusion arises because HIPAA is technology-neutral and does not specify how exactly to protect ePHI. Encryption is unnecessary if your organization can devise another way to protect sensitive data. However, practically speaking, there aren’t many alternatives other than not storing or transmitting the data at all. Encryption is the easiest and most secure way to protect electronic data in transmission and at rest.

At-Rest Encryption

HIPAA does not require at-rest encryption, though it is recommended to decrease risk and potential liability in some situations. Suppose your risk assessment determines that storage encryption is necessary. In that case, you must ensure that all collected and stored protected health information is encrypted and can only be accessed and decrypted by people with the appropriate keys. This makes backups secure, protects data from access by unauthorized people, and generally protects the data no matter what happens (unless the keys are stolen). Storage encryption is essential in any scenario where the data may be backed up or placed in locations out of your control. 

Transmission Encryption

If protected health information is transmitted outside of the database or application, encryption must also be used to protect the data in transmission. At a minimum, TLS encryption (with the appropriate ciphers) is secure enough to meet HIPAA guidelines. However, TLS alone may not be appropriate for your use cases.

  • Consider using a portal pickup method, PGP, or S/MIME encryption when transmitting highly sensitive information to end users.

Backup Infrastructure Requirements for HIPAA Compliance

Backups and archival are often an afterthought regarding HIPAA compliance, but they are essential. HIPAA requires that organizations “Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.” You must be sure that all ePHI stored or collected by your application is backed up and can be recovered in case of an emergency or accidental deletion. If your application sends information elsewhere (for example, via email), those messages must also be backed up or archived. HIPAA-compliant backups are robust, available, and accessible only by authorized people.

Under HIPAA Omnibus, organizations must keep electronic records of PHI disclosures for up to three years. Some states and company policies may require a longer record of disclosures; some states require up to ten years. When building a HIPAA-compliant infrastructure from scratch, it’s also essential to build backups.

Conclusion

If it is your first time dealing with infrastructure requirements for HIPAA compliance, be sure to ask the right questions and work only with vendors who thoroughly understand the risks involved. It can be overwhelming, but by selecting the right partners, you can achieve your goals without violating the law.