Email

Last updated August 14, 2017 to reflect security improvements.

We often get questions similar to this one:

I have been struggling to send and receive mail consistently since acquiring Apple/Mac products. Would you please see attached reference sheet and make sure I have filled everything in properly.

In order to provide a clear answer, I want to ignore the form you got from the Apple support people.  All you need to do is select protocols and then provide the necessary information for them.  The form lists all the protocols, then separately lists port numbers and settings.  This is incoherent.  Port numbers go with protocols.  Using a particular protocol implies a port number and vice versa.

Getting set up is easier when you understand what the protocols are and why you might select each of them.  The configuration follows on from there.

Recommended settings (for the impatient)
Server, both incoming and outgoing:  mail.YourDomain.com (use your domain name)
Incoming protocol: IMAP Port number: 993 – SSL/TLS – accept all certificates
Outgoing protocol: SMTP Port number: 587 – start TLS – accept all certificates
Login: full email address – Required

Some email clients repeatedly pop up warnings or errors related to server names or certificates.  This is because they are seeing a security certificate with the name of the server, not the server name you provided.   Old, obsolete email client software can’t request the certificate for your domain name.  If at all possible, switch to modern software or update what you are using.  Old software tends to contain security vulnerabilities and is best avoided.  If this is not possible, you will have to use the server name instead of your domain name to silence the warnings.

Our servers are 100% standards compliant and will immediately work with any device which uses standard values as defaults.  This means all you should need to do is select a protocol and then accept the defaults.  Unfortunately, sometimes the software fails to offer a value or offers something bizarre.

Email has 2 entirely separate parts. Interacting with a server which contains delivered email is one part.  The other part is sending email.  There is nothing in common between them other than the term and file object, “email”.  As you can see just above, I am suggesting IMAP for handling emails delivered to you and SMTP for sending.  First we will discuss delivered email (email waiting for you), then we will discus sending email.

Common Email Protocols

A protocol is a set of rules which defines how computers communicate with each other.  It’s how each machine knows what to expect from the other.  It’s easier to follow descriptions like this when you have some idea what the acronyms stand for.

IMAP – “Internet Message Access Protocol”
IMAPS – “Internet Message Access Protocol” – Secured (encrypted)
POP3 – “Post Office Protocol” version 3
POP3S – “Post Office Protocol” version 3 – Secured
SMTP – “Simple Mail Transport Protocol”
SMTPS – “Simple Mail Transport Protocol” – Secured
SSL – “Secure Sockets Layer”
TLS – “Transport Layer Security”
DNS – “Domain Name Server (or System)” – name to address translation
DNS MX – An entry in the DNS system which provides email routing information.

The Internet is all about connectivity, so there is a seemingly endless list of acronyms and protocols.  If you are interested in understanding more about how things work, read the page titled, “The Internet – Technical Basics” above.  Understanding goes a long way to making things easier.

The potential exists for the setup process to be simpler than it is in practice.  There are clearly defined standards for a client machine to connect to a server, request a particular protocol and even switch over to an encrypted connection.  Our servers support this.  Often,  the programmers who wrote the device software were too ignorant to take advantage.  Even if the programmers got it right, the documentation and support people remain clueless.  We are stuck doing it the hard way.  Apple devices, known for excellent user interfaces, remain strangely ignorant.

Picking up email

To interact with a server which has your email, there are many options.  The 2 common choices are IMAP and POP3.  Both can be used encrypted or not encrypted.  That makes 4 sets of settings.  That may sound complicated, but it’s actually simple.

Once your computer (the client machine) makes a connection to a server, it requests a particular port number.  The port number selection is what tells the server which protocol you want to use.  If you tell your client software to use IMAP with a POP3 port number, it’s not going to work.

1) IMAP – not encrypted
Protocol: IMAP
Port number: 143

2) IMAPS – encrypted “secure IMAP” – I suggest you use this.
Protocols it uses: IMAP, IMAPS, SSL, TLS
Port number: 993

The IMAP protocol is more advanced and has many more options than the POP3 protocol.  In a default configuration, your device  (even a web browser)  will first see only the header values.  Headers in email parlance are the metadata, From, To, Subject, delivery and other information describing what an email contains.  The actual content is not displayed or downloaded until you explicitly ask for it, for example by clicking on it.  By default, email will stay on the server until you remove it.

When you use IMAP, email can be organized into folders.  In a default configuration you generally get an Inbox folder, a Sent folder and a Trash folder.  You can add new folders and move email from folder to folder to keep it organized.

