RE: can't read SMFIC_BODY reply packet header: Success

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Tue, 29 Nov 2011 09:36:35 -0800

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of Rolf E. Sonneveld
> Sent: Tuesday, November 29, 2011 7:38 AM
> To: Murray S. Kucherawy
> Cc: opendkim-users_at_lists.opendkim.org
> Subject: Re: can't read SMFIC_BODY reply packet header: Success
>
> Output of opendkim -V:
>
> opendkim: OpenDKIM Filter v2.4.2
> Compiled with OpenSSL 1.0.0-fips 29 Mar 2010
> SMFI_VERSION 0x1000001
> libmilter version 1.0.1
> Supported signing algorithms:
> rsa-sha1
> Supported canonicalization algorithms:
> relaxed
> simple
> libopendkim 2.4.2:

Something's seriously amiss here. OpenSSL 1.0.0 definitely has SHA256 support, but the build that produced this binary apparently didn't find the right includes to say so, as "rsa-sha256" is missing from the supported signing algorithms list.

Otherwise, this is a very plain installation, so reproducing this should, in theory, be easy. However, I don't have postfix installed anywhere, so if this is somehow an artifact of the postfix-opendkim interaction, I won't spot it.

> As for the message: all I do while testing is (from the command line):
>
> $ mailx -s test myaddress_at_sonnection.nl
> a
> b
> c
> .
>
> Not sure what this means for the message as it is handed over to
> opendkim.
>
> As I use the non_smtpd_milters parameter in Postfix, the mail is then
> handled by opendkim.

Thanks, I'll build 2.4.2 and try to reproduce this symptom.

Are you able to get a debug binary compiled and installed on that machine? Getting a more reliable stack trace or even walking through the function that's failing would be ideal, in case I can't reproduce what you're seeing on my side.

The steps are easy:

- get the 2.4.2 tarball, unpack it
- "./configure --enable-debug", possibly some other options for finding libmilter and the SSL libraries
- "make"

Then run it normally, wait for the assertion failure, and load the core inside gdb as you've been doing. Or, even better, run the filter inside gdb and walk it through the failing function(s) to see what's going on. I can give you the commands to do so.

-MSK
Received on Tue Nov 29 2011 - 17:36:44 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:21 PST