When mail delivery agent or POP3/IMAP retrieval service fails, it can trigger email delivery issues in Virtualmin.
Here at Ibmi Media, as part of our Server Management Services, we regularly help our customers to fix email errors.
Now, let us learn how to fix Virtualmin email related issues.
How do you troubleshoot 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 Support Experts apply different methods for further troubleshooting the common email errors.
How to fix Common email errors in Virtualmin?
There are several reasons for the email errors in Virtualmin. Some of them are as follows:
i. Incorrect DNS configuration
ii. Disabled Spam Filter
iii. Problem with Virus Scanner
iv. Bouncing With Reverse Resolution Failures
v. Usermin Webmail Sends With Incorrect From: Address
vi. No space left on device errors
Furthermore, let us have a detailed look into these reasons and to fix them.
1. Incorrect DNS configuration
Most common reason for issues with mail is an incorrect DNS configuration.
Our Support Experts 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.
# host -t mx virtualmin.com
virtualmin.com mail is handled by 5 mail.virtualmin.com.
# host mail.virtualmin.com
mail.virtualmin.com has address 10.10.1.100
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.
2. How to 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.
3. Virus Scanner Issues
This method is the easiest to check Common email errors in Virtualmin
One possible method our Support Experts 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 every time 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:
i. Provide a reverse entry for all our IPs in their DNS servers.
ii. 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 "A spam" 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:
i. Browse to Webmin:Usermin Configuration:Usermin Module Configuration:Read Mail page.
ii. Locate the option labeled From: address mapping file, and set it to
iii. Locate the option labeled Address mapping file format, and set it to;
Address to username (virtusertable)
iv. Save it.
Common email errors in Virtualmin
i. 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.
ii. 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.
Start by creating 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.