After publishing eqmail-1.08 I realized that some additional documentation could be helpful. During the creation of  eqmail-1.08  I tried to follow strictly the KISS principle. Means mainly to use as less as possible programs around the mta. Nevertheless the whole picture looks still complex. So the high level flow for incomming mails is

Within procmail triggers  clamav  and  bmf  before using individual filter rules. Local users are allowed to relay. Authenticated users are treated as local (for sure ). Users can access their mails via IMAP with TLS required.

All users and domains are virtual. I use the basic authentication backend for qmail (see man qmail-users), courier-imap and cmd5checkpw always. This looks like a high effort of administration on the first view, but it isn't. All user data are held in a separate database and will be published to every authentication backend after a change (automatically). I apologize that this (dirty written ) solution is not ready to publish it yet.

The following is not a complete documentation about eQmail. It should show how I do handle some things only. For the basic configuration of eQmail there is LWQ still valid. Nevertheless I have some self-written scripts and a web tool in place to make things easier, but I will not talk about this further on.

/* Edit: Below I wrote cmd5checkpw always, because I didn't have had published qmail-chkpw as this was written initially!

Really I use qmail-chkpw instead! */ Authentication is a basic requirement. I decided to use  cmd5checkpw  below always. This way gives me the highest flexibility of authentication methods including AUTH CRAM-MD5. I am using a modified (by me) version which allows to store password hashes too. This way user who decide to do not AUTH CRAM-MD5 do not have clear text passwords. (Hopefully I am able to publish my version of  cmd5checkpw  soon.)

As any other checkpassword compliant tool is fine for covered configurations, some about usage of  cmd5checkpw . By default  cmd5checkpw  is owned by root:root, so we have to set the sticky bit:

# chmod u+s /bin/cmd5checkpw

Alternatively change the owner to  qmaild . Edit your configuration and and change the call  /var/qmail/bin/qmail-smtpd 2>&1  to

/var/qmail/bin/qmail-smtpd /bin/cmd5checkpw 2>&1

/*Important! */Unfortunately, the config file of cmd5checkpw was  /etc/poppasswd  originally but version 0.30 (by E. Hoffmann) changed it to  /var/qmail/users/authuser . To make more confusion there is a reverse patch  reloc.diff  for it in circulation. But good news are that the format is always the same (one entry per line):

user:[encrypted]password

As more I get familiar with all the lots of options as more I like spamdyke. For detailed information check out the documentation. To activate spamdyke it have to be called before  qmail-smtpd , thereabout

 ...
   /usr/local/bin/spamdyke -f /etc/spamdyke.conf \
   /var/qmail/bin/qmail-smtpd ...

I do highly recommend to use spamdyke. It is possible to do smtp authentication and TLS with spamdyke also - without patching this functionality to (net)qmail.

This patch provides an API for  qmail-smtpd  commands. IMHO underestimated qmail-spp is very mighty. Create a config file  /var/qmail/control/smtpplugins  and a folder for plugins  /var/qmail/plugins . Follow the instructions of the documentation. Plugins will be provided through the homepage of qmail-spp.

The file  control/smtpplugins  have to exist in any case! It will not be created automatically!

I do not use plugins heavily anymore, but for SPF functionality. Things like checking for valid recipients or tarpitting I did move to  spamdyke  .

In general I don't know what I should state about procmail overall. I choose it because it's independence and flexibility. In the mail users  ~/.qmail  file I have

|preline /usr/bin/procmail -m /etc/procmailrc <mailuser-home>

Replace  <mailuser-home>  with the full path to the users mail home directory, e.g. like  /var/mails/<username>  .

The file  /etc/procmailrc  contains something like:

HOME=$1    # the value of "$1" comes from the mta 
LOGFILE="$HOME/procmail.log"
MAILDIR="$HOME/.maildir"
DEFAULT="${MAILDIR}/"
# set shell - otherwise, nothing will happen when we call e.g. formail
SHELL="/bin/sh"
# Viruscheck
CLAMDSCAN=/usr/bin/clamdscan
:0
{
  RESULT=`$CLAMDSCAN -v --fdpass --stdout -`

  :0 Di
  * RESULT ?? FOUND
  /dev/null
}
INCLUDERC=$HOME/filter.rc

There should be nothing have to said about clamav itself. Mostly - as in the  procmailrc  above - I'm very rigorous: virus found –> mail deleted!

For unsolicited mail which passes through spamdyke I have bmf in place. In the through  procmailrc  included  ~/filter.rc  (see above) I do

:0fw
| /usr/bin/bmf -p

:0:
* ^X-Spam-Status: Yes
${MAILDIR}/.Spam.bad/

It uses individual user databases. Each user can move unsolicited mail into a spam-folder. A cronjob checks this folder, updates the database and moves classified mails into a separate folder. If the quota of this folder is reached oldest mails will be deleted automatically from within without any further information.

That was an overview how I do handle it typical. The snippets above are recommendations only and/or could be used as a starting point for individual solutions. Similar more completer solutions can be found on the net. Hopefully this makes it understandable why eQmail-1.08 is patched like it is.

I clearly deliberated to do it this way. Maybe the one or the other is wondering that I don't have widely spread tools in use, like

I don't see any benefit, against vpopmail makes the configuration more complex. Virtual users/domains can be handled by (e)(net)qmail by default. In case a POP3 service is needed there is  qmail-pop3d  as well couriers POP3 daemon available. So I decided to never use vpopmail.

The decision to not use spamassassin is mainly depending on the fact that my main OS is Gentoo. The package manager portage handles the CPAN modules by itself. The effort with Perl/CPAN updates is relatively high and summarizes if there is more then one machine to maintain. So in general I try not to use Perl scripts which needs CPAN modules. And bmf as an alternative does the job fine too.

There are a lot of small tools out to solve a specific problem. But procmail together with a bit scripting can make a lot of them obsolete and beside that a bit more individual. It is a personal thing, but I don't like to install/use additional tools if there is not really a need for it. An example would be the autoresponder for qmail. IMHO it is absolut easy to do such functionality with a simple script. Nevertheless - please don't understand this wrong - everybody should use the software which fits its situation as best.

All tools which work with (net)qmail will (should ) work with eQmail too!

I recommend to use the package  ucspi-tcp-0.88  with eQmail-1.08. I have good experiences with the patch  ucspi-tcp-0.88-ipv6.diff19  (together with  0.88-protos-ipv6.patch ,  0.88-bigendian.patch ,  0.88-tcprules.patch ). This enables IPv6 at least for incoming connections. Nevertheless I consider this experimental.

The eQmail source tarball is still not an easy to install MTA. Beside knowledge of how to install (net)qmail itself there should be knowledge about the configuration of the applied patches. For more information about the patches and how to configure them I have to reference to the net yet.

• mlmmj with openSMTPd and eQmail
• eQmail-1.08
• eQmail quick config guide
• qmail-chkpw