#!/bin/bash

# Programmed by Denie Nataprawira (nataprawira@gmail.com)
# (c) 2011 — www.ayodiet.com
#
# Purposes:
# Deletes mailqueue files using matched keywords.
#

cd /var/spool/mqueue

if test -z $1
then
echo “The required parameter was empty. Please try again!”
echo “Format: delkeyw.sh [KEYWORDS]“
echo ” “
exit
fi

echo ” SEARCHING: \”$1\” from all files…”

find . -type f -exec grep -il ‘$1′ {} \; -exec rm -f {} \;

echo ” DONE: \”$1\” has been checked and deleted (if found).”

Source:
http://www.ducea.com/2008/08/19/sendmail-multiple-queues/

Sendmail will use by default a single mail queue. This is what most users will need, and if you don’t have any special requirement you will not care about this. Still for high traffic mail servers it might be useful to split the queue over several directories, as thousands of files in a single directory will become a performance penalty at some point and also processing the queue sequentially will become very slow.

This post will show how we can implement multiple mail queues with modern sendmail versions.
Let’s start by assuming we want to use 8 mail queues. First thing is to create the actual directories as sendmail will not do this by default:

mkdir /var/spool/mqueue/q{1,2,3,4,5,6,7,8}

And fix the permissions to the ones of the original folder /var/spool/mqueue. For ex. this might look like:

chown -R root:smmsp /var/spool/mqueue/q*

using a default sendmail install running on debian. Fix the users to the specific ones found on your system (ls -al /var/spool/mqueue if you are uncertain of this).

Next, we need to enable the multiple queues in the sendmail configuration. For this we will edit sendmail.mc (normally found under /etc/mail) and append one line:

define(`QUEUE_DIR', `/var/spool/mqueue/q*')dnl

and now regenerate sendmail.cf; this is done normally running:

m4 sendmail.mc > /etc/mail/sendmail.cf

(fix your paths appropriately), or if you are using debian sendmail you can just run make all in /etc/mail.

After restarting sendmail, it will start using the multiple queues we defined. Running mailq will output each of the queues:

#mailq
/var/spool/mqueue/q6 is empty
/var/spool/mqueue/q4 is empty
/var/spool/mqueue/q3 is empty
/var/spool/mqueue/q2 is empty
/var/spool/mqueue/q5 is empty
/var/spool/mqueue/q1 is empty
/var/spool/mqueue/q7 is empty
/var/spool/mqueue/q8 is empty
Total requests: 0

Note: if you want to add more folders to the configuration all you have to do is to create the respective folders, set the appropriate permissions and restart sendmail.

If you had existing mails in the queue (most likely if you were looking for this solution), if you want them still processed, move them from /var/spool/mqueue in one of the newly created queues (q1 for ex).

Individual queue directories can be symbolic links to other partitions to spreads load among multiple disks. Queue IDs are unique across queues so you can move the items among queues if you have to.

This is what I’m currently using on “sendmail.mc”. So far quite good and I can blast around 100K emails within few hours. Enjoy!

divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4′)dnl
VERSIONID(`setup for linux’)dnl
OSTYPE(`linux’)dnl
define(`confDEF_USER_ID’, “8:12”)dnl
dnl define(`confAUTO_REBUILD’)dnl
define(`confTO_CONNECT’, `1m’)dnl
define(`confTRY_NULL_MX_LIST’, `True’)dnl
define(`confDONT_PROBE_INTERFACES’, `True’)dnl
define(`PROCMAIL_MAILER_PATH’, `/usr/bin/procmail’)dnl
define(`ALIAS_FILE’, `/etc/aliases’)dnl
define(`STATUS_FILE’, `/var/log/mail/statistics’)dnl
define(`UUCP_MAILER_MAX’, `2000000′)dnl
define(`confUSERDB_SPEC’, `/etc/mail/userdb.db’)dnl
define(`confPRIVACY_FLAGS’, `authwarnings,novrfy,noexpn,restrictqrun’)dnl
define(`confAUTH_OPTIONS’, `A’)dnl
define(`confCHECKPOINTINTERVAL’,`0′)dnl
define(`confCONNECTION_RATE_THROTTLE’,`0′)dnl
define(`confDF_BUFFER_SIZE’,`16384′)dnl
define(`confMAX_DAEMON_CHILDREN’,`0′)dnl
define(`confMAX_QUEUE_RUN_SIZE’,`0′)dnl
define(`confMCI_CACHE_SIZE’,`4′)dnl
define(`confMCI_CACHE_TIMEOUT’,`120s’)dnl
define(`confMIN_QUEUE_AGE’,`0′)dnl
define(`confSAFE_QUEUE’,`false’)dnl
define(`confTO_IDENT’,`0′)dnl
define(`confXF_BUFFER_SIZE’,`16384′)dnl
define(`confQUEUE_LA’,`1000′)dnl
define(`confREFUSE_LA’,`500′)dnl
FEATURE(`nocanonify’, `canonify_hosts’)dnl
FEATURE(`no_default_msa’, `dnl’)dnl
FEATURE(`mailertable’, `hash -o /etc/mail/mailertable.db’)dnl
FEATURE(`virtusertable’, `hash -o /etc/mail/virtusertable.db’)dnl
FEATURE(redirect)dnl
dnl # FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(local_procmail, `’, `procmail -t -Y -a $h -d $u’)dnl
FEATURE(`access_db’, `hash -T<TMPF> -o /etc/mail/access.db’)dnl
EXPOSED_USER(`root’)dnl
DAEMON_OPTIONS(`Name=MTA-v4, Family=inet’)
LOCAL_DOMAIN(`localhost.localdomain’)dnl
MODIFY_MAILER_FLAGS(`PROCMAIL’, `+m’)dnl
dnl # INPUT_MAIL_FILTER(`dk-filter’, `S=inet:8891@localhost’)dnl
FEATURE(`dnsbl’,`bl.spamcop.net’,`554 Mail from $&{client_addr} rejected by bl.spamcop.net’)dnl
FEATURE(`dnsbl’,`rbl-plus.mail-abuse.org’,`”MAPS-listed host: http://mail-abuse.org/cgi-bin/lookup?”$&{client_addr}’)dnl
FEATURE(`dnsbl’,`sbl-xbl.spamhaus.org’,`554 Mail from $&{client_addr} has been rejected by the Spamhaus Blackhole List’)dnl
FEATURE(`dnsbl’,`dnsbl.sorbs.net’,`554 Mail from $&{client_addr} has been rejected by the SORBS’)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl

processor : 1
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2350 HE
stepping : 3
cpu MHz : 1995.000
cache size : 512 KB

processor : 2
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2350 HE
stepping : 3
cpu MHz : 1995.000
cache size : 512 KB

processor : 3
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2350 HE
stepping : 3
cpu MHz : 1995.000
cache size : 512 KB

# Copyright (c) 2001 Sendmail, Inc. and its suppliers.
# All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
# $Id: TUNING,v 1.16 2001/08/19 21:03:38 gshapiro Exp $
#

********************************************
** This is a DRAFT, comments are welcome! **
********************************************

If the default configuration of sendmail does not achieve the
required performance, there are several configuration options that
can be changed to accomplish higher performance. However, before
those options are changed it is necessary to understand why the
performance is not as good as desired. This may also involve hardware
and software (OS) configurations which are not extensively explored
in this document. We assume that your system is not limited by
network bandwidth because optimizing for this situation is beyond
the scope of this guide. In almost all other cases performance will
be limited by disk I/O.

This text assumes that all options which are mentioned here are
familiar to the reader, they are explained in the Sendmail Installation
and Operations Guide; doc/op/op.txt.

There are basically three different scenarios which are treated
in the following:
* Mailing Lists and Large Aliases (1-n Mailing)
* 1-1 Mass Mailing
* High Volume Mail

Depending on your requirements, these may need different options
to optimize sendmail for the particular purpose. It is also possible
to configure sendmail to achieve good performance in all cases, but
it will not be optimal for any specific purpose. For example, it
is non-trivival to combine low latency (fast delivery of incoming
mail) with high overall throughput.

Before we explore the different scenarios, a basic discussion about
disk I/O, delivery modes, and queue control is required.

* Disk I/O
———————————————–

In general mail will be written to disk up before a delivery attempt
is made. This is required for reliability and should only be changed
in a few specific cases that are mentioned later on. To achieve
better disk I/O performance the queue directories can be spread
over several disks to distribute the load. This is some basic tuning
that should be done in all cases where the I/O speed of a single
disk is exceeded, which is true for almost every high-volume
situation except if a special disk subsystem with large (NV)RAM
buffer is used.

Depending on your OS there might be ways to speed up I/O, e.g.,
using softupdates or turning on the noatime mount option. If this
is done make sure the filesystem is still reliable, i.e., if fsync()
returns without an error, the file has really been committed to
disk.

* Queueing Strategies and DeliveryMode
———————————————–

There are basically three delivery modes:

background: incoming mail will be immediately delivered by a new process
interactive: incoming mail will be immediately delivered by the same process
queue: incoming mail will be queued and delivered by a queue runner later on

The first offers the lowest latency without the disadvantage of the
second, which keep the connection from the sender open until the
delivery to the next hop succeeded or failed. However, it does not
allow for a good control over the number of delivery processes other
than limiting the total number of direct children of the daemon
processes (MaxChildren) or by load control options (RefuseLA,
DelayLA). Moreover, it can’t make as good use as ‘queue’ mode can
for connection caching.

Interactive DeliveryMode should only be used in rare cases, e.g.,
if the delivery time to the next hop is a known quantity or if the
sender is under local control and it does not matter if it has to
wait for delivery.

Queueing up e-mail before delivery is done by a queue runner allows
the best load control but does not achieve as low latency as the
other two modes. However, this mode is probably also best for
concurrent delivery since the number of queue runners can be specified
on a queue group basis. Persistent queue runners (-qp) can be used
to minimize the overhead for creating processes because they just
sleep for the specified interval (which shold be short) instead of
exiting after a queue run.

* Queue Groups
———————————————–

In most situations disk I/O is a bottleneck which can be mitigated
by spreading the load over several disks. This can easily be achieved
with different queue directories. sendmail 8.12 introduces queue
groups which are collections of queue directories with similar
properties, i.e., number of processes to run the queues in the
group, maximum number of recipients within an e-mail (envelope),
etc. Queue groups allow control over the behaviour of different
queues. Depending on the setup, it is usually possible to have
several queue runners delivering mails concurrently which should
increase throughput. The number of queue runners can be controlled
per queue group (Runner=) and overall (MaxQueueChildren).

* DNS Lookups
———————————————–

sendmail performs by default host name canonifications by using
host name lookups. This process is meant to replace unqualified
host name with qualified host names, and CNAMEs with the non-aliased
name. However, these lookups can take a while for large address
lists, e.g., mailing lists. If you can assure by other means that
host names are canonical, you should use

FEATURE(`nocanonify’, `canonify_hosts’)

in your .mc file. For further information on this feature and
additional options see cf/README. If sendmail is invoked directly
to send e-mail then either the -G option should be used or

define(`confDIRECT_SUBMISSION_MODIFIERS’, `C’)

should be added to the .mc file.

* Mailing Lists and Large Aliases (1-n Mailing)
———————————————–

Before 8.12 sendmail delivers an e-mail sequentially to all its
recipients. For mailing lists or large aliases the overall delivery
time can be substantial, especially if some of the recipients are located
at hosts that are slow to accept e-mail. Some mailing list software
therefore “split” up e-mails into smaller pieces with fewer recipients.
sendmail 8.12 can do this itself, either across queue groups or
within a queue directory. For the former the option SplitAcrossQueueGroups
option must be set, the latter is controlled by the ‘r=’ field of
a queue group declaration.

Let’s assume a simple example: a mailing lists where most of
the recipients are at three domains: the local one (local.domain)
and two remotes (one.domain, two.domain) and the rest is splittered
over several other domains. For this case it is useful to specify
three queue groups:

QUEUE_GROUP(`local’, `P=/var/spool/mqueue/local, F=f, R=2, I=1m’)dnl
QUEUE_GROUP(`one’, `P=/var/spool/mqueue/one, F=f, r=50, R=3′)dnl
QUEUE_GROUP(`two’, `P=/var/spool/mqueue/two, F=f, r=30, R=4′)dnl
QUEUE_GROUP(`remote’, `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m’)dnl
define(`ESMTP_MAILER_QGRP’, `remote’)dnl
define(`confSPLIT_ACROSS_QUEUEGROUPS’, `True’)dnl
define(`confDELIVERY_MODE’, `q’)dnl
define(`confMAX_QUEUE_CHILDREN’, `50′)dnl
define(`confMIN_QUEUE_AGE’, `27m’)dnl

and specify the queuegroup ruleset as follows:

LOCAL_RULESETS
Squeuegroup
R$* @ local.domain $# local
R$* @ $* one.domain $# one
R$* @ $* two.domain $# two
R$* @ $* $# remote
R$* $# mqueue

Now it is necessary to control the number of queue runners, which
is done by MaxQueueChildren. Starting the daemon with the option
-q5m assures that the first delivery attempt for each e-mail is
done within 5 minutes, however, there are also individual queue
intervals for the queue groups as specified above. MinQueueAge
is set to 27 minutes to avoid that entries are run too often.

Notice: if envelope splitting happens due to alias expansion, and
DeliveryMode is not ‘i’nteractive, then only one envelope is sent
immediately. The rest (after splitting) are queued up and queue
runners must come along and take care of them. Hence it is essential
that the queue interval is very short.

* 1-1 Mass Mailing
———————————————–

In this case some program generates e-mails which are sent to
individual recipients (or at most very few per e-mail). A simple
way to achieve high throughput is to set the delivery mode to
‘interactive’, turn off the SuperSafe option and make sure that the
program that generates the mails can deal with mail losses if the
server loses power. In no other case should SuperSafe be set to
‘false’. If these conditions are met, sendmail does not need to
commit mails to disk but can buffer them in memory which will greatly
enhance performance, especially compared to normal disk subsystems, e.g.,
non solid-state disks.

* High Volume Mail
———————————————–

For high volume mail it is necessary to be able to control the load
on the system. Therefore the ‘queue’ delivery mode should be used,
and all options related to number of processes and the load should
be set to reasonable values. It is important not to accept mail
faster than it can be delivered otherwise the system will be
overwhelmed. Hence RefuseLA should be lower than QueueLA, the number
of daemon children should probably be lower than the number of queue
runnners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option
in 8.12 which allows delaying connections instead of rejecting them.
This may result in a smoother load distribution depending on how
the mails are submitted to sendmail.

* Miscellaneous
———————————————–

Other options that are interesting to tweak performance are
(in no particular order):

SuperSafe: if interactive DeliveryMode is used, then this can
be set to the new value “interactive” in 8.12 to save some disk
synchronizations which are not really necessary in that mode.

———————————————–
Source:
http://luxio.us/gXwyLu

This is a quick walk through on how to set up domain keys on Centos 5 using sendmail. It should also be very similar for Redhat or Fedora.

Most of them involve changing the daemon’s configuration in /etc/sendmail.mc and rebuilding sendmail.cf

Specific things that can affect performance:

dnl # Sendmail, Chap 24.9.13, Page 955
dnl # Disable re-write of queue control file (will result in duplicates
dnl #   if the daemon is interrupted during a delivery)
define(`confCHECKPOINTINTERVAL’,`0′)dnl

dnl # Sendmail, Chap 24.9.21, Page 960
dnl # Disable throttling the acceptance of new connections
define(`confCONNECTION_RATE_THROTTLE’,`0′)dnl

dnl # Sendmail, Chap 24.9.25, Page 967
dnl # Specify the maximum size, in bytes, of buffered df* files (default is
dnl #   4096 bytes; 0 turns this off and is not recommended)
define(`confDF_BUFFER_SIZE’,`16384′)dnl

dnl # Sendmail, Chap 24.9.60, Page 1011
dnl # Disable limit on the daemon spawning new children
define(`confMAX_DAEMON_CHILDREN’,`0′)dnl

dnl # Sendmail, Chap 24.9.66, Page 1016
dnl # Disbale limit on the number of messages that may be processed
dnl #  during any one queue run
define(`confMAX_QUEUE_RUN_SIZE’,`0′)dnl

dnl # Sendmail, Chap 24.9.19, Page 959
dnl # Turn on connection caching and set maximum number of simultaneous
dnl #  outbound connections kept open to 4; default is 2; this option also
dnl #  depends on MCI_CACHE_TIMEOUT (below)
define(`confMCI_CACHE_SIZE’,`4′)dnl

dnl # Sendmail, Chap 24.9.19, Page 959
dnl # Set time limit on how long a cached outbound connection may be
dnl #  kept open to 120 seconds (2 minutes) – see MCI_CACHE_SIZE above
define(`confMCI_CACHE_TIMEOUT’,`120s’)dnl

dnl # Sendmail, Chap 24.9.72, Page 1022
dnl # Disable time delay for queued messages not delivered on the first try
define(`confMIN_QUEUE_AGE’,`0′)dnl

dnl # Sendmail, Chapter 24.9.107, Page 1057
dnl # Disable MTA setting that forces MTA to queue each message and to sync
dnl #   to disk before forking (a system crash may result in lost mail)
define(`confSAFE_QUEUE’,`false’)dnl

dnl # Sendmail, Chap 24.9.109.13, Page 1065
dnl # Disable IDENT (RFC 1413) calls/turn off sending user-host verification
define(`confTO_IDENT’,`0′)dnl

dnl # Sendmail, Chap 24.9.120, Page 1077
dnl # Specify the maximum size, in bytes, of buffered xf* files (default is
dnl #   4096 bytes; 0 turns this off and is not recommended)
define(`confXF_BUFFER_SIZE’,`16384′)dnl

dnl # Sendmail, Chap 4.8.28, Page 192
dnl # Turn off E-Mail canonization (should be done by MSA, and this
dnl #     is a mail relay with no local users)
FEATURE(`nocanonify’)dnl

