Well, I've just rolled out SA to my IMail server (Windoze, gaaagh!) and my hook to pass to SA also copies the input to a flat file. I can rerun/edit/inspect anything that my nightly "kill -3days" hasn't yet hit. Nice feature for this sort of thing<g>. Maybe I'll keep it.
The input file begins: 00 Received: from at1gw-002.corp.globalpay.com [64.69.192.162] by visioncomm.net with ESMTP 01 (SMTPD32-8.13) id AC1F2720072; Thu, 21 Oct 2004 08:31:27 -0400 02 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 03 content-class: urn:content-classes:message 04 MIME-Version: 1.0 05 Content-Type: multipart/alternative; 06 boundary="----_=_NextPart_001_01C4B769.A6999CE1" 07 Subject: FW: 4 Candles - A Beautiful Message 08 Date: Thu, 21 Oct 2004 08:29:46 -0400 09 Message-ID: <[EMAIL PROTECTED] 10 ay.com> 11 X-MS-Has-Attach: 12 X-MS-TNEF-Correlator: 13 Thread-Topic: 4 Candles - A Beautiful Message 14 Thread-Index: AcS3BWlt5dySvEvTSWeuRuweMuzolAAY/hRA 15 From: <email addresses removed> 16 To: <email addresses removed> 17 and up ... Newlines with a number (nnSP) are actually in the source. Newlines without a number are artifacts of the 76-character/line limit. I see nothing that violates the "Continuation can happen anywhere - just start the next header line with whitespace" rule. The Whitespace before "ay.com>" is a tab character. There are no spaces except between the ":" and the "<". This was verified by a hex-display edit program. That must mean the problem isn't in the rule, but the implementation of the unfolding logic. SA -D says: logmsg: processing message <[EMAIL PROTECTED] orp.globalp?ay.com> for (unknown):0. The "?" is where the 0x0D0A09 was located. Does SA have a problem with CRLF where LF is expected? Kinda kinks the Gates-Challenged croud. I see the \n, \t and \r in the rule. Obviously, the ? is not in the list. However, I believe the unfolder has already flummoxed the pooch. Hacking the 0x0D0A09 to a 0x0A0920 gives: logmsg: processing message <[EMAIL PROTECTED] orp.globalp?ay.com> for (unknown):0. Hacking the 0x0D0A09 to a 0x0A2020 gives: logmsg: processing message <[EMAIL PROTECTED] orp.globalp?ay.com> for (unknown):0. Hacking the 0X0D0A09 to a 0x414243 gives: logmsg: processing message <[EMAIL PROTECTED] orp.globalpABCay.com> for (unknown):0. << Finally, a Sane report! Just not too useful. To whom do I complain<g>? Anyone wanting the original source can get it from ftp.visioncomm.net, anonymous, bin, get saparser.zip (3 KB). Can I attach things on this reflector? Would that be polite? Dan <snip> Fred sez: Here is the rule from 3.0 header __SANE_MSGID MESSAGEID =~ /^<[^<>\\ [EMAIL PROTECTED]<>\\ \t\n\r\x0b\x80-\xff]+>\s*$/m header __HAS_MSGID MESSAGEID =~ /\S/ header __MSGID_COMMENT MESSAGEID =~ /\(.*\)/m meta INVALID_MSGID __HAS_MSGID && !(__SANE_MSGID || __MSGID_COMMENT) describe INVALID_MSGID Message-Id is not valid, according to RFC 2822
