POP3 and IMAP Configuration - How to configure common mail clients to download mail using POP3 and IMAP.
Spam and Anti-Virus Scanning - Explanation of Spam and Virus scanning features in Virtualmin.
Email Frequently Asked Questions - Frequently asked and answered questions about email service in Virtualmin systems.
Email Troubleshooting - Troubleshooting common email problems.
SMTPS and Submission Configuration - Configuring Postfix to accept secure SMTP connections for outgoing mail from mail clients.
Hold and Forward Backup Server - Configuration of a hold and forward backup SMTP server, using a second Virtualmin server.
Email Tutorials - Our step-by-step tutorials related to email.
All Documentation Pages tagged "Email" - A predefined search of pages that have been tagged "email".
Virtualmin configures the Dovecot POP3 and IMAP server for usage with all common mail clients, and Cyrus saslauthd for SMTP authentication on outgoing mail.
You can always find the username for a user by looking on the Edit Users page for the virtual server in which the user exists. It will be displayed in the IMAP/FTP login field. With the exception of users with @ in them, the username will be the same for all services (mail, ssh, FTP, Usermin, etc.).
Virtualmin, by default, creates system login names by combining the username and the first part of the domain name, separated by a configurable separator ("." by default). Thus, a user named joe within the virtualmin.com domain would use the login name joe.virtualmin.
This is, of course, completely configurable. To choose the username format used, browse to System Settings:Server Templates and select the Mail for domain section, and locate the Format for usernames that include domain field at the bottom of the page.
Virtualmin also supports user@domain.tld style usernames, though there are some caveats in this configuration. Specifically, Postfix does not support delivery to users with @ in them, and so Virtualmin creates two users (one that Postfix will deliver to, and one with @).
In order for SMTP authentication to work with users in this format, saslauthd also needs to be configured to include domain information.
On Red Hat, Fedora, and CentOS systems, edit /etc/sysconfig/saslauthd and add "-r" to the FLAGS= line, save it and restart the saslauthd service.
On Debian and Ubuntu, edit /etc/defaults/saslauthd and add the "-r" flag to the PARAMS= line, save it, and restart the saslauthd service.
Open the Account Settings dialog. Click the Add Account button in the lower right corner of the window. Select Email account and click Next.
Fill in your name and the email address for this account.
Select POP or IMAP, fill in the hostname of the Virtualmin server in the Incoming Server, and then click Next.
On the next page, fill in the username. Click Next.
Give the account a name (the default will be the email address associated with the account).
DomainKeys Identified Mail or DKIM is a standard for signing email messages so that the recipient can verify the sender's email address. This allows recipient mail servers to detect sender address forgery, which is often used by spammers to avoid sender domain blacklists. Signing is done with a private key on the senders server, which matches a public key added to in the sender's DNS domain. The recipient can lookup this key at the domain in the From address, and use it to ensure that the email signature was created using the corresponding private key, which proves that the message was really sent from that domain.
Virtualmin uses a milter to implement DKIM signing and verification. This is background process that the Postfix or Sendmail mail server sends messages to for modification before they are sent to their final destination. Any email relayed through the Virtualmin system (either from a web-based mail read or a client like Outlook or Thunderbird) will have a signature added by the DKIM milter, as long as it is from a domain for which DKIM is enabled.
Only Virtualmin versions 3.81 and later support DKIM.
Virtualmin supports the configuration of DKIM on Debian, Ubuntu, Fedora, CentOS and Redhat Enterprise systems, as these distributions provide the required DKIM milter package. The simplest way to install this is as follows :
root and go to Email Messages -> *DomainKeys Identified Mail**.Installation can also be done from the command line. On Debian or Ubuntu, the command is :
apt-get install dkim-filter
while on CentOS, Fedora or Redhat Enterprise you will need to run :
yum install dkim-milter
To enable DKIM signing of outgoing email messages, follow these steps :
root and go to Email Messages -> DomainKeys Identified Mail2010. Do NOT enter default, as this can trigger a bug in the current Virtualmin release which deletes the /etc/default directory!Assuming all goes well, Virtualmin will report the steps taken to configure and enable DKIM.
Only virtual servers that have both the DNS and email features enabled will have DKIM activated, as the mail server needs to be setup to use a private signing key whose corresponding public key is added to DNS.
By default, Virtualmin will also configure the DKIM milter to verify incoming email that has the proper signatures. DKIM-signed messages where the signature is incorrect or cannot be checked with a DNS lookup will be bounced or delayed. If you want to disable verification, set the Verify DKIM signatures on incoming email? option to No.
To turn off DKIM signing completely, just do the following :
root and go to Email Messages -> DomainKeys Identified MailThis will remove the public key from all domains, and stop your mail server from signing messages with the DKIM milter.
How do I set up a catch-all email address to receive or bounce invalid inbound emails?
Note that this is not recommended. It breaks the ability of the mail server to reject mail early in the delivery process, which means your system will work dramatically harder because full spam messages and viruses will have to go through the full processing chain. It is far better to create every alias you need, as you need them.
To "turn off" the automatic email bouncing, simply delete this catch-all email alias.
Why is All Incoming Email Bouncing?
That can occur if your hostname gets out of sync with what's setup in your server's config files.
To check for this problem, log into your server as root over SSH, and run the command "hostname". Then, verify that the resulting hostname exists next to your external facing IP address in /etc/hosts, as well as on the "mydestination" line of /etc/postfix/main.cf. After making those changes, restart Postfix.
What's the deal with @ in mailbox usernames?
It's a bad idea, according to Wietse Venema in this post on the Postfix mailing list: http://archives.neohapsis.com/archives/postfix/2000-02/0892.html
Virtualmin has several clever hacks to workaround this particular feature of Postfix, revolving around the creation of a second user with the same UID and paths, which Postfix can deliver to. This has many potential problems and might confuse other software that isn't smart enough to deal with multiple usernames with the same UID (this is perfectly legitimate, and ought to work, but it is a common failing and even some of our stuff has had some bugs uncovered, but now fixed, by this hack).
On recent operating systems (Fedora Core 5+, CentOS 5, Debian 4.0+, and Ubuntu 8.04LTS are all confirmed to have this issue) the Cyrus saslauthd version defaults to dropping the "@domain.tld" portion of the username before attempting authentication. This, obviously, won't work. The solution is to add the "-r" flag to the saslauthd command. On Red Hat based systems, additional flags can be added in the "FLAGS=" section of the file /etc/sysconfig/saslauthd. On Debian-based systems, the file to edit is /etc/default/saslauthd and the directive to modify is "PARAMS=". This is an orthogonal issue to the Postfix issues, and will occur whether you use Sendmail or Postfix as your mail server.
We don't recommend using @ in the username for mailbox users (for the same reasons that Wietse removed support for them in Postfix), but if you must it can be done. Any problems you run into should be brought up in the Bug Tracker, so we can get them resolved. Just because it's a hack doesn't mean we won't make it work as well as any othe naming convention.
Also note that this trick is incompatible with mbox style mail spools (because mail will be delivered to the "wrong" mailbox: user-domain.tld, instead of user@domain.tld). Maildir format mail spools are not subject to this problem, and are the default in Virtualmin if you have used our automated installation script.
If you really do want to use this type of username, edit the Server Template(s) for which you'd like this type of username. Browse to the "Mail for domain" section (select it in the dropdown, if using the Virtualmin theme, or scroll to this section if using any non-menu-ized theme). Find the option labeled "Format for usernames that include domain", and select "user@domain", and save your changes.
Configuring a secondary MX server to provide hold and forward mail service in the event your primary mail server is offline. Virtualmin Professional is required on the primary server, and Virtualmin Professional or Virtualmin GPL is required on the secondary server.
Mail service is, for many users, the most important internet service. While always-on reliability on virtual hosting systems is impossible (kernel upgrades for security updates, at the very least, require system reboots), the DNS and mail standards provide mechanisms to allow mail to flow successfully even if the primary mail server is temporarily off-line.
Configuration of a secondary mail server is relatively simple, but can be made completely automatic with Virtualmin Professional. To use this automatic backup mail server configuration feature, you must have Virtualmin Professional on the primary server. On the backup server, either Virtualmin Professional or Virtualmin GPL will work.
For this process to work, the following components are needed:
Virtualmin 3.87 and later can configure secondary mail servers to only accept email for addresses that exist on the primary server. This prevents spammers from sending email with faked from addresses to invalid addresses on the secondary server, which are then relayed to the primary and bounced back to the fake address.
The steps to configure Postfix on the secondary to support this are :
/etc/postfix/main.cf and add the line relay_recipient_maps = hash:/etc/postfix/relay_recipientstouch /etc/postfix/relay_recipients ; postmap hash:/etc/postfix/relay_recipients/etc/init.d/postfix restartTo configure Sendmail on the secondary, the steps are :
The first step in this process is to add your secondary server to the list of available Webmin servers. To do this, click on the Webmin link in the upper right corner of the left menu pane to activate the Webmin menu. Then, open the Webmin menu category and click on ''Webmin Servers Index''.
Click the ''Register a new server'' link, and then fill in the form, providing the hostname of the secondary and the port on which Webmin is running. In the Link Type section, select ''Login via Webmin with username ... password ...'' and enter an administrative level username and password.
Once the form is filled out, click ''Save''. Assuming there are no errors, you should now see an icon representing your secondary server in the Webmin Servers Index page.
Once the server has been added as a Webmin server, you just need to enable it as a secondary server in Virtualmin. In the left-hand menu, re-activate the Virtualmin menu by clicking on the Virtualmin link in the upper left corner. Now open the ''Addresses and Networking'' menu item, and click on ''Secondary Mail Servers''.
The server you've just configured in the Webmin Servers Index should appear in the list with an empty checkbox beside it. Click the checkbox to activate it. If you already have domains on your server that you want to setup with secondary mail service, also check the ''Add all existing mail domains to secondary MX servers?''. Finally, click ''Save''.
That's it, you're done!
The simplest way to test if allowed addresses are being sent to secondary mail servers to prevent backscatter spam is to SSH into the primary system as root and run the command :
virtualmin syncmx-domain --all-domains
This will all send valid addresses in all mail domains on the primary system to all secondaries. If you have just added a new secondary or upgraded Virtualmin to version 3.87 (in which this feature was added), you should also run this command at least once.
Note: If you just want it to work and don't care how, you can stop reading at this point. This is merely for those folks who like to understand what's happening behind the scenes.
This Virtualmin Professional feature makes use of a couple of features of the mail RFCs. First up, it creates an additional MX record, with a lower priority (higher number, but lower priority in the sense that it won't be contacted unless the primary isn't responding) than the primary. Second, it adds an entry on the secondary server to the list of domains that the server will relay for. This causes the secondary to accept mail for the domain, despite not having a local mailbox to place it in.
Since the mail RFCs have well-defined rules about what to do in the event a server is down, this has the effect of causing the secondary to simply accept the mail and hold it in its queue until the primary comes back online. It will automatically attempt to resend the mail periodically, and will only bounce the mail back to the sender if the primary stays off-line for an extended period of time.
SMTPS and Submission are email protocols for encrypted authentication for outgoing email. By default, they use ports 465 and 587.
To set them up, you'd first need to add an SSL certificate for one of your Virtual Servers. Virtualmin can then copy that SSL certificate into Postfix for SMTPS and Submission.
To generate a self-signed SSL certificate, you can simply go into Edit Virtual Server for the domain in question, and set SSL Website Enabled.
Then, click Server Configuration -> Manage SSL Certificate. From there, you can click Copy to Postfix in order to enable SMTPS and Submission with your newly generated self-signed SSL certificate.
This will of course work just fine with a commercial SSL certificate. For instructions on setting up a commercial SSL certificate, see these instructions:
http://www.virtualmin.com/documentation/tutorial/how-to-add-an-ssl-certi...
Virtualmin allows you to enable spam and virus scanning on a per-virtual-server basis, and to configure what happens to email classifies as spam or virus-laden. Under the hood, it uses the popular SpamAssassin http://spamassassin.apache.org/ package for spam detection, and ClamAV http://www.clamav.net/ for viruses.
SpamAssassin assigns each message it scans a score indicating how spammy it is, based on the content and servers it was sent from. Typically, anything with a score above 5 is regarded as most likely spam. ClamAV however just compares the message contents with a database of know virus signatures, and reports if any were found or not.
In a typical Virtualmin installation, you can enable filtering for a new or existing virtual server by just selecting the Spam filtering enabled? and Virus filtering enabled? checkboxes in the features section of the Create or Edit Virtual Server page.
If they do not appear, make sure that these features are enabled globally on your system. This can be done as follows :
root, open the System Settings category on the left menu, and click on Features and Plugins.Internally, Virtualmin creates an /etc/procmailrc file that in turn runs a Procmail include file under /etc/webmin/virtual-server/procmail, depending on the domain to which each email received is sent. This then invokes the spamassassin and clamscan commands, then uses their output to decide if email should be delivered to a special folder or deleted.
SpamAsssassin is run with command-line parameters that tell it to use configuration files under /etc/webmin/virtual-server/spam, which can be different for each domain. This way, domain owners can customize their own SpamAssassin rules, spam levels and message modification settings.
By default, email classified as spam as delivered to the ~/Maildir/.spam file under each user's home directory. This shows up as a folder named spam in users' mail clients, and in Usermin. Email that is detected as containing viruses is deleted by default, as virus detection is almost 100% accurate.
However, you can change these destinations on a per-domain basis using Virtualmin. Some users may prefer that spam be deleted outright, or delivered normally so that it can be filtered by their mail clients. To change the delivery rules, the steps to follow are :
root or as the domain owner.In Virtualmin versions 3.54 and above, you can select to have email whose virus score is above some threshold deleted instead of being delivered to a spam folder. This can be used to stop the delivery of messages that are obviously spam, saving on disk spam and the bandwidth used to download them.
To delete high-scoring spam, just follow the steps above and set the Delete spam if score is above field to some number like 10.
If you have spam and virus delivery destinations that you want used for all new domains, you can set them as follows :
root.To make changes for all existing domains, use the modify-spam.pl command-line API script.
If Virtualmin is configured to deliver spam to a separate folder for each user, this can end up consuming a lot of disk space and disk quotas. To keep usage down, it is possible have Virtualmin automatically delete users' spam that is more than a certain number of days old, or is taking up more than some amount of disk space.
To set this up for a single domain, the steps to follow are :
If you prefer to delete based on disk usage, select Yes, when mailbox exceeds instead and enter a maximum size for the spam folder. When this is exceeded, messages will be deleted oldest first until it is smaller than the specified size.
The default setting for new virtual servers can be set on the Module Config page in the Spam filtering options section. To make changes for all existing domains, use the modify-spam.pl command-line API script.
By default, Debian 4.0 (Etch) comes with ClamAV packages that are out of date and buggy.
The most common symptom of this is very slow virus scanning, and high CPU load from clamscan or clamd. However, there is a fix - you can update to a newer ClamAV version from the Debian volatile repository, at http://www.debian.org/volatile/
To use the volatile repository, SSH into your system as root and edit /etc/apt/sources.list. At the bottom, add the line :
deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free
Then update ClamAV packages with the commands:
apt-get update
apt-get install clamav clamav-base clamav-daemon clamav-freshclam
In the default Virtualmin configuration, each email received is processed with the clamscan command to check if it contains viruses. Unfortunately, this can take anywhere from seconds to minutes to run, particularly on VPS systems that have limited IO bandwidth or CPU resources. Most of this time is spent loading the virus database, which is continually growing as new viruses are found by the ClamAV authors.
Slowness running clamscan can cause email delivery to be delayed by several minutes, during which messages stay in the Postfix mail queue. It can also lead to high CPU load on the system, which then slows down other services like Apache or MySQL.
Fortunately, there is a fix - the clamd server process, which loads the virus database just once and then stays running. When email arrives, the clamdscan command connects to it, passes over the message to be scanned, then reads back the results. This typically only takes a seconds, even on a system with limited resources.
If your system is receiving a large amount of email, I recommend the use of clamd. It probably isn't worth running on a system used primarily as a web server though, as it consumes about 64M of RAM at all times.
To enable the use of the ClamAV server process, follow these steps :
root.clamd on your operating system, and you will need to do it manually.Virtualmin will check if clamd and clamdscan are working properly, and if so configure all virtual servers to use it for virus classification from now on.
If Virtualmin reports that the clamscan command is not working on your system, here are some things to try :
freshclam to download the virus database. On some systems, the standard ClamAV packages do not include any virus data files, so clamscan cannot run.Example line from /etc/freshclam.conf. On some systems this line exists by default, to intentionally prevent freshclam from running!/etc/clamd.conf matches the directory updated by freshclam. If not, clamd will not start due to the lack of data files.SpamAssassin and ClamAV can use up a lot of CPU time, which on a system that receives a lot of email can significantly slow down email processing. However, it is possible to move some of this load to a separate system, by making use of spamd and clamd, the SpamAssassin and ClamAV server processes.
These can be run on one or two other systems on your network, and Virtualmin on the master system that actually receives email configured to offload scanning to them.
In the instructions below, serverip is the IP address of the system that will be running spamd, and virtualminip is the IP of the Virtualmin machine.
spamd on as rootyum install spamassassin/etc/sysconfig/spamassassin and add the following to the SPAMDOPTIONS line : -i serverip -A virtualmin-ipAn example file would look like : # Options to spamd SPAMDOPTIONS="-d -c -m5 -H -i 193.9.101.242 -A 193.9.101.104"
spamd : /etc/init.d/spamassassin restart chkconfig spamassassin on
spamd on as rootapt-get install spamassassin/etc/default/spamassassin , and change the line ENABLED=0 to ENABLED=1.OPTIONS line : -i serverip -A virtualmin-ipAn example completed line would look like : OPTIONS="--create-prefs --max-children 5 --helper-home-dir -i 193.9.101.120 -A 193.9.101.104"spamd : /etc/init.d/spamassassin restart update-rc.d -f spamassassin defaults
Once spamd is running on the remote system, you can configure Virtualmin to use it as follows. Note that this will prevent domains and mailboxes from having their own SpamAssassin rules, unless you setup spam to fetch them from a MySQL or LDAP database .
root, and go to Email Messages -> Spam and Virus Scanning.Now try sending email to a mailbox in one of the domains with spam filtering enabled on your Virtualmin server, and check if SpamAssassin X-Spam headers are added. If not, check /var/log/mail* on both the Virtualmin and spam scanning systems for error messages, and /var/log/procmail.log.
The easiest way to setup clamd is to use Virtualmin's built-in support for configuring it. The steps to do this are :
clamd. You don't need to create any domains, or run any other servers like MySQL or Postfix.root, and edit the file /etc/clamd.conf and make sure the line TCPSocket 3310 exists and is not commented out.TCPAddr 127.0.0.1 does not exist or is commented out./etc/init.d/clamd-virtualmin restart or /etc/init.d/clamd restart to apply the configuration changes.Unfortunately, the executables provided as part of the ClamAV package do not seem to support connecting to a remote server. However, the clamd-stream-client program can do this, and can be used by Virtualmin versions 3.63 and later. You can download it from : https://sourceforge.net/projects/clamd-stream-cl/
Once you have the clamd-stream-client-1.3.tar.gz file on your Virtualmin system, it can be compiled and installed with the commands :
tar xvzf clamd-stream-client-1.3.tar.gz cd clamd-stream-client-1.3 ./configure make make install
You can now configure Virtualmin 3.63 or later to use it as follows :
root, and go to Email Messages -> Spam and Virus Scanning.Assuming that clamd-stream-client works and can contact the remote system, it will be enabled and used for virus scanning for all domains.
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.
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.
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.com/Webmin/BINDTroubleshootingTools|BIND Troubleshooting Tools section.
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.
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.
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.
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.
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.
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.
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.
The Webmin wiki covers the following topics in some detail: