Categories
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.

Categories
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 info@companyname.com and support@companyname.com 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!

Categories
dovecot IMAP iptables Linux nat notepad redirect

You want the other server, really…

In my last post I talked a bit about my server loop dependancies. Well one way to break that was to shift the e-mail processing and dovevot (imap) server from one machine to another.

Shifting the e-mail was easily done. I just installed the software, copied over the configuration files to the new server and started it. dovecot was just as simple. But now I needed to shift all my users to the new imap server. Keeping two dovecot servers going wasn’t the solution so I began to hunt for ways to redirect imap connections to the new server.

I looked at http://www.dovecot.org/ for a solution. Dovecot can redirect users but this is not guaranteed to work and it involves setting up MySQL – which is a database I am not familiar with.

A lightbulb then popped into my head – why not get the old server to redirect the TCP connections to the new server! All Linux boxes have routing capability built in via a kernal flag and the iptables service. Iptables are normally used for firewalls, typically setup using UFW. But iptables also has a nat capability and can redirect packets to another server.

After a bit of looking I determined that the following command would do the trick

sudo iptables -t nat -D PREROUTING -p tcp --dport 143 -j DNAT --to-destination 192.168.1.227:143

And this does just what’s needed. The clients don’t even realise what’s going on a each packet is re-written with the new destination. I’ve found that this does not create a load on the old server at all as after the initial connection sequence all packets appear to be going to the new server directly.

Now I can go to each client machines and gradually over time change the name of the machine in their connection setup.

Has anybody ever noticed that notepad on very rare occaisions hangs when saving a file? Here’s a tip. Do not kill the process. Let it sit.  This will probably take about 2-3 minutes. The file save dialog will popup and you can save as usual.

My theory on this is that presumably the last file I saved was to a network connection which now doesn’t exist or is not responding. So Notepad is trying access that connection again and is waiting for it to timeout. EIther that or there is a registry issue, I have also heard that some anti-virus packages can interfere.