Maildrop, IMAP, and Postfixadmin

I have recently configured my mail server to use IMAP. I started doing this when I was attending Linux.conf.au so that I could read urgent mail using my EeePC while at the conference and then be able to deal with the more complex stuff using my laptop later on.

The next logical step is to have mail delivered to different folders in the IMAP account. While there are ways of doing this via the Subject and other header fields, my needs are not that great. All I need to do is to support user+extension@example.com going to a folder named extension in the user’s mail store. While changing my mail server I decided to install Postfixadmin at the same time.

My first attempt to use Maildrop was to put the following in the /etc/postfix/main.cf file:
mailbox_command = /usr/bin/maildrop -d mail -f “$SENDER” “$DOMAIN” “$USER” “$EXTENSION”

That seems to only work when you have local accounts, so I ended up setting fallback_transport = maildrop and then putting the following in /etc/postfix/master.cf:

maildrop unix – n n – – pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d vmail ${nexthop} ${user} ${extension}

Where vmail is a Unix account I created for storing mail. Then I added the following to /etc/postfix/main.cf. Some of these are probably redundant (such as the virtual_mailbox_base). The recipient limit is set to 1 because there are no command-line parameters for maildrop to support two recipients for the same message.
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_gid_maps = static:2000
virtual_uid_maps = static:2000
virtual_mailbox_base = /mail
vmaildir_destination_recipient_limit = 1
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1

The files /etc/postfix/mysql* all have fields user=, password=, hosts=, and dbname=. The queries in each of the files are as follows:
mysql_virtual_alias_maps.cf:query = SELECT goto FROM alias WHERE address='%s' AND active = 1
mysql_virtual_domains_maps.cf:query = SELECT domain FROM domain WHERE domain='%s'
mysql_virtual_mailbox_maps.cf:query = SELECT maildir FROM mailbox WHERE username='%s' AND active = 1

The /etc/courier/maildroprc file has the following contents:

# log the maildrop actions
logfile "/var/log/maildrop.log"
#
# parameters 1, 2, and 3 are the domain, user, and extension
DOMAIN=tolower("$1")
USER=tolower("$2")
EXTENSION=tolower("$3")
DEFAULT="/mail/$DOMAIN/$USER"
#
# try making a backup (cc) copy of the mail but do not abort if it fails
exception {
  cc "$DEFAULT/.backup/"
}
#
# try delivering to the extension folder but do not abort if it fails
exception {
  if(length("$EXTENSION") != 0 && "$EXTENSION" ne "backup")
  {
    to "$DEFAULT/.$EXTENSION/"
  }
}
#
# deliver to the main inbox if there is no folder matching the extension or if no extension is specified
to "$DEFAULT/"

Installing Postfixadmin [1] was another challenge entirely. One of the complications of this is that there is no Debian package for Lenny (it seems that there will be one in Squeeze – Lenny+1).

I found David Goodwin’s tutorial on installing Postfixadmin and lots of other things on Debian/Etch [2] to be a very useful resource. I look forward to seeing a Lenny version of that document.

Please let me know if you can think of any way to improve this.

Employment Packages

Paul Wayper has said that he only wants to work for companies that will send him too LCA [1]. While that criteria is quite reasonable it seems overly specific. Among other things the varying location of LCA will result in the expense for the employer varying slightly year by year – which employers generally don’t like.

I believe that a better option is to have an employment package that specifies a certain amount of money (related to the gross income of the employee) should be set aside for training, hardware, or other expenses that help the employee (or their colleagues) do their job. Such an option would probably only be available to senior employees who are most able to determine the most effective way of spending the money.

For example an employee who earns $100,000 per annum might be permitted to assign 10% of their income ($10,000) to training or hardware that assists their job. Modern PCs are so cheap that any reasonable hardware requirements could fit within that budget with ease.

There are several benefits to such a scheme. On many occasions I have had colleagues who had inadequate hardware to do their work, slow PCs with small screens really impacted their productivity, in such situations buying a $400 PC and a $400 monitor for each person in the team could make a significant direct improvement to productivity before the impact on moralle kicked in!

