Greetings,
I am currently using spamassassin 3.1.7 with SnertSoft's milter-spamc
1.10.376 and sendmail 8.13.8. I am having problems getting DKIM_VERIFIED
to work, and after some trial and error, I compared the canonicalized
files from a signer and verifier system, and found that the data being
passed to SpamAssassin (and in turn to Plugin/DKIM.pm and Mail::DKIM)
contained what appeared to be an extra CRLF between the headers and body.
This is almost a "normal" problem with DKIM, as it's sensitive (by
design) to signs of tampering like this.
Applying a patch against the source for milter-spamc, removing what I
believe is the line of code that's injecting this CRLF when the data is
passed from libmitler to spamassassin:
--- milter-spamc.c.orig 2006-10-17 17:07:09.000000000 -0400
+++ milter-spamc.c 2006-10-17 17:26:22.000000000 -0400
@@ -649,7 +649,7 @@
if (data->work.skipMessage)
return SMFIS_CONTINUE;
- (void) BufAddBytes(data->headers, "\r\n", 0, 2);
+ /* (void) BufAddBytes(data->headers, "\r\n", 0, 2); */
/* Insert a simulated Received: header for this server into the
* header block being sent to spamd. It appears that this header
Results in SpamAssassin doing this:
X-Spam-Report: Content preview: test [...]
____
Content analysis details: (-0.1 points, 4.0 required)
____
pts rule name description
---- ----------------------
--------------------------------------------------
...snip...
2.5 MISSING_HB_SEP Missing blank line between message header and body
0.0 DKIM_POLICY_SIGNALL Domain Keys Identified Mail: policy says domain
signs all mails
-0.0 DKIM_VERIFIED Domain Keys Identified Mail: signature passes
verification
0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature
0.0 DKIM_POLICY_TESTING Domain Keys Identified Mail: policy says domain
is testing DK
Which is a little unexpected... MISSING_HB_SEP & DKIM_VERIFIED at the
same time.
However, I've also discovered that if I keep this line, but change the
CRLF to a LF:
--- com/snert/src/milter-spamc/milter-spamc.c.orig 2006-10-18
15:03:37.000000000 -0400
+++ com/snert/src/milter-spamc/milter-spamc.c 2006-10-18
15:03:49.000000000 -0400
@@ -649,7 +649,7 @@
if (data->work.skipMessage)
return SMFIS_CONTINUE;
- (void) BufAddBytes(data->headers, "\r\n", 0, 2);
+ (void) BufAddBytes(data->headers, "\n", 0, 1);
/* Insert a simulated Received: header for this server into the
* header block being sent to spamd. It appears that this header
Everything appears to work, MISSING_HB_SEP goes away, and DKIM_VERIFIED
works for signed mail.
However, after providing all this information to Anthony Howe, developer
of milter-spamc he's responded with:
I'm going to reject this patch on the grounds that I claim the DKIM
test in SpamAssassin is wrong. RFC 2822 line endings for ALL headers,
body lines, and the blank line separating the two are CRLF, not LF.
Since the first call to filterBody() when processing a message does
NOT contain the CRLF that separates the headers from the body, that
CRLF is correctly added to the buffer when filterEndHeaders() is
called. Its SpamAssassin that would appear not to be correctly
handling message newlines breaking on LF instead of CRLF.
The part of his theory that doesn't sit right with me is that if I
re-scan the email that's handed back to sendmail after milter-spamc
verifies it, DKIM_VERIFIED works fine. It appears that whatever
milter-spamc is handing to SpamAssassin won't DKIM_VERIFy, but that the
final output of milter-spamc will DKIM_VERIFy. To me, this is an
indication of munge when handing off to SpamAssassin, and a removal of
that munge when handed back to sendmail. I know I've just repeated the
same point three times, but I'm trying to articulate it correctly.
I'd like to help debug and/or troubleshoot this issue, even though I
feel my patch to milter-spamc resolves the issue for my systems.
Any thoughts would be greatly appreciated. If you feel it'd be more
appropriate to post to the users list, I'll do that instead, but I
thought that this issue might be more dev-y.
Thanks in advance.
