Ben Lentz wrote, On 29/10/06 1:26 AM:
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.
The problem with this line of reasoning, and I believe the reason why we
ended up with the practical solution of looking at the line endings of
the first lines and using what we find for the rest, is that RFC2822
applies only to the mail as it is sent between computers to an MTA. We
found that we could not count on the line endings conforming to RFC2822
at the time that it is sent to SpamAssassin.
To quote from RFC2822:
This specification is intended as a definition of what message
content format is to be passed between systems. Though some message
systems locally store messages in this format (which eliminates the
need for translation between formats) and others use formats that
differ from the one specified in this standard, local storage is
outside of the scope of this standard.
We ran into problems when we did anything other than decide on what line
ending format the message was using and then use that when we add headers.
It seems to me that milter-spamc is making the same mistake that we did,
which is to assume that it is always ok to add a header in RFC2822
format. As long as it is not acting as a filter of mail in transit to an
MTA, then it cannot rely on RFC2822. In practice, we see mail systems
that internally use RFC2822 format _except_ for using the newline
convention of the local OS, only taking care of that aspect of RFC2822
when the mail is sent out to or received from other MTAs. Absent a
standard, all we can do is figure out which newline is being used and do
the same with any headers that are added.
-- sidney
After examining a tcpdump of the SMTP transaction between my systems
(sendmail 8.13.8 - 8.13.8), I can confirm that the header delimiter is,
in fact, only 0x0a. I was being thrown off by looking at the delivered
message in an MUA, which, when saved, is in 0x0d 0x0a. So, you're
totally right.
When milter-spamc is running with this code (broken):
(void) BufAddBytes(data->headers, "\r\n", 0, 2);
The header-body canonicalization data from Mail::DKIM is:
00000400 74 79 3a 58 2d 4d 61 69 6c 65 72 3a 20 58 2d 4d
|ty:X-Mailer: X-M|
00000410 69 6d 65 4f 4c 45 3b 20 62 3d 0d 0a 74 65 73 74 |imeOLE;
b=..test|
00000420 0d 0a |..|
and I don't get DKIM_VERIFIED.
When milter-spamc is running with this code ("fixed"):
(void) BufAddBytes(data->headers, "\n", 0, 1);
The header-body canonicalization data from Mail::DKIM is:
00000400 74 79 3a 58 2d 4d 61 69 6c 65 72 3a 20 58 2d 4d
|ty:X-Mailer: X-M|
00000410 69 6d 65 4f 4c 45 3b 20 62 3d 74 65 73 74 0d 0a |imeOLE;
b=test..|
00000420
and I do get DKIM_VERIFIED. It's a little disconcerting that the
header-body separator is completely missing, but it's really not
missing; I can tell because I don't get MISSING_HB_SEP.
I guess the real way to fix this is to try and detect the header
delimiter from the first few lines in the message and apply that same
delimiter later on?
Does anyone have any tips on helping me convince Anthony that this
problem exists?