Some years ago Lenovo ran some adverts for Thinkpads which said “demand one at the interview”. That made sense when a Thinkpad was an expensive piece of hardware. While there are still some expensive Thinkpads, there is a good range of cheap models, two which cost less than $1200AU and another eight which cost between $1200 and $1800. Now it makes more sense to allow each employee to choose their own hardware (both desktop and portable) and not even bother about issues such as whether the IT department blesses them. As Tom Limoncelli suggested in his LCA keynote, users are going to take more control over their environment whether the IT department like it or not, so it’s best to work with them rather than fighting them.

For training a common problem is that management can’t correctly determine which conferences are worthy of the expense of sending their technical staff. Then when a conference is selected they send everyone. It seems to me that when there are a number of conferences in a region (EG AUUG, LCA, OSDC, and SAGE-AU in Australia) there is a benefit in having someone from your team attend each one. Planning at the start of the year which conferences will be attended by each team member is something that appears to be beyond the ability of most managers as it requires knowing the technical interests and skill areas of most staff. If each employee was granted one week of paid time per year to attend conferences and they could determine their own budget allocation then they would be able to work it out themselves in a more effective manner.

Voting and Linux Australia

Dhanapalan writes about the small number of voters for Linux Australia elections [1]. I guess that blacklist-voting is partly to blame for my inactivity in this regard. Linux Australia is running pretty well so I don’t think there’s a great need for me to go out of my way to vote.

One thing that could be done given that LCA is an LA event is to give a voting session keynote status at LCA. Have it happen just after a keynote speech and have some prize given away to a random person who attends – the free laptops that were given away one year are not required, a free lunch voucher would be more than enough to increase the attendance.

A final factor that needs to be considered is the number of elections that we may vote in. I vote in Australian elections (state and federal), Debian votes (General Resolutions and DPL elections), and sometimes my local LUG. The amount of attention that I can focus on political issues is limited and divided with other elections that are more important.

SE-LAPP

On Tuesday afternoon I gave a talk on behalf of KaiGai Kohei about SE Linux and the LAPP (Linux Apache, PostgreSQL, PHP/Perl) stack. KaiGai has blogged about this [1], unfortunately Google Translation does a poor job of Japanese and has particular problems with KaiGai’s work (could anyone who knows Japanese and English well please submit some tips to Google). KaiGai’s post is useful for links to his notes which are good background reading.

My talks about SE-LAPP and SE-PostgreSQL have been getting some notice, Bob Edwards referenced SE-PostgreSQL in his talk about database security.

It’s good to see KaiGai’s great work getting the notice that it deserves. I hope that it becomes a standard feature of the PostgreSQL code base in the near future!

Also Casey Schaufler, James Morris, and I have bought KaiGai a present of some Tasmanian wine, in recognition of his great work.

Status of SE Linux in Debian LCA 2009

This morning I gave a talk at the Security mini-conf of LCA about the status of SE Linux in Debian. Here is a summary of the issues I covered:

General Status

In Lenny (the new release of Debian that will come out in a month or two) SE Linux is working well. Considerably better than in Debian/Etch. There is an installation document on my documents blog [1], it’s very easy, only two scripts need to be run with no parameters to do most of the work (5 commands in total). There is more detail on installing SE Linux in Lenny (and other issues) in the Debian Wiki [2].

The default configuration of SE Linux is “targeted”. Previously we had separate policy packages for “targeted” and “strict”, now they are configuration options for selinux-policy-default. It is also possible to have some users in the unconfined_t domain (like the “targeted” policy) and some in confined domains such as user_t. Changing to strict can be done one user at a time, this needs further documentation.

Backports

I maintain an APT repository of i386 and AMD64 packages for better SE Linux support. This includes libraries built to not need an executable stack (see my previous blog post for details [3]). It also includes i386 libraries that don’t need text relocations AKA execmod (see my blog post about why i386 must die for details [4]).

My Lenny repository includes policy packages before they appear in Testing as well as the packages that are modified to fix the execmod and executable stacks issues. I plan to maintain this repository for some time, at least as long as I am actively using Lenny, but the content will change.

I might back-port the newer upstream policy to Lenny at some later date. If I do this it will be near the time that Lenny+1 is released and I will put it in a different location to my current Lenny repository.

