One of the problems (and best things) with using IMAP is that you really
need to have you email rules and filters server side if you intend to
use more than one client.
Sieve is a powerful email filtering
language. The ManageSieve protocol allows users to write their Sieve
rules in the client of their choice, and then upload them to the server.
There are a few Sieve clients which interest me, a plugin for
squirrelmail; Avelsieve,
and a Thunderbird plugin.
Since the LinkStation is already short of memory and CPU I've been
thinking of re-vamping the e-mail handling for quite a while.
The current configuration uses exim & courier (IMAP and POP3). I have
wanted to get rid of POP3 entirely, but the lack of server-side rules
made that undesirable (I don't like the idea of client-side rules, very
inefficient with large messages).
Exim and Courier are currently tied together, since SMTP user
authentication is currently done through the courier-authdaemon (yet
another unnecessary process).
The plan is as follows:
-
Remove the tie between Exim and Courier, this will involve making Exim
authenticate using PAM.
-
Convert users mailboxes from Courier format to Dovecot (this is only
required for users with mail in their Maildir.
-
Install and Configure Dovecot IMAP, POP3 IMAPS, and POP3S
-
Have exim perform its local delivery using the Dovecot Local Delivery
Agent (LDA)
-
Configure Sieve
-
Install & Configure Avelsieve
Step 1.
PAM authentication for Exim.
It turns out that the exim-heavy Debian package is already built with
PAM support, so we dont have too much to do.
Create a file /etc/pam.d/exim
#%PAM-1.0
@include common-auth
@include common-account
@include common-session
Add Debian-exim to the shadow group
adduser Debian-exim shadow
Create the auth configuration for Exim. I am using Exim split
configuration, so the configuration should go in /etc/exim4/conf.d/auth.
I removed the previous auth files leaving only 00_exim4-config_header.
Create a file 30_exim4-config_pam_auth.
# /etc/exim4/conf.d/auth/30_exim4-config_pam_auth
login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = "${if pam{$1:$2}{1}{0}}"
server_set_id = $1
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
The server is configured only to offer LOGIN authentication when the
connection is encrypted, otherwise we'll have cleartext passwords flying
all over the 'net.
Step 2.
Although Maildir is some kind of standard, it seems the IMAP and POP
servers keep control files with the directory. If the Maildir contains
mails (read or unread), it needs to be converted to work with Dovecot,
otherwise the mail client will download all the mail again, and wont
have a record of which mail is read and unread etc.
This process did not seem to work 100%, Thunderbird still insisted on
downloading a bunch of mails, however for the most part everything was
fine, and no mail was lost.
Other ideas for converting the Maildir are to copy all mails locally (to
local folders in Thunderbird), recreate the Maildir, and then copy them
back from Thunderbird, after Dovecot has been upgraded. The Dovecot
Wiki has a number of pages on migration.
I used this script,
following the instructions from here.
Step 3.
Dovecot configuration is pretty easy. The Debian packages come
pre-configured with pretty much everything ready to go.
The basic Dovecot config (all comments removed) looks like this:
protocols = imap imaps pop3 pop3s
listen = *
disable_plaintext_auth = no
shutdown_clients = yes
log_timestamp = "%Y-%m-%d %H:%M:%S "
ssl = yes
ssl_cert_file = /etc/ssl/certs/CERT.crt
ssl_key_file = /etc/ssl/private/PRIVATE.key
mail_location = maildir:~/Maildir
namespace private {
prefix = INBOX.
separator = .
inbox = yes
}
mail_privileged_group = mail
protocol imap {
}
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
}
protocol lda {
postmaster_address = postmaster
}
auth default {
mechanisms = plain
passdb pam {
args = dovecot
}
userdb passwd {
}
user = root
}
NOTE:
It looks like we are allowing plaintext authentication....we are,
however our firewall blocks the non-TLS ports from the outside world, so
a plain-text password should only ever be passed on the LAN.
Step 4.
As it happens, everything should be up-and-running just fine now. Mail
can be delivered, and collected, however the main thrust of this
exercise is to get us into a state where we can run have Sieve rules
running against received mails. The Dovecot
Sieve implementation is a plugin to deliver, the Dovecot
Local Delivery Agent. This means that we need to tell exim to use this
program to perform local delivery.
Once again Debian make this particularly easy for us:
First create the config for exim:
#/etc/exim4/conf.d/transport/30_exim4-config_dovecot_delivery
dovecot_delivery:
driver = pipe
command = /usr/lib/dovecot/deliver
message_prefix =
message_suffix =
log_output
delivery_date_add
envelope_to_add
return_path_add
#group = mail
#mode = 0660
temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78
This defines the transport for the delivery, now we just tell exim to
use this transport, edit /etc/exim4/update-exim4.conf.conf and
change the dc_localdelivery setting:
dc_localdelivery='dovecot_delivery'
Be sure to restart exim after making these changes.
At this point end-to-end functionality should be tested. Everything
should be working as before.
Step 5.
After completing this step we should have 2 pieces of new functionality.
-
Dovecot deliver should evaluate Sieve scripts during mail delivery
-
The Dovecot daemon should listen on port 4190 for Managesieve
requests, which allows us to update Sieve scripts remotely
We need to make a couple of modifications to the Dovecot configuration, dovecot.conf.
Modify the protocols line
protocols = imap imaps pop3 pop3s managesieve
This enables the managesieve protocol in Dovecot, however by default
Dovecot seems to listen on port 2000. This will most likely be changed
in a future versions, since IANA have assigned the port now according to this.
Add the following section to the Dovecot configuration, the make it
listen on 4190:
protocol managesieve {
listen = localhost:4190
}
Since I am planning only to allow script editing via Avelsieve, I have
chosen to only have this listen on localhost, Change 'localhost' to a
'*' for all interfaces, but you may want to confirm that the connection
is such that you are not passing passwords in cleartext across the net.
Now we need to configure the Dovecot LDA to run sieve scripts:
protocol lda {
postmaster_address = postmaster
mail_plugins = sieve
}
And configure the delivery plugin itself:
plugin {
sieve=~/.dovecot.sieve
sieve_dir=~/sieve
}
See the Dovecot Sieve
page for all of the options.
You should be able to check its working using the sieve-connect util,
but thats far too much like hard work, we'll use Avelsieve.
Step 6.
Avelsieve is a plugin for SquirrelMail. The last release
was over a year ago now, so I dont know how active the development is,
but it looks promising enough. There is a Debian package in unstable,
which seems to have everything configured.
I had to make one other modification to my system, but that may just be
because of the way I am configured...
The Avelsieve client makes use of the Scriptaculous
JS library, which although was installed by the Debian package, I needed
to make a symlink at the root of my web server to ensure these files
were loadable via HTTP.
# cd <WEBROOT>
# ln -s /usr/share/javascript/
Job Done!
Categories: Debian, Linux
