[dkim-milter-discuss] dkim 2.4.1 woes on Fedora 7 x86_64

[Andrew Haveland-Robinson]

I wanted to use DKIM with Sendmail on Fedora 7. Easy, I thought, just do the
following:

1. yum install dkim-filter (+dependencies)
2. create keys
3. edit a couple of template files
4. update dns txt records
5 /etc/init.d/named reload
5 /etc/init.d/dkim-filter start
6 /etc/init.d/sendmail (or MailScanner) restart

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
...

/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,
dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
In file included from dkim-ar.h:19,
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,
dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
test.h:24:29: error: libmilter/mfapi.h: No such file or directory
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,
dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory
In file included from config.h:23,
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

#
# 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)
;;
*)
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:***@localhost
#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:***@localhost')

I started the script with
/etc/init.d/dkim-filter start

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

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

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-***@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

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

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.

[Ben Lentz]

Post by Andrew Haveland-Robinson
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.

Hey Andy,
As an experienced sysadmin, I'm sure you're aware that the developers of
a given software project rarely cater directly to a specific
distribution. This software is used by many folks on many different
platforms. There's heavy concentration on making sure that things are
cross-platform compatible as opposed to "installable in 30 minutes on
Fedora 7." After all, it's generally up to the folks who make the
distribution to configure packages for their distribution, not up to the
developers of the software itself.

I agree that an RPM would be nice. All it takes is a spec file and a
little time, and since you've already solved the majority of the
distribution-specific problems, you might be primed and ready to
construct an RPM that saves the next person a lot of time. You can also
lobby the developers and maintainers of Fedora to include your package
in the extras/contrib yum repository for distribution to others.

The man page thing can be fixed by adding define(`confMANROOT',
`/usr/share/man/man') to the site.config.m4... this will put the manuals
in the right place on a Fedora system (unless they've moved them... I
can't keep up with a F-release every 6 months) at the ./Build install step.

As opposed to relying on a mailing list email from gmail to check
verification (which is broken for any number of reasons), try sending
email to the sa-test --at-- sendmail.net autoresponder. It will both
verify the mail you send it, and properly sign a response that you can
verify when it comes back. There are also other DKIM autoresponders
available if you google around a little.

As far as the crash, it might be helpful to get versions of openssl and
openssl-devel on your system, ensure that no stray, random versions of
openssl headers exist. Being able to successfully compile, but not
successfully run a piece of software can sometimes be caused by running
against different versions of shared libraries than their headers, so
it's a good thing to check, IMO. Output of ldd /usr/bin/dkim-filter and
/usr/bin/dkim-filter -V might also be helpful. I don't run any x86_64,
but I have not had stability trouble with dkim-filter on i386. I will
let the other, more skilled programmers on the list provide additional
suggestions, like providing gdb or strace output... which I don't know
are helpful yet.

[Tony Earnshaw]

Ben Lentz skrev, on 04-01-2008 14:41:

[...]

Post by Ben Lentz
As an experienced sysadmin, I'm sure you're aware that the developers of
a given software project rarely cater directly to a specific
distribution. This software is used by many folks on many different
platforms. There's heavy concentration on making sure that things are
cross-platform compatible as opposed to "installable in 30 minutes on
Fedora 7." After all, it's generally up to the folks who make the
distribution to configure packages for their distribution, not up to the
developers of the software itself.

[...]

I already wrote to Andy off list telling him I had a Fedora (for that
matter RHEL5 too) source rpm for him and he responded. He has to build
himself on x86_64 (my production rigs use ia32) , I've tested the srpm
build on RHEL5 x86_64, but that's not Fedora 7.

Best, and a fine 2008,

--Tonni

PS: the spec and all other Sendmail DKIM stuff is my own, so I (as a
Postfix person) get to take the rap when it doesn't work. Mind you, it's
worked for me for months and months and months.

[Andrew Haveland-Robinson]

Hi Ben,

Thanks to you and everyone for their help and patience with my frustration!

Post by Ben Lentz

Post by Andrew Haveland-Robinson
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.

Hey Andy,
As an experienced sysadmin, I'm sure you're aware that the developers of
a given software project rarely cater directly to a specific
distribution. This software is used by many folks on many different
platforms. There's heavy concentration on making sure that things are
cross-platform compatible as opposed to "installable in 30 minutes on
Fedora 7." After all, it's generally up to the folks who make the
distribution to configure packages for their distribution, not up to the
developers of the software itself.

Yes, my perception was a little skewed through exasperation and I've only
worked with RedHat flavours of Linux for the last decade. All the couple of
dozen machines I manage are of RH lineage. Of course, it is a subset of
Linux of a subset of a multitude of Unices, which you are all valiantly
trying to cater for!

Post by Ben Lentz
I agree that an RPM would be nice. All it takes is a spec file and a
little time, and since you've already solved the majority of the
distribution-specific problems, you might be primed and ready to
construct an RPM that saves the next person a lot of time. You can also
lobby the developers and maintainers of Fedora to include your package
in the extras/contrib yum repository for distribution to others.

Yes, I would strongly lobby for this and lower the entry barrier for
'normal' administrators...

Post by Ben Lentz
The man page thing can be fixed by adding define(`confMANROOT',
`/usr/share/man/man') to the site.config.m4... this will put the manuals
in the right place on a Fedora system (unless they've moved them... I
can't keep up with a F-release every 6 months) at the ./Build install step.

F-ing hell... :-) Updates are frequent, but rarely cause problems for me,
though there was a classic last year that hosed cron.d... so those relying
on automatic updates didn't get the fix automatically a couple of days
later... Open mouth, insert foot...

Post by Ben Lentz
As opposed to relying on a mailing list email from gmail to check
verification (which is broken for any number of reasons), try sending
email to the sa-test --at-- sendmail.net autoresponder. It will both
verify the mail you send it, and properly sign a response that you can
verify when it comes back. There are also other DKIM autoresponders
available if you google around a little.

No, not relying on gmail, just noticed it didn't verify. Perhaps signed
messages should be delimited to protect against appendices, and made clear
where the authentication begins and ends?
Like the OSI 7 layer model, can't dkim not make use of wrappers and
encapsulation to preserve integrity during transmission/forwarding?

I used a couple of dkimi test addresses... my test messages did verify ok,
however my verification of the reply from dkim-***@testing.dkim.org gave:
Authentication-Results: gaia.haveland.com; dkim=permerror (verification
error: signature timestamp in the future) header.i=***@dkim.org

My ntp source is a nuclear physics research institute, and I'm sure my time
is accurate so I think someone ought to check the machine.

Post by Ben Lentz
As far as the crash, it might be helpful to get versions of openssl and
openssl-devel on your system, ensure that no stray, random versions of
openssl headers exist. Being able to successfully compile, but not
successfully run a piece of software can sometimes be caused by running
against different versions of shared libraries than their headers, so
it's a good thing to check, IMO. Output of ldd /usr/bin/dkim-filter and
/usr/bin/dkim-filter -V might also be helpful. I don't run any x86_64,
but I have not had stability trouble with dkim-filter on i386. I will
let the other, more skilled programmers on the list provide additional
suggestions, like providing gdb or strace output... which I don't know
are helpful yet.

Thanks for the hints... I compiled again with a vanilla version, relying on
site defaults, but it still crashes predictably on some locally generated
messages.

ldd /usr/bin/dkim-filter :
linux-vdso.so.1 => (0x00007fffb5dfd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003160c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000315f400000)
libssl.so.6 => /lib64/libssl.so.6 (0x000000362e200000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x000000362de00000)
libc.so.6 => /lib64/libc.so.6 (0x000000315ec00000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003164c00000)
/lib64/ld-linux-x86-64.so.2 (0x000000315e800000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003bb5200000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003bb4e00000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003b08e00000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003bb5a00000)
libz.so.1 => /lib64/libz.so.1 (0x0000003160400000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003bb4a00000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000316aa00000)

dkim-filter: Sendmail DKIM Filter v2.4.1
Compiled with OpenSSL 0.9.8b 04 May 2006
Supported signing algorithms:
rsa-sha1
rsa-sha256
Supported canonicalization algorithms:
relaxed
simple

previous version:
dkim-filter -V
dkim-filter: Sendmail DKIM Filter v2.4.1
Compiled with OpenSSL 0.9.8b 04 May 2006
Supported signing algorithms:
rsa-sha1
rsa-sha256
Supported canonicalization algorithms:
relaxed
simple
Active code options:
_FFR_CAPTURE_UNKNOWN_ERRORS

I will try and get it to do a core dump and get a trace.

Thanks again,
Andy.

[SM]

Post by Andrew Haveland-Robinson
No, not relying on gmail, just noticed it didn't verify. Perhaps signed
messages should be delimited to protect against appendices, and made clear
where the authentication begins and ends?
Like the OSI 7 layer model, can't dkim not make use of wrappers and
encapsulation to preserve integrity during transmission/forwarding?

There's an option (BodyLengths ) which will include the body length
tag when signing a message. This allows the message to pass
verification if it goes through a mailing list which append a
footer. DKIM-signed messages are generally not affected by
forwarding as the signed headers and body content is not modified by
forwarders.

Post by Andrew Haveland-Robinson
I used a couple of dkimi test addresses... my test messages did verify ok,
Authentication-Results: gaia.haveland.com; dkim=permerror (verification
My ntp source is a nuclear physics research institute, and I'm sure my time
is accurate so I think someone ought to check the machine.

I would recommend using ntp if you are using DKIM as it prevents
verification failures due to an incorrect timestamp as in the above example.

Post by Andrew Haveland-Robinson
dkim-filter: Sendmail DKIM Filter v2.4.1
Compiled with OpenSSL 0.9.8b 04 May 2006
rsa-sha1
rsa-sha256
relaxed
simple

You have the correct version of OpenSSL.

Post by Andrew Haveland-Robinson
I will try and get it to do a core dump and get a trace.

That's the next step if you are still getting a crash. See Murray's
message about setting confOPTIMIZE in site.config.m4 before
compiling dkim-milter. The trace will provide us with some debugging
information to identify the cause of the crash in your environment.

Regards,
-sm

[Daniel Black]

Post by SM

Post by Andrew Haveland-Robinson
No, not relying on gmail, just noticed it didn't verify. Perhaps signed
messages should be delimited to protect against appendices, and made clear
where the authentication begins and ends?
Like the OSI 7 layer model, can't dkim not make use of wrappers and
encapsulation to preserve integrity during transmission/forwarding?

There's an option (BodyLengths ) which will include the body length
tag when signing a message. This allows the message to pass
verification if it goes through a mailing list which append a
footer. DKIM-signed messages are generally not affected by
forwarding as the signed headers and body content is not modified by
forwarders.

I did a trial patch to enable a database of addresses that will receive the
body length tag. Database entries need to be managed using raw db tools (ref
comment "2007-11-03 23:29").

http://sourceforge.net/tracker/index.php?func=detail&aid=1811969&group_id=139420&atid=744361

For other email lists, like this one, you need to account for the [listname]
tags.

my opinion is that gracefull handling of email lists fudges will ultimately
determine if DKIM is readily adopted in an organisation.

perhaps the verification process could almost brute force the email list
mangles. This would involve:
1. attempting the subject line unfudges (removing [])
s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/'
2. attempting to remove the last 5 (configurable) lines off the email and see
if that passes.

Yes this going to be really ugly to implement. Is it worth it?

Am I missing something in the standard that says a verifying server should not
attempt to verify the original signature?

[SM]

Hi Daniel,

Post by Daniel Black
I did a trial patch to enable a database of addresses that will receive the
body length tag. Database entries need to be managed using raw db tools (ref
comment "2007-11-03 23:29").

That's an interesting patch.

Post by Daniel Black
For other email lists, like this one, you need to account for the [listname]
tags.

You can include the original subject on signing and do a comparison
with the new subject line before using the original subject for verification.

Post by Daniel Black
my opinion is that gracefull handling of email lists fudges will ultimately
determine if DKIM is readily adopted in an organisation.

It's one-to-one communication that's more important and that's where
DKIM can make a difference. Mailing list failures aren't critical
unless we do an outright reject on verification failures. You are
right in that organisations may push off adoption until mailing lists
are handled gracefully.

Post by Daniel Black
perhaps the verification process could almost brute force the email list
1. attempting the subject line unfudges (removing [])
s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/'
2. attempting to remove the last 5 (configurable) lines off the email and see
if that passes.
Yes this going to be really ugly to implement. Is it worth it?

If we want to increase the pass rate only, it may be worth it. The
last lines would have to be removed which means doing a body
rewrite. That has a significant overhead. I made a suggestion above
on how the subject line can be unfudged.

Post by Daniel Black
Am I missing something in the standard that says a verifying server should not
attempt to verify the original signature?

No.

Regards,
-sm

[Daniel Black]

Post by SM

Post by Daniel Black
For other email lists, like this one, you need to account for the
[listname] tags.

You can include the original subject on signing and do a comparison
with the new subject line before using the original subject for verification.

Clarifing just to make sure I understand you:

Subject: email list handling

Sign this origination subject line ^

and on verification

compare new subject like
Subject: [dkim-milter-discuss] email list handling

to the original and indentify that only [dkim-milter-discuss] was added.

and because of this verify using the original?

If you receive an email you only receive one subject so how do you compare the
original if you don't know it. Could compare it to a z= header if the sender
added it.

I'd suggest once [.*] is detected that second sha1/256 hash state is need -
one for with and one for without the [.*].

Post by SM

Post by Daniel Black
my opinion is that gracefull handling of email lists fudges will
ultimately determine if DKIM is readily adopted in an organisation.

It's one-to-one communication that's more important and that's where
DKIM can make a difference. Mailing list failures aren't critical
unless we do an outright reject on verification failures.

True - but how do you identify a mailing list compared to a normal email
reliably? What kind of actions/delays/implementations would occur in an
organisation to gain the integrity of DKIM for one-to-one and not loose
mailing list emails.

Post by SM
You are
right in that organisations may push off adoption until mailing lists
are handled gracefully.

Post by Daniel Black
perhaps the verification process could almost brute force the email list
1. attempting the subject line unfudges (removing [])
s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/'
2. attempting to remove the last 5 (configurable) lines off the email and
see if that passes.
Yes this going to be really ugly to implement. Is it worth it?

If we want to increase the pass rate only, it may be worth it. The
last lines would have to be removed which means doing a body
rewrite.

Rather than a body rewrite, the milter maintains a buffer of the last X lines.
These last X lines will not be added to the running hash state until the
final verification (milter eom).
That way the last complete hash is the total of the final hash state including
the buffer. If this doesn't verify then..
Take the hash state with 1 added line and verify....and failing that...
Take the hash state with 2 added lines.....and failing that...
Take the hash state with X-1 added lines.....

Post by SM
That has a significant overhead.

Hopefully the stateful hash calculation is significantly less than body
rewrite. Its certianly less expensive that a total hash recaluation over the
entire message X times.

Post by SM
I made a suggestion above
on how the subject line can be unfudged.

Unfudging should be easy. I think you'll need to maintain two (or more - see
below) hash states there after.

Additional hash calculation time:

Best case - no subject changes and no addition lines (i.e. a typical non-email
ilst message)
Same amount of hash calculation is performed.

Second Case - subject header modified - no added lines - person just happens
to add a [XXX] in the header.
Hash is calculated twice over the entire message - once with and one without
the header unfudged

Ugly Case - subject header mutulation - person just happens to add [XXX] [YYY]
[ZZZ] to the subject line
Hash calculated 4 times over the entire message. 3 after selectively omiting
each [] value and once for the original.

Worst Case: header modified (assumed once) and X-1 lines added before a passed
verification
Hash is calculated up till the final state twice
Hash is appened (X-1) * 2 for a number of lines

Absolute Worst Case: header modified by adding Y x [ ] values to the header
and X-1 lines added before a passed verification
Hash is calculated up till the final state Y+1 times
Hash is appened (X-1) * (Y + 1) for a number of lines

After all this it is probably worth associating the number of lines appended
and the [XXX] value with the mailing list (return path address?) so future
calculations can be optimised. Given the ads at the bottom of this list just
changed this sounds like a potentially fault possible technique that also
allows for changes.

[SM]

Hi Daniel,

Post by Daniel Black
Subject: email list handling
Sign this origination subject line ^
and on verification
compare new subject like
Subject: [dkim-milter-discuss] email list handling
to the original and indentify that only [dkim-milter-discuss] was added.
and because of this verify using the original?

Yes.

Post by Daniel Black
If you receive an email you only receive one subject so how do you compare the
original if you don't know it. Could compare it to a z= header if the sender
added it.

You can only compare if you have the z= tag.

Post by Daniel Black
I'd suggest once [.*] is detected that second sha1/256 hash state is need -
one for with and one for without the [.*].

We have to compute two hashes then.

Post by Daniel Black
True - but how do you identify a mailing list compared to a normal email
reliably? What kind of actions/delays/implementations would occur in an
organisation to gain the integrity of DKIM for one-to-one and not loose
mailing list emails.

The mailing list manager which generally breaks DKIM signatures adds
a List- header. We have to be careful here as any "rules" we put in
may be used for questionable motives.

You are equating verification failures with "bad" mail. I consider
the failures as unsigned mail. I don't reject on failures and as
such I won't lose mailing list emails. If your (one-to-one) email is
DKIM signed and verifies, it's easier for me to whitelist you without
having to track any IP address change at your end. If the email goes
through forwarders, it will still verify successfully. I'm not sure
what you mean by actions and delays. I can also use DKIM for
"reputation" assessments.

Post by Daniel Black
Rather than a body rewrite, the milter maintains a buffer of the last X lines.
These last X lines will not be added to the running hash state until the
final verification (milter eom).
That way the last complete hash is the total of the final hash state including
the buffer. If this doesn't verify then..
Take the hash state with 1 added line and verify....and failing that...
Take the hash state with 2 added lines.....and failing that...
Take the hash state with X-1 added lines.....

The purpose of the l= tag is to avoid the steps above.

Post by Daniel Black
Hopefully the stateful hash calculation is significantly less than body
rewrite. Its certianly less expensive that a total hash recaluation over the
entire message X times.

We still have to do a body rewrite as passing unsigned content opens
the way for all kinds of tricks.

Post by Daniel Black
Unfudging should be easy. I think you'll need to maintain two (or more - see
below) hash states there after.

Technically, there's nothing that prevents us from "unfudging". Is
it worth it? We have to deal with the cases you mentioned which is
non-trivial.

Post by Daniel Black
After all this it is probably worth associating the number of lines appended
and the [XXX] value with the mailing list (return path address?) so future
calculations can be optimised. Given the ads at the bottom of this list just
changed this sounds like a potentially fault possible technique that also
allows for changes.

What if the number of lines appended changes in future? DKIM has no
association with the Return-path address. It's easier to associate
the return-path with some token instead of having DKIM do all these
calculations.

Regards,
-sm

[Murray S. Kucherawy]

Post by SM

Post by Daniel Black
If you receive an email you only receive one subject so how do you
compare the original if you don't know it. Could compare it to a z=
header if the sender added it.

You can only compare if you have the z= tag.

...or if you can apply some kind of heuristic to the Subject: header thus
generating one or more possible originals.

Post by SM

Post by Daniel Black
True - but how do you identify a mailing list compared to a normal
email reliably?

This is the key: You can't. A mailing list could be as simple as an alias
that expands to lots of other addresses. In that case the "List-*:"
header fields mentioned elsewhere in this thread don't get added, yet
there's clearly a change in recipients, the To: header doesn't match
anymore, etc.

Some MLMs munge Subject: headers, some don't. Some add footers, some
don't. Some that do add footers add the same one each time, some select
from a rotation of possible footers of possibly different sizes.

There's no single uniform behaviour or common property among them to
distinguish MLM traffic from "regular" mail. We definitely wish that
weren't the case. Similarly, there's no standard or universally applied
form for auto-responders (e.g. vacation messages) either.

Post by SM
You are equating verification failures with "bad" mail. I consider the
failures as unsigned mail. I don't reject on failures and as such I
won't lose mailing list emails. If your (one-to-one) email is DKIM
signed and verifies, it's easier for me to whitelist you without having
to track any IP address change at your end. If the email goes through
forwarders, it will still verify successfully. I'm not sure what you
mean by actions and delays. I can also use DKIM for "reputation"
assessments.

I cite this paragraph only to indicate that I agree with each of its
important points. Moreover, several places in the DKIM RFC make clear
that a message whose verification fails should be treated as unsigned, not
discarded outright.

Of course, the verifier can do whatever it wishes with failures. For
example, the SPF/SID filter we wrote was originally intended to add an
Authentication-Results: header and be done, but people requested that we
add patches to it to actually reject mail that failed either or both
tests. Clearly people are looking for anything they can get to stem the
tide of spam and phishing, even taking very aggressive measures to do so.
But as a result, false negatives then become a big risk.

The generally recommended use of all of this authentication work is that a
verification "pass" using a method you trust should simply bypass some of
your spam or virus checks, a form of whitelisting. Failures can happen
for legitimate reasons (Yahoo! DomainKeys signatures break when Yahoo!
groups sends mail, for example; some Google mail also fails when it goes
through their list distribution service), so you have to take that into
account when making your ultimate reject/accept decision.

Interesting discussion!

-MSK

[Murray S. Kucherawy]

Post by Daniel Black
perhaps the verification process could almost brute force the email list
1. attempting the subject line unfudges (removing [])
s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/'
2. attempting to remove the last 5 (configurable) lines off the email and see
if that passes.

You certainly could do this, though it could require recomputing the hash
several times which is a bit on the expensive side, and dangerous if you
have an MTA waiting for a response from the server.

It's also worth noting that the discussions among the original DKIM
implementors, as I recall, leaned in the direction of recommending that a
failed signature should still be considered failed even if you can
determine what mangling took place to cause it to fail, and thus determine
what the original signed message looked like. This is to some extent what
the "z=" tag is for.

Post by Daniel Black
Yes this going to be really ugly to implement. Is it worth it?
Am I missing something in the standard that says a verifying server
should not attempt to verify the original signature?

There's nothing in the standard that makes that improper. In fact the
standard is deliberately vague on the topic of interpreting
multiply-signed messages. It's up to the verifier to decide how to handle
them. The only guidance it provides is to say that one can't rely on the
order of the signatures to be meaningful because we've seen header order
get mangled in transit before.

The current libdkim implementation evaluates all of them by default, in
the order in which they appear in the headers. The filter doesn't allow
you to say which one(s) to prefer, but it could if that turns out to be a
good idea. The library allows the caller to specify which ones it wants
to consider and in which order.

[Daniel Black]

Post by Murray S. Kucherawy

Post by Daniel Black
perhaps the verification process could almost brute force the email list
1. attempting the subject line unfudges (removing [])
s/Subject:/\([^[]*\)\[[^\]*] \?\(.*\)/\1\2/'
2. attempting to remove the last 5 (configurable) lines off the email and
see if that passes.

You certainly could do this, though it could require recomputing the hash
several times which is a bit on the expensive side, and dangerous if you
have an MTA waiting for a response from the server.

Is the incremental hash state approach acceptable? I was looking at
./libdkim/dkim-canon.c and it does seem like a non-trival amount of effort.

Post by Murray S. Kucherawy
It's also worth noting that the discussions among the original DKIM
implementors, as I recall, leaned in the direction of recommending that a
failed signature should still be considered failed even if you can
determine what mangling took place to cause it to fail, and thus determine
what the original signed message looked like.

If you can determine what the original signed message looked like and it
verified ok can it be considered a pass?

"Yes" would certianly make it more useful to admins. Especially to those that
don't want to debug dkim failures every time a user adds themselves to an
email list. Admins may need to think wider to determine if this would
introduce risk in replay attacks by the appending short amounts of text.

Post by Murray S. Kucherawy
This is to some extent what
the "z=" tag is for.

Useful for debugging a failure with the assumed cooperation of the sender in
adding the "z=" flag. Not sure any admin would want to be debugging for email
list traffic for DKIM failures considering its a known risk in the standard.

Post by Murray S. Kucherawy

Post by Daniel Black
Yes this going to be really ugly to implement. Is it worth it?
Am I missing something in the standard that says a verifying server
should not attempt to verify the original signature?

There's nothing in the standard that makes that improper. In fact the
standard is deliberately vague on the topic of interpreting
multiply-signed messages. It's up to the verifier to decide how to handle
them. The only guidance it provides is to say that one can't rely on the
order of the signatures to be meaningful because we've seen header order
get mangled in transit before.
The current libdkim implementation evaluates all of them by default, in
the order in which they appear in the headers. The filter doesn't allow
you to say which one(s) to prefer, but it could if that turns out to be a
good idea. The library allows the caller to specify which ones it wants
to consider and in which order.

This would make sence on a small volume server where you add a signature now
and then for emailing lists that you choose to trust. A large volume server
would require the user to self manage a whitelist of signatures for
themselves which isn't impossible either.

[Murray S. Kucherawy]

Post by Daniel Black
Is the incremental hash state approach acceptable? I was looking at
./libdkim/dkim-canon.c and it does seem like a non-trival amount of effort.

It depends on how the SHA contexts (objects) work. For example, if
calling SHA1_Final() on a SHA1 context makes it unusable for further calls
to SHA1_Update(), much like fclose() would for a FILE handle, then the
only thing you can do is maintain several parallel SHA1 contexts and feed
them data separately. That would mean two header hashes (one for the
received Subject: header and one for what you think the original is) and N
body hashes where you want to try omitting up to (N-1) trailing lines.

The SHA API documentation (i.e. the man page) doesn't say whether or not
you can safely do this, so it's prudent for me to assume I can't and thus
I must err on the expensive side.

Post by Daniel Black
If you can determine what the original signed message looked like and it
verified ok can it be considered a pass?

There were strong opinions in the DKIM working group in favour of the
answer to that being a solid "no". You can use the "z=" tag or other
heuristics to determine in an automatic fashion what got munged in transit
(MLM or otherwise) but the verifier should still consider it a failure to
verify.

However the way the RFC is written, such courses of action are not
expressly forbidden. The use of "z=" is clearly intended for diagnostic
work and not included in pass/fail decisions, but there's nothing
indicating doing so actually violates the standard.

Post by Daniel Black
"Yes" would certianly make it more useful to admins. Especially to those
that don't want to debug dkim failures every time a user adds themselves
to an email list. Admins may need to think wider to determine if this
would introduce risk in replay attacks by the appending short amounts of
text.

I think the more overall correct thing to do is to encourage people who
are concerned their mail might be munged by appended footers to sign with
the "l=" tag, and encourage MLM operators in general to re-sign their mail
after munging Subject: headers and adding footers.

Insisting on those, however, may or may not be pragmatic.

Post by Daniel Black

This is to some extent what the "z=" tag is for.

Useful for debugging a failure with the assumed cooperation of the
sender in adding the "z=" flag. Not sure any admin would want to be
debugging for email list traffic for DKIM failures considering its a
known risk in the standard.

dkim-filter has tools which make use of "z=" if present to highlight what
got changed in transit, so the admin does get some assistance from us
there. Of course, the question then is "OK, so now what?"

Post by Daniel Black
This would make sence on a small volume server where you add a signature
now and then for emailing lists that you choose to trust. A large volume
server would require the user to self manage a whitelist of signatures
for themselves which isn't impossible either.

Sorry, I'm missing what you're saying here. A whitelist of signatures?
Can you provide an example?

These are all interesting questions. I think I'll summarize them and
bring them up on the DKIM working group list for some more dialog and
suggestions.

-MSK

[Daniel Black]

Post by Murray S. Kucherawy

Post by Daniel Black
Is the incremental hash state approach acceptable? I was looking at
./libdkim/dkim-canon.c and it does seem like a non-trival amount of effort.

It depends on how the SHA contexts (objects) work. For example, if
calling SHA1_Final() on a SHA1 context makes it unusable for further calls
to SHA1_Update(), much like fclose() would for a FILE handle, then the
only thing you can do is maintain several parallel SHA1 contexts and feed
them data separately. That would mean two header hashes (one for the
received Subject: header and one for what you think the original is) and N
body hashes where you want to try omitting up to (N-1) trailing lines.

guess I was hoping a more flexable SHA API existed.

Post by Murray S. Kucherawy
The SHA API documentation (i.e. the man page) doesn't say whether or not
you can safely do this, so it's prudent for me to assume I can't and thus
I must err on the expensive side.

I may play with it and look at the implementation. The self tests should be
able to detect failure however I understand your prudence.

Post by Murray S. Kucherawy

Post by Daniel Black
If you can determine what the original signed message looked like and it
verified ok can it be considered a pass?

There were strong opinions in the DKIM working group in favour of the
answer to that being a solid "no".

That make sense from a standards ideological point of view.

Post by Murray S. Kucherawy
You can use the "z=" tag or other
heuristics to determine in an automatic fashion what got munged in transit
(MLM or otherwise) but the verifier should still consider it a failure to
verify.
However the way the RFC is written, such courses of action are not
expressly forbidden. The use of "z=" is clearly intended for diagnostic
work and not included in pass/fail decisions, but there's nothing
indicating doing so actually violates the standard.

Post by Daniel Black
"Yes" would certianly make it more useful to admins. Especially to those
that don't want to debug dkim failures every time a user adds themselves
to an email list. Admins may need to think wider to determine if this
would introduce risk in replay attacks by the appending short amounts of
text.

I think the more overall correct thing to do is to encourage people who
are concerned their mail might be munged by appended footers to sign with
the "l=" tag,

So my bodylength tag database patch may be useful.

Post by Murray S. Kucherawy
and encourage MLM operators in general to re-sign their mail
after munging Subject: headers and adding footers.

This still involves the verifying party trusting the MLM operator. By
delivering it though it could be taken as the originator was verified rather
than a trusted third party (MLM operator). Probably just a education of
users/admins issue.

Post by Murray S. Kucherawy
Insisting on those, however, may or may not be pragmatic.

Producing documentation about DKIM from a MLM operators perspective may
alleviate some pragmatism.

Other solutions could be providing patches to software like mailman that will
reject DKIM email without bodylength tags that it intends to mangle.

Maybe modifying the documentation to highlight the risks of subject and body
prepend/appending.

Post by Murray S. Kucherawy

Post by Daniel Black

This is to some extent what the "z=" tag is for.

Useful for debugging a failure with the assumed cooperation of the
sender in adding the "z=" flag. Not sure any admin would want to be
debugging for email list traffic for DKIM failures considering its a
known risk in the standard.

dkim-filter has tools which make use of "z=" if present to highlight what
got changed in transit, so the admin does get some assistance from us
there.

Haven't looked at them yet. Good to know they exist. Thankyou.

Post by Murray S. Kucherawy
Of course, the question then is "OK, so now what?"

whatever it is, lets make it easy and documented for whoever needs to take
action.

Post by Murray S. Kucherawy

Post by Daniel Black
This would make sence on a small volume server where you add a signature
now and then for emailing lists that you choose to trust. A large volume
server would require the user to self manage a whitelist of signatures
for themselves which isn't impossible either.

Sorry, I'm missing what you're saying here. A whitelist of signatures?
Can you provide an example?

Yes I was thinking of a whitelist of MLM operators.

For larger volume of server the management of the whitelist could be delegated
to the users in some fashion.

Post by Murray S. Kucherawy
These are all interesting questions. I think I'll summarize them and
bring them up on the DKIM working group list for some more dialog and
suggestions.

Sounds good. Thankyou. I probably should join the list myself though i've got
a bit to catch up on.

[SM]

Post by Daniel Black
Other solutions could be providing patches to software like mailman that will
reject DKIM email without bodylength tags that it intends to mangle.

That would reject mail from Gmail.

Post by Daniel Black
Maybe modifying the documentation to highlight the risks of subject and body
prepend/appending.

See http://www.ietf.org/rfc/rfc4686.txt

"When body length limits are used, there is the potential for an
attacker to add content to the message. It has been shown that this
content, although at the end, can cover desirable content, especially
in the case of HTML messages."

Regards,
-sm

[Daniel Black]

Some reading material from the developers of mailmain and a good discussion
from Mat representing DKIM.

http://wiki.list.org/display/DEV/DKIM

http://mail.python.org/pipermail/mailman-developers/2007-February/thread.html#19377

[Murray S. Kucherawy]

Post by Daniel Black
Some reading material from the developers of mailmain and a good
discussion from Mat representing DKIM.
http://wiki.list.org/display/DEV/DKIM

There are a number of things worth mentioning about what's on this page:

- the broken dkim-filter implementation that refused to sign signed
messages was this one, but that was fixed in 2.3.0 (October of last year)

- the recommended (by the DKIM working group at IETF) practise would, I
believe, be to have either Mailman or the MTA to which Mailman hands its
work re-sign the message before sending it on its way; if only there were
an open-source tool to do such a thing... ;)

- they do say the latter in their "Proposal" section

- they talk about wishing there were some kind of DKIM validity status
header, but they don't seem to reference Authentication-Results: which has
been around for quite a while now

- I don't understand the point about a distinction between verifiers and
policy agents; in what circumstance would they not, operationally, be the
same thing?

Post by Daniel Black
http://mail.python.org/pipermail/mailman-developers/2007-February/thread.html#19377

Awful lot to read here. I'll re-post here if I have anything that needs
saying once I'm done. :-)

[SM]

Post by Murray S. Kucherawy
- I don't understand the point about a distinction between verifiers and
policy agents; in what circumstance would they not, operationally, be the
same thing?

[Murray S. Kucherawy]

On Wed, 9 Jan 2008, SM wrote:

[Murray S. Kucherawy]

I asked one of our large ISP partners what they think about the idea of
running multiple verification passes with slightly different data based on
MLM-aware heuristics. They were particularly disinterested in the idea of
verifying based on something other than exactly the content that arrived.

To cite some parts of the reply:

-- snip --
A hacker on a hosting company could add all sorts of stuff in [] and after
the end of the l= field which we would happily ignore and tell the user it
is a valid message from their bank.

Unless we are going to put in the client someway to highlight that the
text below a certain point is not necessarily true, in case their bank
statement got forwarded and had information added to it, which is also
somewhat of an insane idea :).

........

Any ISP/hosted domain that implements a sender signing policy that is
really strict despite knowing that users use listservs, etc, is just
asking for it anyways, similarly to with SPF.

This is another one of those things that works great for the people who
aren't lying, but totally fails the stops the bad guys test :)
-- snip --

The "after the l=" thing also applies to the last "n" lines of text which
you might omit in an attempt to verify successfully a message that was
modified by a footer.

Anyway, some other data points for thought.

-MSK

[Murray S. Kucherawy]

Post by Andrew Haveland-Robinson
No, not relying on gmail, just noticed it didn't verify. Perhaps signed
messages should be delimited to protect against appendices, and made clear
where the authentication begins and ends?
Like the OSI 7 layer model, can't dkim not make use of wrappers and
encapsulation to preserve integrity during transmission/forwarding?

DKIM does have ways to do that (e.g. the "l=" tag), plus the mailing list
manager or whatever is munging the message enroute could simply re-sign
the mail after making the changes it wants to make. I don't think gmail
is using either method at the moment.

Post by Andrew Haveland-Robinson
I used a couple of dkimi test addresses... my test messages did verify ok,
Authentication-Results: gaia.haveland.com; dkim=permerror (verification
My ntp source is a nuclear physics research institute, and I'm sure my time
is accurate so I think someone ought to check the machine.

That means your dkim-filter checked the timestamp in the signature against
its view of local time and found that they're out of order (i.e. the
signature had a timestamp later than what you think the current time is)
by enough of a difference to complain about it (see the "ClockDrift"
configuration option). Clearly though if your clock is correct then the
signing machine's clock is out of whack.

Post by Andrew Haveland-Robinson
I will try and get it to do a core dump and get a trace.

That would be ideal.

-MSK

[SM]

Hi Andrew,

Post by Andrew Haveland-Robinson
I wanted to use DKIM with Sendmail on Fedora 7. Easy, I thought, just do the
1. yum install dkim-filter (+dependencies)
2. create keys
3. edit a couple of template files
4. update dns txt records
5 /etc/init.d/named reload
5 /etc/init.d/dkim-filter start
6 /etc/init.d/sendmail (or MailScanner) restart
Max 30 mins work.

It's usually less than 30 minutes work if your system has the
prerequisites, i.e. sendmail 8.13.x built with MILTER support, the
milter library and OpenSSL version 0.9.8 or later. I think that Tony
has a RPM for dkim-milter. I'm not sure whether it's for x86_64.

Post by Andrew Haveland-Robinson
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!

The latest version of dkim-milter is 2.4.2. Dkim-milter can work out
of the box. It's useful to know the DKIM specifications if you want
to turn the knobs.

Post by Andrew Haveland-Robinson
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
...

/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,
dkim-filter.h:22:29: error: libmilter/mfapi.h: No such file or directory

You don't have the libmilter library installed.

[snip]

Post by Andrew Haveland-Robinson
I started the script with
/etc/init.d/dkim-filter start

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
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

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

What's the output of dkim-filter -V ?

Post by Andrew Haveland-Robinson
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
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

The problem was identified at
http://www.mail-archive.com/dkim-milter-***@lists.sourceforge.net/msg00424.html
You may be experiencing a different problem even if the syslog line
in that post is similar to yours.

Post by Andrew Haveland-Robinson
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! :-)

