http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5179
------- Additional Comments From [EMAIL PROTECTED] 2006-11-12 03:42 -------
Ben Lentz wrote to the dev mailing list:
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