I’m assuming you’re using a modern version of sendmail – v8.12.10 or later. These settings may be different, or not exist at all, for older versions.

Source

Source: [click here]

Max 30 mins work.

However, life is rarely so simple.
yum search dkim didn't find anything.

So, based on what I could find, I ended up here. Downloaded dkim-filter
2.4.1 and went on an epic voyage of discovery into the RFCs and other stuff.
I just want to install, configure and run the thing!

Anyway. I thought compilation would be straightforward, but no. More
unfamiliar stuff to read. I dutifully read the site.config.m4.dist, copied
to devtools/Site/site.config.m4 and hoped to make some intelligent decisions
on what options to enable.

 # ./Build
...
>Making all in:
>/etc/mail/dkim/dkim-milter-2.4.1/dkim-filter
>Configuration: pfx=, os=Linux, rel=2.6.23.1-10.fc7, rbase=2,
>rroot=2.6.23.1-10, arch=x86_64, sfx=, variant=optimized
>Using M4=/usr/bin/m4
>Creating
>/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter
>using /etc/mail/dkim/dkim-milter-2.4.1/devtools/OS/Linux
>Making dependencies in
>/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter
>make[1]: Entering directory
>`/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter'
>rm -f sm_os.h
>ln -f -s ../../include/sm/os/sm_os_linux.h sm_os.h
>cc -M -I. -I../../include  -I../libdkim/   -D_REENTRANT config.c dkim-ar.c
>dkim-filter.c stats.c test.c util.c   dkim-testkey.c   dkim-testssp.c    >>
>Makefile
>In file included from config.h:23,
>                 from config.c:20:
>dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
>In file included from dkim-ar.h:19,
>                 from dkim-ar.c:23:
>dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
>dkim-filter.c:59:29: error: libmilter/mfapi.h: No such file or directory
>In file included from config.h:23,
>                 from dkim-filter.c:78:
>dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
>In file included from test.c:31:
>test.h:24:29: error: libmilter/mfapi.h: No such file or directory
>In file included from util.c:49:
>dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
>make[1]: *** [depend] Error 1
>make[1]: Leaving directory
>`/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter'
>Making in
>/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter
>make[1]: Entering directory
>`/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter'
>cc -O2 -I. -I../../include  -I../libdkim/   -D_REENTRANT -DXP_MT   -c -o
>config.o config.c
>In file included from config.h:23,
>                 from config.c:20:
>dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
>In file included from config.h:23,
>                 from config.c:20:
>dkim-filter.h:86: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_connect’
>dkim-filter.h:87: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_envfrom’
>dkim-filter.h:88: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_header’
>dkim-filter.h:89: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_eoh’
>dkim-filter.h:90: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_body’
>dkim-filter.h:91: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_eom’
>dkim-filter.h:92: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_abort’
>dkim-filter.h:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
>before ‘mlfi_close’
>make[1]: *** [config.o] Error 1
>make[1]: Leaving directory
>`/etc/mail/dkim/dkim-milter-2.4.1/obj.Linux.2.6.23.1-10.fc7.x86_64/dkim-filter'
>make: *** [all] Error 2

