pyldaw

[ The Name | History | Overview | Example Configuration | Downloading | Contact | Sourceforge Project Page ]

The Name

'Pyldaw' is an an acronym for 'PYthon Local Delivery Agent Wrapper', or 'Pyldaw: Your Local Delivery Agent Wrapper', if you prefer recursive acronyms.

I would not recommend trying to pronounce 'pyldaw'. If you must, the proper pronunciation is "pyldaw". Maybe it could be something like [pill dahw], and pronounced with a southern drawl. Or maybe it just rhymes with "mill raw". I'd rather spell it than say it, anyway.

History

I started using Qmail as my mailserver somewhere in the 1990s and was well-pleased. Until 2000, when I decided to start using my ISP's mailserver as a relayhost, and they required me to use SASL. As many of you know, this is not possible without a patch for qmail. I finally found a useful patch (qmail-1.03-smtpauth.patch.gz for those who want to use it) and was very happy again.

In 2004 I decided to move back to Linux (from FreeBSD, main reason being that I wanted to do sound recording on my PC, and there was no jackd support on FreeBSD. Yet), and decided to go with Gentoo as my distro. Rather than going with Qmail, which Still lacked a few features I thought would be useful, I decided to go with Postfix. Which was all hugs and puppies until I wanted to use extension addresses like I was used to with qmail. Even after setting 'recipient_delimiter' to "-", there was still no way to have 'user-ext1-ext2-ext3@example.com' be handled by .forward-ext1 - It's just not possible. I was used to this from my years of experience with the dot-qmail idea.

Reading that Courier MTA uses dot-courier files which were just like dot-qmail files, I decided to try using the standalone Local Delivery Agent (LDA) from Courier, called Maildrop. Alas, while the filtering and reliability are much better than procmail (so I've been told), it won't do dot-courier processing without the Courier MTA installed too. It has been noted that the '-M' option in maildrop does a function like what I want, but I think a separate wraper script is more accessable than a patch for maildrop anyway.

So, despondent, alone, and unanswered on the maildrop mailing list, I set out to write a wrapper which would not reinvent the wheel, but just extend an existing LDA to process things in a dot-qmail-like way. I wrote this wrapper for use with Postfix and Maildrop, but it should be easily extendable to any other LDA like procmail, and possibly extendable to other MTAs, but maybe not easily.

After running version 1.0 for a time, and fixing the few bugs which led to the version 1.1 release, I realized that Postfix does funny things with the RECIPIENT environment variable for Virtual Domain processing. Enter version 2.0 of Pyldaw, with its extended virtual domain support.

Overview

Version 2.0 and greater of Pyldaw includes Postfix Virtual Domain support. Basically, when processing virtual domains, Postfix puts the original Recipient address in an email header and rewrites the RECIPIENT environment variable with the local delivery address. The new 'pyldaw-v' looks for this header and processes things accordingly. Since this takes more overhead than the original v 1.0 processing which works great for local deliveries only, the original 'pyldaw' script still exists for Local Delivery.

Virtual Delivery

Here's how processing happens for virtual deliveries, assuming an original recipient address of 'vuser-ext1-ext2-ext3@example.com' and a Postfix Virtual table which contains:

example.com domain
@example.com user-example
  1. Postfix will rewrite the RECIPIENT environment to user-example@localhost, and put the original recipient 'user-ext1-ext2-ext3@example.com' in the X-Original-To header, both of which are extracted by Pyldaw.
  2. Check for the file '~user/.mailfilter-example-vuser-ext1-ext2-ext3'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "".
  3. If not, check for the file '~user/.mailfilter-example-vuser-ext1-ext2'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext3".
  4. If not, check for the file '~user/.mailfilter-example-vuser-ext1'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext2-ext3".
  5. If not, check for the file '~user/.mailfilter-example-vuser'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext1-ext2-ext3".
  6. If not, check for the file '~user/.mailfilter-example'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext1-ext2-ext3".
  7. If not, check for the file '~user/.mailfilter-vuser-ext1-ext2-ext3'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "".
  8. If not, check for the file '~user/.mailfilter-vuser-ext1-ext2'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext3".
  9. If not, check for the file '~user/.mailfilter-vuser-ext1'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext2-ext3".
  10. If not, check for the file '~user/.mailfilter-vuser'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the environment to "ext1-ext2-ext3".
  11. If not, run maildrop with the default filter, after setting the EXTENSION variable in the envioronment to "ext1-ext2-ext3".

Local Delivery

Here's how processing happens for local deliveries, assuming a recipient address of 'user-ext1-ext2-ext3@example.com':

  1. Check for the file '~user/.mailfilter-ext1-ext2-ext3'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the envioronment to "".
  2. If not, Check for the file '~/.mailfilter-ext1-ext2'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the envioronment to "ext3".
  3. If not, Check for the file '~/.mailfilter-ext1'. If it exists, run maildrop with that filter, after setting the EXTENSION variable in the envioronment to "ext2-ext3".
  4. If not, run maildrop with the default filter, after setting the EXTENSION variable in the envioronment to "ext1-ext2-ext3".

Right now, because it's only been written for postfix, the recipient address is taken from the RECIPIENT environment variable, and the username is expected to be in the USER environment variable. If your MTA sets these things, you can probably use this too.

To be compatible with other LDAs, the base filename (in our example, this was "~user/.mailfilter") can be changed, as can the path to the LDA, and the actual commandline to run in the case of (1, 2, or 3) a matching filename was found, or (4) no matching filename was found. As long as the LDA accepts mail on stdin and has some way of specifying a filename to process, it should be easy to use pyldaw with that LDA.

For more information on configuring, see the INSTALL file in the distribution, the 'pyldaw' program itself, which is an editable python program, or the example setup below.

Example Configuration

Sometimes I like examples. I hope this one helps you.

Let's say that a user, call him, say, 'user', wishes to use maildrop to filter his messages on a postfix server, with extended extension addressing. He downloads pyldaw and untars it in his home directory, so the 'pyldaw' program itself is located at '/home/user/src/pyldaw-2.0/pyldaw'

He sets up his .mailfilter-* files so that he can have different filtering on different extension addresses:

Now he wants postfix to start sending email through pyldaw, so he changes his .forward file to be:

"| /usr/bin/python /home/user/src/pyldaw-2.0/pyldaw"

If 'example.com' is a Postfix Virtual Domain setup as follows:

example.com domain
@example.com user


He would want to use 'pyldaw-v' instead:

"| /usr/bin/python /home/user/src/pyldaw-2.0/pyldaw-v"

That's it. His mail is now being filtered.

Downloading

The current release is 2.0. It is the third release and should be considered beta software. It has only been tested by me. Hopefully this will change in the near future as more people test it.

[ pyldaw-2.0.tar.bz2 download (11870 bytes) | pyldaw-2.0.tar.gz download (12134 bytes) ]

Download either of the distribution tarballs, and untar it somewhere where you will run it. No compilation necessary, but it does require Python 2.0 or better to run. Read the README and INSTALL files there, and you should be able to figure out how to install it from there.

Contact

For help, you can email the author, Jim Ramsay, at i.am@jimramsay.com, or use the Sourceforge Help Forum. I'm also usually on irc.freenode.net in the #gigs channel as user 'lack'. Maybe I'll make a #pyldaw channel, but only if this software becomes really popular (not likely).


SourceForge.net Logo