This information is covered by the GNU Free Documentation License.  This
license can be read at:  http://www.gnu.org/licenses/fdl.html

Please let me know if you find this document helpful.  Drop me an email
at:  mailto:me@mooluv.com


This document aims to instruct you on getting DSpam integrated as the
delivery mechanism of Postfix.

I'll assume that you know how to get postfix working.  I'll only be
describing the steps to modify a working postfix instance to use DSpam.

This document assumes that mail will be delivered in Maildir style.
It requires procmail, and will work with both local and virtual
delivery.  The configuration does not include spam quarantine or use of
the CGI spam manager.

For starters I'll describe my current setup:

Debian testing/unstable
Packages:
postfix 2.0.18  (including postfix-tls)
procmail 3.22
courier imap 2.2.1
courier pop .44.2

Source:
dspam-2.10-RC1


We'll start with compiling and installing dspam.

I configured dspam with the following:

./configure --with-storage-driver=libdb4_drv --enable-alternative-bayesian \
  --enable-spam-delivery --enable-opt-in --disable-trusted-user-security

DSpam automatically detects procmail as the LDA.  I enable opt-in because
it's "The Right Way" for my server.  The spam delivery is on so that all
interaction with dspam is via email.  disable-trusted-user-security is due
to my usage of tertiary domains instead of aliases for fp and add-spam
addresses.  It is required in order to set the username to something else
on local deliveries.

Once dspam is configured, make and install it.

One last thing:  I made /usr/local/bin/dspam world executeable.  I know
of no other way to make it work with postfix.  My mail server has no
shell accounts beyond administrators.



Configuring postfix for local delivery using DSpam:

We setup the mailbox_command to use dspam.

/etc/postfix/main.cf:
mailbox_command = /usr/local/bin/dspam --user "$USER"@"$DOMAIN" \
-t DEFAULT=/mail/"$DOMAIN"/"$USER"/Maildir/

The --user option tells dspam what username to use in the repository, and
opt-in files.  The DEFAULT setting tells procmail where to deliver mail to.
In this case: /mail/localdomain.tld/username/Maildir/

Note that there is no /etc/procmailrc.  In my configuration there is no
$HOME/.procmailrc either.  Procmail is being used as a simple LDA after
dspam does it's work.  However you can setup $HOME/.procmailrc files if
you wish.  The issue is then how do you let users modify and test their
rc file?

That's it for local delivery, if you're only doing the local delivery
configuration, you'll need to setup the addspam and false-positive aliases
as usual for dspam.  Otherwise don't create these aliases, we'll be using
transports for that job.


Configuring virtual delivery using DSpam:

We start by creating the user and group which will own the virtual
destinations mail files.  I'll assume you know how to create users and
groups.

Create the user and group for virtual:
/etc/passwd:   virtual:x:500:500::/nonexistant:/bin/true
/etc/group:    virtual:x:500:

Make sure that the virtual destinations are all owned/grouped by virtual.
Otherwise you might have delivery problems and mail will end up in /var/mail.
Interestingly enough I have this working, and I still end up with empty mail
files in /var/mail for all of my local users and the virtual user.  Very odd,
if anyone knows what's going on here, please contact me.

Then we create a transport to be used for virtual delivery.

Create a new transport in master.cf (all one line):
dspam     unix  -       n       n       -       -       pipe flags=Rqu user=virtual argv=/usr/local/bin/dspam --user ${user}@${nexthop} -t DEFAULT=/mail/${nexthop}/${user}/Maildir/ HOME=/mail/${nexthop}/${user}

You'll notice that the user for dspam is going to be user@virtual.tld and 
that procmail gets the rest of the commandline.  Mail will be delivered to
/mail/virtual.tld/user/Maildir/ via procmail.

Setup your maps, aliases and transports:

/etc/postfix/main.cf:
virtual_transport = dspam
virtual_mailbox_domains = hash:/etc/postfix/virtual-domains
virtual_mailbox_maps = hash:/etc/postfix/virtual-users/virtual.tld
virtual_alias_maps = hash:/etc/postfix/virtual-alias/virtual.tld


The following file contains the list of domains that we will be accepting
mail for.  Any domain listed here will be attempted through the virtual
transport.  The RHS of this table is unused, however to make postfix not
throw an error, something needs to be there.

/etc/postfix/virtual-domains:
virtual.tld	nothing important


This file contains the recipients for your virtual domains.  I've broken
the domains into seperate files, you do whatever suits you.  If an address
isn't listed here, it's not going to get email delivered.  I don't recommend
listing an address twice, I don't know what will happen.  Aliasing is
handled in the next file.

Since we are not using the original virtual transport the RHS of
/etc/postfix/virtual-users/virtual.tld is unimportant.  It would normally
contain the location to deliver mail to, however this is handled by our
dspam transport entry in master.cf.

/etc/postfix/virtual-users/virtual.tld:
recipient0@virtual.tld	nothing important
recipient1@virtual.tld	nothing important
recipient2@virtual.tld	nothing important
recipient3@virtual.tld	nothing important
recipient4@virtual.tld	nothing important


This file is basically your alias file.  Any address listed on the LHS
gets sent to the address on the right side.  To have multiple addresses
on the RHS, simply seperate them by commas.

/etc/postfix/virtual-alias/virtual.tld
postmaster@virtual.tld	responsibleparty@virtual.tld
webmaster@virtual.tld	responsibleparty@virtual.tld
group@virtual.tld	recipient1@virtual.tld, recipient2@virtual.tld


Now for the bad news.  Virtual delivery doesn't allow for piping to a
command.  According to the man page virtual(8): 
	This agent was originally based on the Postfix local delivery
	agent.  Modifications mainly consisted of removing code that
	either was nota pplicable or that was not safe in this context:
	aliases, ~user/.forward files, delivery to "|command" or to
	/file/name.

What this means for us is that we cannot create aliases for adding spam
and false positives.  So here comes my hacked up solution: a new transport
map and 2 more transports in master.cf.

/etc/postfix/master.cf:
dspam-add     unix      -       n       n       -       -       pipe flags=Rqu user=virtual argv=/usr/local/bin/dspam --user ${user}@${nexthop} --addspam

dspam-fp     unix       -       n       n       -       -       pipe flags=Rqu user=virtual argv=/usr/local/bin/dspam --user ${user}@${nexthop} --falsepositive

/etc/postfix/transport:
/^.*@addspam.(.*)$/     dspam-add:${1}
/^.*@fp.(.*)$/  dspam-fp:${1}

/etc/postfix/main.cf:
transport_maps = regexp:/etc/postfix/transport
dspam_destination_recipient_limit = 1
dspam-add_destination_recipient_limit = 1
dspam-fp_destination_recipient_limit = 1

Instead of the aliases dspam usually uses (spam-user@virtual.tld), we are
using transports to create a couple 3rd level domains: addspam and fp.
The user now sends spam to user@addspam.virtual.tld and false positives to
user@fp.virtual.tld.  Also note that I have put a recipient limit on all
the dspam transports, this is necessary.




Version 1.1 [May 7, 2004]
Copyright (c)  2004 Leeman Strout.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license can be found here:
http://www.gnu.org/licenses/fdl.html

Changes:
Version 1.1 [May 7, 2004]
Modified master.cf transport entries to include u flag.  It lower-cases
the $user so that DSPAM/procmail deliver correctly to address that
contain capitalization on the LHS.