After some googling, a "yum install sendmail-devel" fixed this problem, and
a ./Build -c completed successfully.
I copied /devtools/OS/Linux to /devtools/Site/site.Linux.m4

./Build install was successful after manually creating dirs /usr/man/man15
and /usr/man/man18
Fedora manuals are in /usr/share/man
The files /usr/bin/dk* should have ownership root:root instead of bin.

Sendmail of Fedora 7 is currently 8.14.1:
# sendmail -d0.1
Version 8.14.1
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
 MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
 NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS
 TCPWRAPPERS USERDB USE_LDAP_INIT

I created the keys, updated the dns zone files and decided to use user smmsp
instead of creating yet another user.

I created:
/var/db/dkim :
-rw-r----- 1 smmsp smmsp 887 2008-01-01 08:30 jan2008.admin.key.pem
-rw-r--r-- 1 smmsp smmsp 272 2008-01-01 08:30 jan2008.admin.public.pem

/var/run :
drwxr-xr-x 2 smmsp   smmsp   4096 2008-01-04 09:23 milter

and created this basic start/stop init script:
/etc/init.d/dkim-filter
then:
chkconfig --add dkim-filter
chkconfig dkim-filter on

contents:
>#
># dkim-filter        Starts /usr/bin/dkim-filter
>#
># chkconfig: 2345 67 33
>#
># description: Domain Keys Milter
># processname: dkim-filter
>#
># Source function library.
>. /etc/init.d/functions
>
>[ -f /usr/bin/dkim-filter ] || exit 0
>RETVAL=0
>
>umask 077
>
>start() {
>        echo -n $"Starting dkim-filter: "
>        /usr/bin/dkim-filter -x /etc/mail/dkim.conf
>        RETVAL=$?
>        if [ $RETVAL -eq 0 ]
>        then
>                echo_success
>                touch /var/lock/subsys/dkim-filter
>        else
>                echo_failure
>        fi
>        echo
>}
>stop() {
>        echo -n $"Shutting down dkim-filter: "
>        /bin/kill `cat /var/run/milter/dkim-filter.pid 2> /dev/null ` >
> /dev/null 2>&1
>        RETVAL=$?
>        sleep 3
>        if [ $RETVAL -eq 0 ]
>        then
>                echo_success
>                rm -f /var/lock/subsys/dkim-filter
>                rm -f /var/run/milter/dkim-filter.pid
>        else
>                echo_failure
>        fi
>        echo
>}
>rhstatus() {
>        status dkim-filter
>}
>restart() {
>        stop
>        start
>}
>
>case "$1" in
>  start)
>        start
>        ;;
>  stop)
>        stop
>        ;;
>  status)
>        rhstatus
>        ;;
>  restart|reload)
>        restart
>        ;;
>  condrestart)
>        [ -f /var/lock/subsys/dkim-filter ] && restart || :
>        ;;
>  *)
>        echo $"Usage: $0 {start|stop|status|restart|condrestart}"
>        exit 1
>esac
>
>exit $?

