" servers Archives - LuxSci

Posts Tagged ‘servers’

Dedicated Servers: How They Improve Security And Reliability

Tuesday, December 8th, 2020

What’s best for your organization, shared or dedicated servers? If your company is looking for website hosting, an email provider, or hosting for other online services, this question may not be high up on its list of priorities. The differences between shared and dedicated servers may not seem particularly important at first. However, this choice could have significant security and reliability ramifications.

Many providers will steer you toward shared servers, or only provide a “shared cloud,” even though these may not be in your company’s best interest.

Dedicated Servers


It’s more efficient and cost-effective for them to lump a bunch of their customers onto the same server. This makes it easier to manage and reduces the provider’s overhead expenses. Your provider’s cost-savings and ease-of-administration probably aren’t your organization’s greatest concerns. Instead, you should be more worried about the additional risks and complications that shared servers can bring to your business.

While dedicated servers can be a more expensive option, the security and reliability benefits they provide make it worthwhile.

Security of Shared vs Dedicated Servers

Let’s say your website is hosted on a shared server, along with a bunch of other websites. For the sake of this example, let’s also presume that you are exceptionally diligent. All of your software and plugins are always updated as soon as possible, you have strong passwords, two-factor authentication, and suitable access control policies. You have regular security audits, and any issues that pop up are immediately rectified. Your site is essentially Fort Knox and meets compliance requirements.

But what about the sites that you share your server with?

You have no control over them, and can’t enforce the same security precautions that your organization does.

Well, that’s their problem, right?

It is, but it could very easily become your problem as well. There are a number of situations in which things could go badly for your organization as well.

Security Risks on Shared Servers

  • One or more of the other websites may be highly vulnerable. Whether through neglecting their updates or other poor security practices, they may be easy to infiltrate. If hackers can compromise one site on the server, it can give them a window into the others. This means that sharing a server significantly increases your own risk of data breaches. Cybercriminals may even target your site deliberately by looking up others that share the same IP address.
  • Malicious actors may set up their own sites on your shared server, with the sole intention of using this access to penetrate the other sites. This can also result in your organization’s website and database being breached.
  • You may share the server with a high-value target, such as a political activist or journalist. If they raise the ire of others, they could fall victim to a DDoS attack. Not only could this prevent legitimate visitors from accessing their website, but it could use up the shared resources, and prevent others from visiting your site.

These examples around web hosting also apply to other services such as email hosting, video conferencing, payment processing, online chat, etc. It is always a better and more secure choice to isolate your services and data from others to the maximum degree possible.

While shared servers can be the more economical option, particularly for those with limited needs, you also need to weigh these savings against the potential threats that come from any of these attacks. Is the possibility of suffering an attack, as well as the costs, damage to your organization’s reputation and stress worth the slight reduction in price?

If you use a shared server, it takes control out of your organization’s hands.

Reliability of Shared vs Dedicated Servers

If your organization uses a shared service, it shares resources with other organizations provisioned on the same shared server(s). The disk space, disk throughput, memory, network capacity, and processing power are all split or shared between the various parties.

This isn’t necessarily a problem—unless one of the other customers starts consuming all of the resources. If you shares a server with one of these bad neighbors, the strain can cause your services to slow down, or even become unavailable. In practical terms, this could result in your website being down, your email inaccessible, an inability for your employees to send messages, of your video teleconferencing system malfunctioning.

If a bad neighbor sends out email spam, that activity can also get the whole shared server or shared IP space blacklisted. This can result in your company’s emails going straight to spam, even when it has done nothing wrong. The reliability of your email sending and the successful inbox delivery of your messages depend on others when using shared resources.

LuxSci’s Dedicated Server Options

You can avoid facing these security and reliability issues through segmentation and isolation. LuxSci provides a range of options to suit a variety of different needs. These include giving clients:

  • Their own dedicated server(s) that are firewalled off from other customers.
  • Their own network segment with dedicated physical or network firewalls. These can be customized according to an organization’s needs.
  • Their own dedicated physical hardware, which means that even virtualization hypervisors aren’t shared between customers.

These options give our clients the flexibility they need to meet their organization’s unique requirements. Pursuing one of the above options will mean that your organization won’t have to worry about the threats or reliability problems that sharing a server can bring. LuxSci is HITRUST CSF certified and specializes in building custom, highly secure web environments designed to meet our customers’ needs.

