Mail is perhaps the most complex component in a Virtualmin system, combining a mail transfer agent (usually Postfix, but optionally Sendmail or qmail), a mail delivery agent (usually procmail), POP3/IMAP retrieval (usually Dovecot), anti-virus (ClamAV), anti-spam (SpamAssassin), and mail log analysis (Virtualmin's built-in mail log analysis tools, and optionally logwatch and others). If any one of these components fails, mail may be completely broken for some or all tasks.
Logs
The first place to look for information about a mail problem is the relevant logs. On Red Hat, Fedora, CentOS, SUSE, and Mandriva systems, the majority of mail related logging is directed to /var/log/maillog. Thus, you should check the contents of this log while attempting whatever action is giving you trouble. Most failed actions will result in a log action, possibly a very helpful one. 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 that found in the /var/log/maillog mentioned previously. Debian/Ubuntu also has 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.
DNS Resolution for Mail
Many issues with mail can be traced back to incorrect DNS configuration. Check to be sure DNS works for the problem domain, and returns valid records. In particular, check the MX record and the name it points to to be sure other hosts can correctly look up the address of your server.
To test DNS resolution you can use the host and dig commands.
For example, here's and example interaction checking the MX record for virtualmin.com:
# 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
This first checks for a MX (mail exchange) record, and then checks to see what address that name resolves to. Mail servers must also reverse resolve in order to be able to deliver to a large number of mail servers on the Internet, as reverse resolution is used as a simple tool to reduce spam by ruling out many classes of dynamic address (like some dialup accounts). Reverse resolution can also be tested with host:
# host 70.86.4.226
226.4.86.70.in-addr.arpa domain name pointer e2.4.5646.static.theplanet.com.
Note that it doesn't matter what the server reverse resolves to. It just matters that it does resolve.
Note also that if you run these commands on your Virtualmin server, you aren't necessarily getting a complete picture of DNS. If your glue records at your registrar are incorrect, hosts other than the Virtualmin server will get completely different results from these commands (and they will also be unable to talk to your server, since they're looking for name information in the wrong place). You can use whois to check your glue records, but that's beyond the scope of simple email troubleshooting. See the Webmin BIND documentation, particularly the http://doxfer.webmin.com/Webmin/BINDTroubleshootingTools|BIND Troubleshooting Tools section.
Is Spam Filtering Working?
Sometimes it can seem like you've hooked right into the firehose that is the Internet and spam is spewing directly into your mailbox without any limit. It may be, if SpamAssassin isn't configured correctly or procmail is broken in some way. To find out if your mail is being processed by the spam filter, look in the headers of a message received on your server. In Usermin or the Webmin Read Mail module, you 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 you to see the raw message or the full headers.
If spam filtering is happening correctly, 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 mis-configured.
Is Virus Scanning Working?
This one is even easier to test. Write yourself an email with an attachment containing the EICAR test string. If it makes it to your mailbox, then AV scanning isn't working. If it doesn't, things are working fine.
The EICAR test string and information about it, can be found on the http://www.eicar.org/anti_virus_test_file.htm|EICAR home page.
Bouncing With Reverse Resolution Failures
Many mail servers in the wild will reject email from a server without correct reverse resolution.
Reverse is different than forward resolution. The authoritative server is defined by the owner of the IP address (i.e. your hosting provider or network service provider). Usually, this is just setup to whatever the provider likes, and that's fine. It doesn't matter what name it resolves to, as long as it resolves to something.
Webmin handles reverse DNS zones--but it's out of the scope of Virtualmin, because Virtualmin would end up assigning a new name every time you created a new virtual server on a shared IP. By that, I mean that you create one reverse entry for every IP address--not one for every virtual host that lives on it. It's also not something we can automate away--it requires cooperation from your hosting or network provider, or whoever is authoritative for your IP addresses.
So, to add reverse DNS, you'll first have to figure out who is authoritative for your IP address(es), and ask them to do one of the following:
Provide a reverse entry for all of your IPs in their DNS servers.
Delegate the zone to your DNS servers. everydns.net probably does not provide reverse resolution services, so you'll need to point them to your Virtualmin server, fire up BIND, and create those entries.
You definitely want reverse lookups on your IP to work, as it's considered "spammy" by most spam filters and mail servers when it doesn't.
You can find out what name servers are currently responsible for a zone with:
whois 192.168.1.1
Replacing 192.168.1.1 with your servers IP address, it will list lots of details about the IP, including the servers for the PTR records.
Usermin Webmail Sends With Incorrect From: Address
In most cases, if Usermin webmail does not include the correct From: address, it is incorrectly configured. The default was not being set correctly in our automated installer until recently due to a bug.
The old default would default to a From: address of the form "user-domain@hostingco.tld", when it should instead be "user@domain.tld".
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 may be seen on systems that use disk quotas. Specifically, it will manifest as errors about disk space, even on a disk with plenty of free space.
ClamAV processing causes delivery to fail
Because mail processing with SpamAssassin and ClamAV can be temporarily very disk space intensive, it can run into disk quotas while it will appear that disk usage is still well below the limit you've imposed.
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 shouldn't be a big concern).
To configure Dovecot to use an alternate location for index files, you can 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. Just make sure you create /var/cache/dovecot/index and /var/cache/dovecot/control first, and make them mode 6777.
Then re-start the Dovecot server.
If you don't have multiple filesystems to place the Dovecot files on, you can always create a loopback filesystem.
To do that, 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 you created above:
losetup /dev/loop0 /virtualfs
You can then proceed to create a filesystem on the image:
mke2fs -j /dev/loop0
Then, assuming you wish to mount it at "/var/cache/dovecot", you can mount it with the following command:
mount -t ext3 /dev/loop0 /var/cache/dovecot
You'll also want to add an entry for this into your /etc/fstab file.