Dkim-filter crashed while it attempted to sign an email. The
programmers try to make your life easier by trying to figure out
what's going on from the information you provided. :-)

Post by Andrew Haveland-Robinson
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.

The "default" build options and the site.config.m4.dist sample should
be enough to get dkim-milter working. You do need to adjust the
OpenSSL settings before compiling.

Post by Andrew Haveland-Robinson
When it does work, another gripe is this padding too short error, which may

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;
How can a gmail signature fail verification? What did it fail on? What is
the "i" in "header.i" ?

Why should a gmail signature pass verification? :-) For the record,
it does if the data in the message body is not modified after DKIM signing.

Post by Andrew Haveland-Robinson
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.

The mysql mailing list appends a footer to each message and that
invalidates the DKIM signature, hence the verification failure. The
"header" refers to the message header and the "i" is the DKIM identity.

OmitHeaders specifies which message headers should not be
signed. You can leave that setting blank usually.

Regards,
-sm

[Murray S. Kucherawy]

Post by Andrew Haveland-Robinson
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!

The INSTALL and README should give you everything you need. In fact, the
COMPILING section of the former indicates which version of sendmail must
be installed and also specifically mentions that libmilter needs to be
available. The first errors you hit indicated that libmilter and its
include files were not present on your system (or at least not in the
compiler's search rules).

Post by Andrew Haveland-Robinson
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.

[Aside: In fact, if libmilter and its includes (and other dependencies
like OpenSSL) are installed and in the compiler's search rules, you can
completely skip the site.config.m4 step.]

Post by Andrew Haveland-Robinson
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’

That's bizarre. Those lines of dkim-filter.h contain C prototypes in my
copy. I've no idea why the compile would be expecting control characters
in a C header file.

Post by Andrew Haveland-Robinson
I copied /devtools/OS/Linux to /devtools/Site/site.Linux.m4

Your build would've picked up devtools/OS/Linux automatically (based on
the output of "uname") so that step was not necessary.