Learn more about LuxSci’s dedicated server options: Schedule a Consultation

Maximize Your Outbound Email Throughput: How to Send More Email, Faster

Tuesday, July 24th, 2012

Customers of our Secure High Volume bulk outbound email service often ask how they can “send faster.” They want to get their mailing out ASAP, no matter if it is to hundreds or millions of recipients.

This post codifies all of the various types of advice we give for optimizing outbound email throughput. Much of it applies to outbound email sending over SMTP in general — i.e. its not limited to the LuxSci Secure High Volume service.

Use Concurrent Connections

When sending an email message, your emailing program connects to our servers, establishes your identity, and passes the message through. If you have to send 1000 messages, then you might connect 1000 times to do this. Many sending programs can be configured to make more than one connection at a time. If you make 10 connections at once (e.g. concurrently), then you could send those messages about 10 times faster. That is a really significant speedup!

Don’t make too many concurrent connections, however! The more connections that you make at once, the harder your server has to work to process the mail. At some point, the server can get so busy and overloaded that the average time to send a message starts getting longer and longer. You never want to push your server to the point where it is struggling to keep up with your sending, as that will only make things slower for you. Instead, you want to use a modest number of concurrent connections so you can take advantage of parallel sending and so the server can easily and efficiently process all of the messages.

For shared High Volume accounts, where you are sharing capacity with other bulk senders, we recommend keeping your number of concurrent connections to 1o or less. Single dedicated servers can support 20-30 concurrent connections (or more depending on many factors discussed below), and dedicated server clusters can support as many as you need (depending on how large a cluster you have).

SMTP Pipelining

Your email program sends a message by:

  1. Connecting to your SMTP server
  2. Establishing SSL or TLS encryption, if configured
  3. Authentication to establish your identity and permission to send
  4. Uploading the list of recipients and message content
  5. Disconnecting
When sending small messages, the time taken by steps 1, 2, 3, and 5 are very significant relative to the time it takes to upload the message data.  With SMTP Pipelining, the connection is reused for successive messages.  I.e. when sending 3 messages, it would look like:
  1. Connecting to your SMTP server
  2. Establishing SSL or TLS encryption, if configured
  3. Authentication to establish 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. Disconnecting
By not repeating the connect-authenticate-disconnect steps for every single message, a lot of time in saved and your messages are sent much faster.  SMTP Pipelining should always be used if supported by your email sending program and outbound email service (LuxSci High Volume supports SMTP Pipelining).

Multiple Recipients in One Message

Imaging sending the same message to 1000 recipients.  If your send these one at a time and it takes 1 second to send each one, then that is almost 20 minutes to send.  However, if you instead include all of these recipients in the BCC line of one single message, then it will take only about 1-2 seconds to get the message uploaded to the server (though it will still take the server some time to actually deliver it to those recipients).

Sending messages to multiple recipients using BCC allows you to upload your messages to the server very much faster than otherwise.

There are two downsides, however:

  1. The received message may appear more SPAM-like, since the recipient would not see his/her 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 to 1000 recipients may take longer to be delivered to all of those recipients as the mail server will not generally parallelize delivery to the recipients but will instead process them sequentially.  If the delivery time is not very time sensitive, then this point can be discounted.
LuxSci’s High Volume servers allow you to send to up to 1000 recipients in each message.  Customers with dedicated servers and clusters can have this limit increased arbitrarily.

Smaller Messages are Better

A significant factor in determining how fast messages can be delivered is how long it takes to upload each one to the server.  To see the difference, lets look at an example — sending a PDF to 1000 people in 1000 separate messages.  This PDF is 1 Megabyte in size.

Case 1 – the PDF is attached to the message and it takes 10 seconds to upload the large message to the mail server.  This results in it taking 10,000 seconds (almost 3 hours) to send these messages (unless you use concurrent connections or multiple recipients/message).

Case 2 – the PDF is placed on a web site and a link to it included in each message instead. The resulting email message is only 10 KB in size (100 times smaller) and it is able to be sent about 100 times faster. That’s less than 2 minutes without any other optimization.

It is best to remove images and other attachments from bulk messages to decrease the size.  Images can be hosted on a web site and displayed in the message by merely linking to the image, rather than including the image content every time.  Attachments that are not sensitive in nature can be similarly hosted on a web site and linked to.  Keeping your email message size down will have a big impact on sending speed.