I am currently deciding what to do with packages from external repositories such as debian-multimedia (see my previous post for the background) [5]. I may have to create a separate repository for non-standard Debian packages which I then modify to better support SE Linux.

I also plan to build packages of Security Enhanced PostgreSQL [7] for Lenny and Lenny+1. After demonstrating it’s capabilities I will suggest that it be considered for Lenny+1.

Play Machine

I have been running a Play Machine (open root machine) [6] for most of the last seven years. In the near future (probably the week after LCA) I will upgrade it to Lenny. One thing that I didn’t mention is the fact that I plan to demonstrate other things such as SE-PostgreSQL in Play Machines.

Training

I have a Xen server that is used for my Play Machine, I will run it as a SE Linux training machine and grant temporary ownership of a DomU to anyone who wants to learn and have a document with a list of tasks to complete to learn about SE Linux. I might be able to get it online this week. If so then I’ll make it available first to LCA delegates.

I will also set up a Bittorrent server for a Xen image for anyone who wants to go through the same SE Linux training program on their own machine – this will allow them a greater time limit and also avoid contention for my server. Unfortunately I have some problems with BitTorrent, I would appreciate any advice about running a torrent tracker.

Post Lenny

SE PostgreSQL is an exciting new development that I want to get in Debian. Initially I will create my own APT repository for it and include it in my Lenny repository. Hopefully it will become a standard feature in Lenny+1.

Security Enhanced X (the X window access controls) is a significant security feature. I hope to have that in Lenny+1, but it might not be possible.

Security Lessons from a Ferry

On Saturday I traveled from Victoria to Tasmania via the ferry (to attend LCA), they grossly failed in their security measures and provide three lessons for others:

  1. Make it possible for people to read security relevant documents .
  2. Make obeying the rules not be a cost and make the fact known.
  3. Don’t be lazy.

Here is the detail:

  1. When driving towards the ferry in a queue that lasted about 30 minutes just around the last corner there was a sign notifying me of the security rules. As soon as it was visible I started reading it but the security guard started frantically waving at me, the time taken to read it was holding up the queue. Therefore I never discovered the full list of things that I’m not supposed to do.
  2. One rule was that cylinders of gas (such as propane) were apparently banned and should be surrendered – presumably to prevent a gas leak in the confined space of the ship’s hold from risking an explosion. Anyone who did have such a gas cylinder would probably not want to have it stolen by the security people and would be inclined to lie and hope that the security people wouldn’t find it. If they had made it well known that such gas cylinders would be stored in safe keeping for the duration of the voyage and then returned then they would have been more successful.
  3. They wanted to check the luggage compartments of all vehicles. To check the tail-gate of the Kia Carnival van I was driving first required that all the bags which had been put over the back seat be removed (they were resting against the tail-gate and would fall out if it was opened). When the guard realised that they would have to wait for me to empty a lot of luggage out they decided to just trust me that I didn’t have any bad things on board (even though due to point #1 I didn’t know what bad things were). This problem happened a second time when I reached Tasmania and the guards wanted to search for fruit.

Security Enhanced PostgreSQL

Today was the first day of Linux Conf Au 2009 [1]. KaiGai Kohei was unable to attend the conference and give a database mini-conf presentation about his work on Security Enhanced PostgreSQL [2], so I gave the presentation in his place. It was a fairly difficult presentation and required that I learn a lot about PostgreSQL in a small amount of time. But the result seemed OK, the audience seemed reasonably interested and the questions indicated that there was no extreme negative reaction to it.

After the main presentation I gave a live demo using a Fedora 10 machine image that KaiGai provided. That ended about four minutes after the specified time, which was pretty good considering that I started about seven minutes late to allow the audience time to return from the lunch break.

Tomorrow I will give another talk for KaiGai on the topic of the Security Enhanced LAPP (Linux, Apache, PostgreSQL, and PHP) stack. I will also give a talk about the status of SE Linux in Debian/Lenny.

For both talks I have a separate laptop for the demos, so after tomorrow I will only take one laptop to LCA – which will probably be an EeePC (on some days at least).