Post by Andrew Haveland-Robinson
./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.

We don't have the means in our build system to specify that man pages go
someplace else specifically on Fedora since "uname" doesn't say something
other than Linux. Thus, the build is only as specific as Linux and
versions thereof.

I can add a section to the README about what changes need to or should be
made for Fedora installations if that would be helpful. This is the first
I've heard that such are necessary. If someone can combine the man page
and file ownership requirements, I'd be happy to add that.

Post by Andrew Haveland-Robinson
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

Does it produce a core file when it crashes? A backtrace would be really
helpful, especially if it comes along with a copy of a message that causes
the problem.

If you didn't already, enable the first "define" in site.config.m4 which
changes confOPTIMIZE to "-g", and recompile. This will produce a version
that should be able to generate a core dump when it crashes. One caveat
though is your use of "Userid" in the configuration file; Linux processes
are forbidden from generating coredumps if they change userid during
execution, so you'll have to comment that out of the configuration file
and either (a) run it as root, or (b) start it as smmsp some other way,
until you get the problem fixed.

Post by Andrew Haveland-Robinson
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

Having crashed, dkim-filter can't very well log anything. That log entry
is from sendmail, not the filter, and all it indicates is that it was
expecting a reply from the filter when what came back is 0 bytes
(end-of-file, meaning the filter had gone away). sendmail can't really
tell you more than that.