Clean Mailing Lists are Important

Obviously you should only be sending bulk messages to addresses that have opted into your mailings and/or with whom you have established business relationships.  This, and all that is implied, are standard terms for the use of any bulk mailing service.

However, mailing lists get stale as people change addresses, domain names go defunct, etc.  It is very important to cull invalid email addresses off of your lists. Why?

  • Bad Domains. Sending email to an email address whose domain name is no longer valid (e.g. which has expired) can be very slow as it can take much more time to determine that the domain is bad than to determine that it is good and where to deliver the mail.  The delay caused by bad domain names can really slow down your sending.
  • Defunct Addresses. Sending email to now-invalid email addresses looks like spamming.  Recipient servers like Yahoo!, AOL, McAfee, etc., are very sensitive to the number of messages that come through addressed to defunct email addresses.  If they see a lot of these, they will either block your emails, or slow down the rate at which they process them.  This will result in more delays and/or non-delivery to valid recipients.
  • Waste of Time. Obviously, sending messages to invalid recipients also just wastes time and money.

You should take advantage of any and all tools available to track what recipient email addresses are failing and to actively remove them from your mailing lists.  LuxSci provides many such features — including ones which can automatically email you digests of all failing email addresses and which let you create your own reports.

Insecure is Faster than Secure

OK, while encrypting your username and password and message content is always a good thing and always recommended, this encryption will always slow things down to some extent.  It requires extra processing on the part of the server and your sending machine.  It also requires somewhat more bandwidth to transmit all of the data.

So, if you are looking to “eek” out every bit of speed, we would recommend not using TLS or SSL when connecting to your bulk SMTP server.  However:

  • Be sure that the username and password being used to authenticate the message sending is NOT used for anything else.  I.e. 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 email.  In LuxSci, you can restrict it from using the web interface and any other services.
  • Change the password often.  Change the sending user’s password often. I.e. weekly.
  • Use tools to check that noone else is using this user to connect to your SMTP service.  I.e. LuxSci provides alerts and reports about logins (successes and failures), which you can use to be sure that no one else is accessing this user account.
In the worst case scenario, if you have followed these guidelines, the username could be only used to allow someone to send email though your account until you next change your password or until you hit your sending limits.

Use an Appropriate Email Program

Many programs that are good for regular email usage are terrible for sending email in bulk.  E.g. don’t try to use Outlook, Thunderbird, Mac Mail, and similar programs to send bulk mail if you are interested in sending speed or efficiency. Why?  Such programs
  • Generally do not support concurrent connections
  • Might not support SMTP Pipelining
  • Cannot handle large mailing lists (e.g. more than 100s of recipients) well
  • Get bogged down and can be very slow when sending many messages
They are just not designed for it or optimized for it.  Instead, use a program explicitly designed for bulk mailing.  I.e.
  • LuxSci Spotlight Mailer
  • GroupMail
  • Interspire Email Marketer
  • Atomic Mail Sender
  • SendBlaster
  • Email Marketing Director
See our videos on how to set these programs up with High Volume email.

Increase Capacity!

Finally, if you must send to many recipients in a short time, you may need to increase your outbound server’s sending capacity.  At LuxSci there are tiers of capacity:
  • Shared – Your account shares a single server with multiple other accounts.  The capacity of the server is shared and your sending throughput (i.e. maximum concurrent connections, maximum recipients/month, etc.) is more restricted so that you play nice with other customers.  Your outbound IP reputation is also shared with others.
  • Dedicated – This is like “shared”, except that the sending server and IP is yours, and yours alone.  You get all of the capacity to yourself and thus can attain a much higher throughput.  Your IP reputation is also not subject to other customer’s actions.
  • Cluster – When the capacity of a single powerful server is insufficient, a cluster is the perfect solution.  It consists of 2 or more (really, any number) of outbound servers behind a load balancer.  The more servers you put in your cluster, the higher your throughput can be.  As a “side effect”, you also end up with multiple sending IP addresses for reputation management and with fail over so your sending can be resilient against server failure.

Which one should you get?  That really depends on the number of recipients you want to send per month. Also, if you have requirements to send to large numbers of recipients in a very short time, you may need a dedicated or cluster solution even if the overall number of recipients in a month is not excessively large.  Contact us for help in determining the best solution for you.