Failure of mail delivery agent, POP3/IMAP retrieval or any similar components may lead to some common email errors in Virtualmin.

Here at Bobcares, our Experienced Server Admins handles several such email errors on a daily basis.

Let us discuss the some common email errors in Virtualmin and their fixes.

 

Where to check for common email errors in Virtualmin

Most failed actions will result in a log action, possibly a very helpful one. Hence, it would be a good idea to look for information in the relevant logs.

On Red Hat, Fedora, CentOS, SUSE, and Mandriva systems, the majority of mail based logging directs to /var/log/maillog. Hence, we need to check the contents of this log to see whatever action is giving the trouble.

The log /var/log/secure may also contain information about failed login attempts, possibly including a reason.

On Debian and Ubuntu systems the mail log is called /var/log/mail.log and will contain similar information as found in the /var/log/maillog

Debian/Ubuntu also have a /var/log/mail.err and /var/log/mail.info which may or may not contain information, depending on the MTA in use and the configuration of syslog.

Our expert techs use various other tools for further troubleshooting the common email errors.

 

Fix Common email errors in Virtualmin

There are several reasons for the email errors in Virtualmin. Some of them are as follows:

1. Incorrect DNS configuration
2. Disabled Spam Filter
3. Problem with Virus Scanner
4. Bouncing With Reverse Resolution Failures
5. Usermin Webmail Sends With Incorrect From: Address
6. No space left on device errors

Furthermore, let’s have a detailed look into these reasons and it’s fix.

 

Incorrect DNS configuration

Most common reason for issues with mail is an incorrect DNS configuration.

Our Support Techs check if DNS works for the problem domain, and returns valid records. In particular, we check the MX record and the name it points to, to be sure other hosts can correctly look up the address of the server.

To test DNS resolution we can use the host and dig commands.

For example:

# host -t mx virtualmin.com 
virtualmin.com mail is handled by 5 mail.virtualmin.com.
# host mail.virtualmin.com 
mail.virtualmin.com has address 70.86.4.226

Here, the first check is for a MX (mail exchange) record, and the second is to check the address the name resolves to.

On the other hand, mail servers must also reverse resolve in order to deliver to a large number of mail servers on the Internet.

To check reverse resolution, use the host command.

Note that it does not matter what the server reverse resolves to. It just matters that it does resolve.

Similarly, if we run these commands on our Virtualmin server, we are not necessarily getting a complete picture of DNS.

If the glue records at our registrar are incorrect, hosts other than the Virtualmin server will get completely different results from these commands (making it unable to talk to the server, since other hosts are looking for name information in the wrong place).

We can use whois to check our glue records.

 

Disabled Spam Filter

Sometimes spam will spew directly into our mailbox without limit. This might happen if SpamAssassin is not configured correctly or procmail is broken in some way.

To figure if our mail is being processed by the spam filter, we need to look in the headers of a message received on the server.

In Usermin or the Webmin Read Mail module, we can see the headers on a message by clicking the View Full Headers link in the upper right corner of the email. Most mail clients have some sort of option to allow us to see the raw message or the full headers.

If spam filtering is performing correct, there will be one or more X-Spam-* headers within the header. If no such message appears, procmail or SpamAssassin may be disabled for domain or the user, or misconfigured.

 

Problem with Virus Scanner

This method is the easiest to check Common email errors in Virtualmin

One possible method our support engineers use is, write themselves an email with an attachment containing the EICAR test string. If it makes it to the mailbox, then AV scanning is not working. If it does not, things are working fine.

Bouncing With Reverse Resolution Failures

Many mail servers will reject email from a server if it does not have correct reverse resolution.

The authoritative server is defined by the owner of the IP address (i.e. the hosting provider or network service provider). It does not matter what name it resolves to, as long as it resolves to something.

Webmin handles reverse DNS zones – but it is out of the scope of Virtualmin, because Virtualmin would end up assigning a new name everytime we create a new virtual server on a shared IP.

Thus, we create one reverse entry for every IP address – not one for every virtual host that lives on it. It is also not something we can automate away – it requires cooperation from the hosting or network provider, or whoever is authoritative for our IP addresses.

So, to add reverse DNS, we will first have to figure out who is authoritative for our IP address(es), and ask them to do one of the following:

1. Provide a reverse entry for all our IPs in their DNS servers.
2. Delegate the zone to our DNS servers. Point them to our Virtualmin server, fire up BIND, and create those entries.

The reverse lookups on our IP should work, as it is considered “spammy” by most spam filters and mail servers when it does not.

Usermin Webmail Sends With Incorrect From: Address

In most cases, if Usermin webmail does not include the correct From: address, it is incorrectly configured.

To correct this problem:

• Browse to Webmin:Usermin Configuration:Usermin Module Configuration:Read Mail page
• Locate the option labeled From: address mapping file, and set it to

  /etc/postfix/virtual

• Locate the option labeled Address mapping file format, and set it to

  Address to username (virtusertable)

• Save it.

No space left on device errors

A particularly tricky problem with mail processing, delivery, and retrieval can be found on systems that use disk quotas.

Specifically, it will manifest as errors about disk space, even on a disk with plenty of free space.

This may happen majorly due to the following scenarios:

• ClamAV processing causes delivery to fail

Since mail processing with SpamAssassin and ClamAV can be temporarily very disk space intensive, it can run into disk quotas while the disk usage is still well below the imposed limit.

The solution to this problem is to mount the /tmp directory that clamav or clamd are configured to use on a partition separate from /home. This will allow clam to use as much space as it needs in order to decompress files and process them.

We now recommend all installations that will use disk quotas to use an independent /home partition – that is separate from /, /tmp/, and /var directories.

• Dovecot won’t allow mail retrieval if disk quota is filled

This is caused by the inability of Dovecot to manage its index files on a “full” disk. Dovecot can be configured to place indexes in a different location from the mailbox, which resolves this problem (though it does mean users can use slightly more than their disk quota on the system, but indexes are generally pretty small, so this should not be a big concern).

To configure Dovecot to use an alternate location for index files, we set the following in the dovecot.conf:

default_mail_env = maildir:%h/Maildir:INDEX=/var/cache/dovecot/index/%u:CONTROL=/var/cache/dovecot/control/%u

Or (depending on the Dovecot version):

mail_location = maildir:%h/Maildir:INDEX=/var/cache/dovecot/index/%u:CONTROL=/var/cache/dovecot/control/%u

This will tell Dovecot to use a different filesystem for those control and index files that it is having trouble writing to.

We make sure to create /var/cache/dovecot/index and /var/cache/dovecot/control first, and make them mode 6777.

Then re-start the Dovecot server.

If there is no multiple filesystems to place the Dovecot files on, we can always create a loopback filesystem.

First, create an image file using ‘dd’.

The following example will create a 100MB image file:

dd if=/dev/zero of=/virtualfs bs=1024 count=100000

Then, type the following to attach the first Linux loopback device (/dev/loop0) with the image file created above:

losetup /dev/loop0 /virtualfs

We can then proceed to create a filesystem on the image:

mke2fs -j /dev/loop0

Later, assuming to mount it at “/var/cache/dovecot ”, we can mount it with the following command:

mount -t ext3 /dev/loop0 /var/cache/dovecot

We will also want to add an entry for this into our /etc/fstab file.

[Need further assistance? We are here for you!]

Conclusion

In short, email errors in Virtualmin are mostly triggered by failure of the components of its mail system. Today, we saw how our Support Engineers troubleshoot the common email errors in Virtualmin.