Now for configuration files:

/etc/mail/dkim.conf :
Canonicalization        relaxed/simple
Domain                  /etc/mail/domains
KeyFile                 /var/db/dkim/jan2008.admin.key.pem
#MTA                    MTA
Selector                jan2008.admin
SignatureAlgorithm      rsa-sha256
Socket                  inet:[EMAIL PROTECTED]
#Socket                 /var/run/milter/dkim-filter.sock
Syslog                  Yes
SyslogSuccess           Yes
Userid                  smmsp
PidFile                 /var/run/milter/dkim-filter.pid
SubDomains              Yes
X-Header                No
SendReports             No

/etc/mail/domains contains just one domain on one line.

and added to sendmail.rc:
INPUT_MAIL_FILTER(`dkim-filter', `S=inet:[EMAIL PROTECTED]')

I started the script with
/etc/init.d/dkim-filter start
and it worked, eg:
>Jan  4 10:58:10 gaia dkim-filter[6033]: Sendmail DKIM Filter v2.4.1 starting
>(args: -x /etc/mail/dkim.conf)

It even adds signatures to my messages (hopefully to this one), but silently
crashes regularly without any indication on processing a simple locally
generated mail from a perl script and/or/exor from logwatch or virus
notification from MailScanner. eg:

DKIMDEBUG=ct :
>Jan  3 02:57:18 gaia sendmail[12260]: m031vIL6012260: from=<[EMAIL
>PROTECTED]>, size=1780,, nrcpts=1, msgid=<[EMAIL PROTECTED]>,
>proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
>Jan  3 02:57:18 gaia dkim-filter[6926]: thread 0x41e02950 header
>Jan  3 02:57:18 gaia last message repeated 6 times
>Jan  3 02:57:18 gaia dkim-filter[6926]: thread 0x41e02950 eoh
>Jan  3 02:57:18 gaia sendmail[12260]: m031vIL6012260:
>milter_sys_read(dkim-filter): cmd read returned 0, expecting 5
>Jan  3 02:57:18 gaia sendmail[12260]: m031vIL6012260: Milter (dkim-filter): to
>error state
>Jan  3 02:57:18 gaia sendmail[12260]: m031vIL6012260: to=<[EMAIL PROTECTED]>,
>delay=00:00:00, mailer=esmtp, pri=31780, stat=queued

I have spent the last couple of days trying to solve this
The only relevant information I found was Jim Hermann's useful message and
thread last month
http://www.mail-archive.com/dkim-milter-discuss@lists.sourceforge.net/msg00409.html

I'm disappointed, disillusioned and frustrated in trying to nail jelly to a
wall... This doesn't say anything useful at all!
>milter_sys_read(dkim-filter): cmd read returned 0, expecting 5

It only seems to happen by locally generated mail, sometimes it even seemed
as if having a Reply-To: field influenced its crash frequency, but without
real diagnostic tools, skills and a lot of time, I can't solve it. I'm an
experienced sysadmin, not a C programmer! Programmers should try to make all
our lives easier!  

I want to get this working reliably and dependably on a few production
systems, and know what options to compile with and what settings to use for
Fedora, but I'm now stumped.

When it does work, another gripe is this padding too short error, which may
or may not be a reason for the verification failure:
>Jan  4 08:14:35 gaia dkim-filter[8389]: m047EY6O010080 SSL error:04067069:rsa
>routines:RSA_EAY_PUBLIC_DECRYPT:pkcs1 padding too short; error:04077068:rsa
>routines:RSA_verify:bad signature
>Jan  4 08:14:35 gaia dkim-filter[8389]: m047EY6O010080: bad signature data
>Jan  4 08:14:35 gaia sendmail[10080]: m047EY6O010080: Milter insert (1):
>header: Authentication-Results:  gaia.haveland.com; dkim=neutral (verification
>failed) [EMAIL PROTECTED]

How can a gmail signature fail verification? What did it fail on? What is
the "i" in  "header.i" ?
It was a mysql mailing list, so perhaps other headers got in the way, but
this isn't what I would call a robust solution! Omitheaders command in
dkim.conf seems to be a blanket fudge.

If we are to stand a chance of defeating spammers, then we have to make DKIM
easier to install and configure so mere mortals can install and use it, and
encourage adoption.  I'm sure many would like to see dkim-filter available
in rpm for various distros.

However, Network Solutions, amongst others need to wake up and allow people
to modify their DNS TXT attributes... Here's what their completely
ridiculous FAQ says on the subject:
http://customersupport.networksolutions.com/article.php?id=369

>"Can I Make Changes To The TXT Record
>
> Network Solutions does not currently support changes to the
> TXT record for a domain name registration.
>
> The TXT Record is strictly informational, not functional."

What planet are they living on?

Cheers,
Andy.