Skip to main content

Common Linux email problems and how to fix them

Email servers and clients occasionally like to rebel and every sysadmin needs to know how to quell the uprising.
postman with a letter

Image by Pixabay

When working with email, you never know what to expect. The issues that system administrators come across vary from place to place, from person to person, and from server to server. However, there are issues that remain the same everywhere. In my personal experience, I have seen many mailing issues across the board; from millions of spam emails filling up the mail queue and the server’s disk space (and ultimately taking down the server), to phishing emails from hacked websites with honeypots sending emails to other customers on the same network. In this article, we will cover common email problems that occur in the world of system administration.

Email delays

The first thing you want to do when troubleshooting email delays is to get the information you need in order to troubleshoot. Having the information that you need to get started, or at least information to work from, helps you to make an informed decision. Let’s say that there is an email that did not go through to the recipient, or that bounced back to the original sender. The best information to start with is the full email headers of the email that was sent to the original sender. Depending on the mail client you are using, you can gather the mail ID from the mail header in different ways, but it is always available, regardless of the client. Once you have the mail ID, you can search for the ID in the mail logs with the following command:

$ grep 'EMAIL ID' /var/log/exim_mainlog

If you are not familiar with the way the logs are formatted, you could overlook important information. Reading the output logs is definitely something that can require a trained eye and will get easier with experience. Over time, the logs can serve as more than just information, but as a source of truth.

Outlook error codes

Mail clients commonly throw out error codes when things go wrong—and they do go wrong. Outlook can be notorious for this issue, so going over the most common Outlook error codes is a must.

Invalid HELO: 0x800CCC78

Outlook almost always sends an invalid HELO, and as a result, must directly authenticate (vs. the IP auth from checking IMAP/POP) to bypass the check. You receive the 0x800CCC78 error code in this situation. If this error is hit by a client sending email, it’s a result of SMTP authentication not being set up or set up incorrectly. When a user is authenticated, most SMTP checks are bypassed.

The official description from Microsoft states:

Your sender address must be a full email address not simply a username. Please set up your account in Outlook/Outlook Express to use a full account name such as instead of simply 'username'.

Note: An Invalid HELO message is not specific to Outlook. Only the error code is.

The host could not be found: 0x800CCC0D

The full version of this error looks like this:

The host '' could not be found. Please verify that you have entered the server name correctly. Error Number: 0x800CCC0D

If you see this error, there could be a problem with the mail server that the mail client is attempting to connect to. The mail server could be propagating its DNS record, misspelled, or having resolution/network problems. This issue requires investigation of the mail server as a system administrator. As an alternative to the mail server’s domain, you can also use the mail server’s IP address.

The connection to the server has failed: 0x800CCC0E

This error means that there is a problem with the incoming port: port 110 should be used for POP3, and port 143 should be used for IMAP. Separate ports are used for secure connections that require SSL. That information is covered in more depth in A sysadmin’s guide to configuring an email server.

An unknown error has occurred: 0x800CCC69

The full version of this error looks like:

An unknown error has occurred. Subject 'test', Account: '', Server: '', Protocol: SMTP, Server Response: '550 External MTA's must be authenticated in order to send e-mails', Port: 25, Secure(SSL): No, Server Error: 550, Error Number: 0x800CCC69

In this error, it states that the mail transfer agent has to be authenticated in order to send email. That is because mail clients and servers need to verify the source and destinations to avoid being marked as potential spam. In order to do that, the outgoing mail server or client needs to enable authentication, which can be set up in the mail client. Specific settings for Outlook can be found here.

Guess which error: 0x800CCC67

This error code is tricky, as it can mean a couple of different things. If you use port 25 for SMTP, it might be blocked. It is common for mail services and ISPs to block them. The problem could also be another firewall that is installed locally on the sender’s workstation and blocking SMTP connections. Or, Outlook could also just be set up incorrectly. To find the culprit just requires troubleshooting.

SMTP firewall errors

In most shared environments, ports 25 and 26 are blocked for non-root users to prevent abuse. This includes but is not limited to spammy scripts sending excessive amounts of email from the server (resulting in server or IP blacklisting) and email deliverability issues for all clients on the machine.

There are multiple ways around this problem:

  1. Use the Sendmail binary or PHPMailer instead.
    You might choose to use the Sendmail binary or PHPMailer instead. In some cases, you will need to specifically set the FROM setting in the SMTP envelope when using this option. Otherwise, the Sender would be the server’s default email address, not the proper one.
  2. Use the domain or server’s IP as the hostname and port 26 as the outgoing port.
    This setup requires email authentication for the SMTP server and logging in with the username and password. It’s recommended to set the FROM setting here as well. The FROM header is what is normally seen by the receiver (unless the receiver chooses to view full headers).
  3. Whitelist the user in the firewall.
    You can whitelist a user or IP through the firewall. This tactic is only recommended as a last resort. Once the rules are added, restarting the firewall is a good best practice. Adding the user or IP through the firewall will allow them to connect to any host on the available outgoing ports, like 25 and 26.

No such person at this address

Rejections with the error of "No such person at this address," or another custom message, are usually due to a forward being set up to reject email. The regular fail message is "No Such User Here," but some clients use other messages. You can set up custom messages on the mail server and configure them to match what suits the situation best. However, the default seems to work just fine.

SPF rejection

Incoming email is usually checked for a valid Sender Policy Framework (SPF) record when the destination address an authentication checker enabled. Neutral or failed SPF checks result in bounces, which can also have custom messages just like "No such person" errors. All of the rejection messages are customizable. SPF is used to indicate to mail exchanges which hosts are authorized to send mail for a domain. The record is easy to create and works well. There are control panels that allow you to create such a record with a user-friendly tool, or you can make one with an online tool, or create a record from memory.

Email pipes/forwarding

Email pipes need to begin with binary to PHP (e.g., /usr/local/bin/php). This process sends an email message to a program and appends the message to the mailbox file with real-time delivery. Just as with the option of setting up an SPF rejection, you have additional options for how the email pipes can be set up and how they will work. This tactic is at the mercy of wherever the mail server is located.


There are still so many more mailing issues that exist. There is no way to cover them all. This article is meant to give you insight and shine a light into the world of mailing issues, what to look out for, and how to solve them. The most common issue across these different problems is that something will happen at some point, and having authentication is always a good idea.

[ Want more on networking topics? Check out the Linux networking cheat sheet. ]

Topics:   Troubleshooting   Networking  
Author’s photo

Gabrielle Stenzel

I currently work as a Cloud Support Supervisor for Acronis . I have worked with Linux and OpenSource tools for a decade, constantly wanting to make new resolutions for obstacles and always training others on improving systems as a systems administrator. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.