(To translate the error: "milter_sys_read" is the function waiting for
data from the filter, "dkim-filter" is the filter on which it was waiting,
the read() function returned 0 meaning EOF when it was expecting five
bytes back.)

Since you set DKIMDEBUG's "c" flag, there may be temporary files in
/var/tmp you can examine to see how far it got in processing a message
before it died. That might helpful.

There's also a documented sendmail trace flag, "-d71.100", which will
cause sendmail to quarantine mail that was in progress at the time a
filter crashed. You might also find this useful. You just need to start
up sendmail with its usual arguments plus that flag.

Post by Andrew Haveland-Robinson
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! :-)

Progarmmers love making people's lives easier but can't do so without the
data they need. dkim-filter is stable and doesn't exhibit this behaviour
on any other system I've heard of, but there may not be that many people
using it on 64-bit Linux systems yet. I don't have a 64-bit Fedora system
here with which to try to reproduce your problems so I have to rely on the
help of others and/or you to point us in the right direction. If you can
provide more information we might be able to get you either a patch or a
workaround.

Post by Andrew Haveland-Robinson
When it does work, another gripe is this padding too short error, which

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

How can a gmail signature fail verification?

There are many possible reasons: Message modification in transit (e.g.
through an MLM that altered the message), corrupted reply to the DNS
query, signature expiration, key revocation, etc. libdkim actually
enumerates 29 of them.

