dovecot e-mail errors file permissions IMAP shared folders

Finally think I’ve got Dovecot sorted (I think!)

In the last blog I wrote on – at some length I might add – about setting up public shared folders in Dovecot and about just how hard that is! There are some annoyances with Dovecot, but that’s the evolution of something free (the old “you get what you pay for” line). I haven’t tried Dovecot 2.0 yet. Perhaps in 18 months when the next LTS of Ubuntu is available I’ll get there.

After getting the basics of the configuration working I set out to start using and testing the setup. What I found initially is that Dovecot will use the root folder permissions as the permissions for manipulating files. This is particularily problematic when sharing folders as typically you need to enable group permissions. Eg:

rwx----- user mail .
rwxrwx-- user Pubmail .

In the dovecot error log, or just in mail.err, you’ll see plenty of informative error messages about fchown, dotlock etc.. and in there will be information about the group being used Eg:

dovecot: IMAP(infocss): fchown(/home/infocss/Mail/subscriptions.lock, -1, 8(mail)) failed: Operation not permitted (egid=513(Domain Users), group based on /home/infocss/Mail)

In this case you can see that it used the permissions of the group to perform the operation and this failed. That group doesn’t have the permissions – from Dovecot – to perform that operation.

The only way I have found to “fix” this is to allow additional groups to have privileged permissions within Dovecot. This is in addition to the group permissions you need on the files – though I must add that I haven’t tried reducing the file permissions. I’m afraid of breaking something that works!

To do this you need to modify a line in the config file, as described in the Dovecot Wiki.

mail_access_groups = Group1,Group2

The wiki, while telling you that you can have multiple groups here, doesn’t tell you whether the line is comma delimiter or space delimited. It is comma delimited.

That should get your public shared boxes working. Though I still wonder how this setup will work with use shared boxes. I still had tremendous problems with that.

In the last post I pondered about the ACL and how group will work there. Dovecot only really recognises a user’s primary group but not supplementary ones. The “workaround” to this, and to get ACLs really working is to use Post Login Scripting. This is thankfully explained here.

I haven’t tried this. Presumably the script can be put in an appropriate place – /usr/local/bin ??

The guys at Chameeya now have full access to the info e-mail box to answer and respond to customer enquiries.

dovecot e-mail IMAP Linux permissions shared folders

Shared folders in dovecot (aka how to hide useful information)

Along with the installation of squirrelmail in the office it became inconvenient for people to monitor the public e-mail addresses of the business. You know the and through the web interface. The user would have to log out and then in with the shared account – annoying.

In most IMAP systems where is a way to implement shared folders so user’s can stored documents or monitor public e-mail accounts. For example you have a public support or sales account and you’d like the entire team or company access to these e-mails.

I use dovecot IMAP server v 1.2.9 which came with Ubuntu 10.04. The latest version is 2.0 but Ubuntu 10.04 is not using it yet. These instructions may apply to 1.2+ but you’d be best going to the dovecot wiki instead. As well I tried the shared folders setup but I had all sorts of permissions issues and one issue with the shared dict file which I could not resolve so I gave up. I assume it is a bug.

Firstly I am sharing a user’s account e-mail and as stated above. This would have been the right way to do this, but I could not get it work.

First make a backup of the dovecot.conf file

cd /etc/dovecot
cp dovecot.conf dovecot.conf.bak

Then open the dovecot.conf file using your favorite editor and scroll down to find the following section

# REMEMBER: If you add any namespaces, the default namespace must be added
# explicitly, ie. mail_location does nothing unless you have a namespace
# without a location setting. Default namespace is simply done by having a
# namespace with empty prefix.
#namespace private {
# Hierarchy separator to use. You should use the same separator for all
# namespaces or some clients get confused. '/' is usually a good one.
# The default however depends on the underlying mail storage format.
#separator =

This is the default in dovecot, there is no namespaces at all. To implement a public (or shared) namespace, you will NEED to implement the private namespace. To do this uncomment the appropriate lines so that the following are set:

namespace private {
separator = /
prefix =
inbox = yes
subscriptions = yes

Don’t worry about the commented lines. Leave them in there, these are the only lines you need to change.

Now you need to add in the public namespace for the public folders to sit underneath. Note that I couldn’t get this work directly to a e-mail folder. I’ll get into what I did below along with the messy filesystem permissions and ACLs.

namespace public {
separator = /
prefix = Public/
location = maildir:/var/mail/Public
subscriptions = no
hidden = no
list = children

So this is a public namespace, the choices are private, shared and public. The separator, for subscriptions and e-mail clients is ‘/’ which is the most common. In the subscriptions list the prefix for this mail boxes is ‘Public’. The public folder is located at /var/mail/Public. The subscriptions are handled by the ‘parent’ namespace ie: the user’s subscription list. This is probably what you want. And the Public folder is only listed if there are folders underneath being shared. Note that the actual path /var/mail/Public is just a container for the maildir folders underneath. The wiki for dovecot give more information on your choices here.

Then you’ll need to add in two more lines to enable the ACL which will allow you to restrict/enable access to the shared mailboxes to the specific users you want.

protocol imap {
mail_plugins = acl imap_acl
plugin {
acl = vfile

Now things are setup in the imap server, but don’t restart it yet! Now we need to get the filesystem and acl files right.

I then create the folder and shared subfolders.

cd /var/mail
mkdir Public
chgrp mail Public
touch dovecot-acl

I then symlink in the maildir folder I want users to have access to. I did this because the account already existed and I didn’t want to effect any symlinks in the system pointing (and delivering e-mail) to this folder.

ln -s infobox ./Public/.info

Now I need to give users access the Public folder – but not yet the subfolders. The wiki misses some important points here. Firstly you need to allow users to read/list the public folder. I do this by editing the dovecot-acl file and allowing anyone read access

cd Public
nano dovecot-acl

add the following line

anyone lr

You need the put the same file in the maildir folders (not the cur/new/tmp folders) and any subfolders you want users to access. The wiki gives good explanation of what goes in the acl mine looked like

user=me keilrswtx
owner akxeilprwts

I could not get the group option working. Though I think if you read this then usage of the mail_access_groups flag may fix it. I haven’t tried it.

Now the last bit is to give the correct file permissions for access. I did this with file system acl (using setfacl and getfacl). I won’t get into the details here as they are well documented in many places.

This is what I did.

cd /var/mail/Public
chmod o+rx .
setfacl -dm g:GRP:rwx .info
cd .info
setfacl -dm g:GRP:rwx cur
setfacl -dm g:GRP:rwx new
setfacl -dm g:GRP:rwx tmp
setfacl -m g:GRP:rw cur/*
setfacl -m g:GRP:rw new/*
setfacl -m g:GRP:rw tmp/*

Now I can restart the dovecot server

service dovecot restart

Using my e-mail client I can see and subscribe to the public folders and read the e-mails.

Job done!

clamav e-mail Linux procmail virus

Even Linux needs to scan for Windows Viruses

What! you say. Why would Linux need to scan for Windows viruses, surely they don’t affect Linux. Well, yes it is true that a standard Linux O/S setup cannot be affected by Windows viruses. However, almost all setups I read about with Linux involve either acting as a server for Windows machines or as a dual boot/wine host.

In these cases it is essential to run a antivirus tool to prevent your Windows machines from being infected by files sitting on a samba share, shared e-mail server or wine. In my case, my office server stores Windows documents on samba shares and shares e-mail via dovecot IMAP server. The e-mails are fetched from various sources using fetchmail and passed through procmail for delivery to the correct mail folder.

The most common antivirus package on Linux is ClamAV. There are others available from:

I will be speaking about my setup with ClamAV. ClamAV is the most common anti-virus you will find on a Linux setup. This is because it is completely open source and free and available as part of the major Linux distributions. I use Ubuntu throughout my business and ClamAV is included in the main repositories.

To get started the simplest thing to do is install:

sudo apt-get install clamav-base freshclam-daemon clamav-daemon clamassassin

let’s go through this. We install the base tools and software (clam-base), then a daemon to download the latest virus and malware signatures (freshclam-daemon), the clamav daemon  – very useful for scanning e-mail and a script for processing e-mail virus scans (clamassassin).

There are two ways to scan your files, with clamscan or with clamdscan which uses the daemon. Using clamdscan is usually faster as all the virus definitions are loaded in memory. However, the daemon runs under its own user (clamav) and you need to add it to any groups necessary to scan your files.

I use clamscan within a script file which is then invoked through cron to provide a nightly scan with a e-mail summary.

To scan e-mail I needed to add in a procmail recipe. Procmail is a wonderful piece of software which could use a better web page. Procmail delivers mail based on a set of rules/patterns which are set in a global and user’s rules file.

My current setup I have fetchmail bringing down e-mail from my ISP and various other sources. Procmail which is dropping the e-mails into the correct folders. Exim which is currently only acting as a local and forwarding e-mail server. There is a way to tie in ClamAV into Exim but this would only catch outgoing e-mails which I’m not worried about. The only place appropriate was in Procmail.

After some looking around I came up with this procmail recipe:

SUBJ_=`formail -xSubject: | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`

# check if there is a virus and indicate in subject, don't actually delete it!
| /usr/bin/clamassassin

* ^X-Virus-Status: Yes
  :0: fhw
   | formail -I"Subject: [**VIRUS**] ${SUBJ_}"
  :0: fhw

To test it go to where you can download a sample virus and then send it to yourself. The e-mail should be trapped and dropped into your virus folder with the subject altered.

My colleagues appreciated not having to worry any longer about e-mails with suspect viruses coming through the e-mail system. I also have made some adjustments to our Windows e-mail clients for any remote accounts accessed by IMAP (like info and enquiries). Some e-mail clients like to cache the e-mails and attachments from these accounts and this bypasses our e-mail scanner. I have turned off that caching because as you can imagine these accounts get a lot of spam and malicious attachments.

We here at chameeya now feel much more secure. We are even improving in other areas by removing local admin rights for many users and ensuring everyone is logging in with domain accounts.

Now to see if I can get a proxy server to keep out all the porn!