Within each folder, but not visible to you are 2 sub folders, “new” and “cur” (for current).  Email is delivered to “new” and as soon as you first see the headers, it is moved to “cur”.   Some devices show you only what was in “new” in the Inbox.  Generally, you can change what they show you.  When you connect later and don’t see what you saw earlier, nothing has disappeared from the server.  Your email software is simply not showing it to you.

To delete mail from the server when using IMAP, you need to purge or “empty the trash”.  We commonly see accounts go over quota because the owner never emptied the trash.   Permanently deleting email is a 2 step process: delete then purge.

3) POP3 – Post Office Protocol – not encrypted
Protocol: POP3
Port number: 110

4) POP3S – Post Office Protocol – encrypted
Protocol: POP3S
Port number: 995

The POP3 protocol is much older and much simpler.  In the default configuration, all email is downloaded to you when you connect and then deleted from the server.  On a phone or other small device, you almost certainly want to use IMAP.  You don’t want to get stuck waiting for a big attachment to download over a slow link.  Using IMAP you can defer looking at those emails until you are using a larger and probably faster device.

That’s receiving. Sending email can be done using IMAP, but that’s not widely used. Our servers support it, but I suggest you use SMTP.  It’s simpler.

Sending Email

Protocol: SMTP – I suggest you use SMTP for sending.
Port number: 587 or 26

The standard port number for SMTP is 25, but many service providers block port 25. They do this because it is easy to set up a mail server and start sending spam everywhere.  There is apparently an endless supply of people who believe they can make money this way.  As a work-around, our servers listen on additional ports.   Port 587 is the “mail message submission” port, which is the standard work-around.   Some poorly written and non standards compliant software (notably Microsoft Outlook) cannot be configured to use port 587.  This is why we listen on port 26 as well.

Long ago, sending email using an encrypted connection required connecting on a separate port number.  There is outdated documentation floating around which describes how to do this using port 465.  If you encounter references to port 465 in email client documentation or elsewhere, you are reading about antique software. Don’t use it.

For BOTH Receiving and Sending

Your login name is your email address.  You MUST log in.  Inexplicably, some client software assumes that you do not need to log in.  If you have problems sending, this is the most common cause.  Find and check a box labeled something like, “My server requires authentication”.

The server to connect to is mail.YourDomain.com in all cases. Replace “YourDomain.com” with your actual domain name.

Incorrect Default Server Names

It is very common for email client software (running on your device) to make bad assumptions about server names.  It may offer defaults like IMAP.yourDomain.com or SMTP.yourDomain.com.  Unless explicitly created (by you) via DNS zone file setup or editing, they do not exist and will not work.   Sometimes DNS MX values are looked up and offered.  A DNS MX record specifies where to route mail to get to your account, but is not necessarily where email is finally delivered to you.   Do not use MX values.  They will not work.

Certificates

Encryption certificates serve 2 purposes:  to verify the identity of what you connected to; providing encryption keys.   The name on the certificate is that of the server, not mail.YourDomain.com.  This means you must override the warning (or check a box) to accept the certificate.  You could purchase a certificate and have us set it up for you, but there is no necessity to spend the extra money for this.

Occasionally we move accounts from one server to another.  Your email client will continue to connect to the correct server as long as you use mail.YourDomain.com.  You can use the server name to avoid the certificate warning, but this would cause a problem the next time your account is moved to a new server.  By then the problem is likely to be a mystery and require detective work to solve it.

Using an encrypted connection provides a slight security enhancement. I dislike this because people tend to think it is doing more for them than it is. It’s a false sense of security.  If you have a reason other then not providing your password over a clear connection, please read this:  https://blog.deerfieldhosting.net/encrypted-email-or-is-it/

We use a separate mail server to provide better performance and redundancy.  Email is delivered there and held for 3 days so that it is available to you even if your hosting server account is unavailable.  You can use web based email on it if you need to.

Backup Mail Server

This is a highly summarized overview.  If you have questions or comments, please ask them!

We are often asked about certificate warnings which pop up in email clients.  When an account is moved to a new server, there is a new certificate and a new warning often appears.  In answer to a question about this:

It’s safe to accept the certificate.  We moved your accounts to a newer faster server a few days ago.  We had been using a wildcard certificate, but that was causing problems for people running software too dumb or too conservative to work with such a certificate.  It seemed like an appropriate time to switch.

Email client software often sets up TLS (encrypted) connections by default.  It makes people think sending stuff via email is secure, adding yet another misconception to the rampant ignorance.  It’s not secure.  Email is a store and forward system.  That means your message may cross the network encrypted, but it is then stored unencrypted on the target mail server.  It frequently passes through many servers before being delivered.  It’s trivial for an administrator of any of those servers to keep a copy – not encrypted.

The security of your message is in the hands of those administrators.  You will almost never even know who they are.

Nearly it’s only virtue is that your password is sent over an encrypted connection.    It also means that when someone at the NSA wants to read it, he will have to spend a few minutes on a powerful computer to decrypt it first.  If you want more secure email, you need to encrypt the content, not just the connection.  If you don’t want the NSA or anyone else reading your email at all, you’re basically out of luck.

Content encryption is good enough to deter most criminals and casual snoopers.  Unfortunately, a really sophisticated criminal can still decrypt it.  But you don’t need to worry about this too much unless you know that your content has a very high value to such a person.  If you make it even a little hard, they will move on.   There is no shortage of easy targets.

The bottom line is: encrypt the content if you need security.  That said, there are better ways to transfer sensitive information than via email.  There’s no reason to allow it to have such a high profile.  Virtually all cases of hacking are the result of gaping stupid security holes, someone incompetent in charge of security.

Don’t be lulled into the idea that great big rich companies automatically have high quality correctly configured Internet service. It is very common for outbound email service to be incorrectly configured.

A big part of the problem is that Microsoft email servers are configured incorrectly out of the box. They work correctly in the common cases and testing frequently stops there. At that point they will not use a backup or secondary email server AND they fail to keep things on a queue for a few hours to work around temporary failures as the standards dictate.

It is virtually impossible for your inbound email service to be completely down. There are 2 servers in different data centers capable of receiving mail. Yet, I commonly get reports of bounced email when our main mail server is off line. There is absolutely no excuse for that because the secondary is available.

Next time anyone, and especially a Great Big Company, tells you they couldn’t get an email to you, demand that they send you a copy of the mail with the failed headers. I can almost guarantee they will reveal a configuration error on their server. It’s only by pointing out their problems that they will become aware of and correct them. They should want to know they have a problem.

The content of your emails is not as secure as you may think it is.

When you set up an email account on your computer (or tablet or phone) you have the opportunity to specify encrypted connections. The trouble is, email is a store and forward system. Unless you know every server your mail will traverse, you can’t know that it will be transmitted encrypted from server to server.

You are also subject to trusting the mail server administrator of each server it traverses, sometimes as many as 4 or 5. While the transmission from your machine to the first server may be encrypted, subsequent transmissions may not be.  What is more, at each server it will be stored in plain text format.  It is trivial for any mail server administrator to retain a copy of your emails.  It is also trivial to scan plain text files looking for key words such as the word, “password”.

If you want what is in your email to be secure, what you need to do is encrypt the content, not just the connection.

One commonly used tool for this purpose is PGP. That stands for “pretty good protection”.  Encryption is a huge subject, but there tools in the cPanel control panel to help you get this done.  More information about PGP and this subject in general can be found HERE.

Having said all that, there is still 1 good reason to set up secure (encrypted) connections from your email client to your hosting server: passwords.  Secure connections are established before your password is sent and that means it is sent encrypted and not as plain text.

Setting your email client (MS-Outlook, Windows mail, Thunderbird, etc.) to check email too often is abuse. Sometimes it’s accidental abuse. It’s common for unstable programs like Microsoft Outlook to become corrupted and go wild, checking incessantly.

Recently we implemented a system to track (among many other things) email logins. When too many logins to a specific email account exceed limits, the IP address the logins are coming from is temporarily blocked. The reason for doing this is performance. Our servers typically have 5,000 or more email accounts on them. 20 or 30 abusive accounts is not a large percentage of the total, but can significantly reduce performance for everyone using a server.

If your ability to send and receive email is experiencing intermittent problems, this may be the reason. We can check this for you if you submit a trouble ticket. Our ticketing system automatically includes your public IP address which we need to do this. Click on “Orders – Tickets” above left, then “Submit Ticket”.

All this begs the question, why you are doing this in the first place. All you really need to do is click on the send/receive button in your email client and you will have your email. If you have a broadband connection, which is most often the case, you will almost certainly have your email within 2 seconds. Most people who have automatic checking turned on will do this anyway! If you have a slow connection, by all means do automated checking to save yourself some time.

Otherwise, wouldn’t you rather see faster performance of your server? If you actually think you have another reason for automated checking, let’s hear it!