Post by Andrew Haveland-Robinson
What did it fail on?

It looks, according to the logs you pasted, like OpenSSL didn't like
something in the key they're using or in the signature they generated.
Perhaps some truncation occurred, but it's hard to say without more
forensics such as the message which caused the problem.

What version of OpenSSL do you have installed?

Post by Andrew Haveland-Robinson
What is the "i" in "header.i" ?

In the specification for the Authentication-Results: header, a copy of
which is included in the source code you downloaded, this is explained.
It's the value of the "i=" portion of the DKIM signature about which the
report is being generated.

Post by Andrew Haveland-Robinson
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!

Other added (or even reordered) headers don't get in the way unless an MTA
modifies one of the headers the signer included when generating the
signature. Read about DKIM's "h=" tag to find out why if you're curious.

Post by Andrew Haveland-Robinson
Omitheaders command in dkim.conf seems to be a blanket fudge.

OmitHeaders is there to omit during signing headers that you know will
very likely get munged in transit, thus invalidating the signature you
generate. A prime example is Return-Path: which Exchange adds but
downstream MTAs tend to delete or replace.

Post by Andrew Haveland-Robinson
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.

At least one person on this list is maintaining an RPM, I believe for
Debian. There are probably others. It's also in the ports tree for at
least FreeBSD.

-MSK

[Daniel Black]

Post by Murray S. Kucherawy

Post by Andrew Haveland-Robinson
./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.

We don't have the means in our build system to specify that man pages go
someplace else specifically on Fedora since "uname" doesn't say something
other than Linux. Thus, the build is only as specific as Linux and
versions thereof.

Its really not a Fedora specific problem. Debian, Ubuntu, Gentoo, SuSe all
have the same location and permissions.
http://www.linux-foundation.org/en/LSB_Distribution_Status

Even distros that don't meet the LSB still follow the same convention. The LSB
standard references th FHS standard for system locations.

/usr/share/man is standard
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES)

"a. The bin User ID/Group ID is included for compatibility with legacy
applications. New applications should no longer use the bin User ID/Group
ID."
http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/usernames.html

I've reported this and provided a patch. Don't know what the devtools people
are doing with it.

http://sourceforge.net/tracker/index.php?func=detail&aid=1810714&group_id=139420&atid=744360

Post by Murray S. Kucherawy
I can add a section to the README about what changes need to or should be
made for Fedora installations if that would be helpful. This is the first
I've heard that such are necessary.

reminder - you commented on the patch on 2007-10-10 07:13

Post by Murray S. Kucherawy
If someone can combine the man page
and file ownership requirements, I'd be happy to add that.

I think pushing the devtools people to update their tools to modern
specifications would save the time of a lot of admins and distro maintainers.

Post by Murray S. Kucherawy
At least one person on this list is maintaining an RPM, I believe for
Debian. There are probably others. It's also in the ports tree for at
least FreeBSD.

And Alin and myself are doing it for gentoo.
http://packages.gentoo.org/package/mail-filter/dkim-milter