For the 8bit header part, this received: line has an interesting DNS lookup answer for a PTR lookup of 10.91.4.225... can't say as I can blame that 8bit header on outlook.. looks like a DNS configuration issue to me... I'm pretty sure DNS responses aren't allowed to be in 8-bit form, and that's definitely 8bit (6 chars in it with their high bit set).
Received: from mofe (°½ΒΈπ [10.91.4.225]) by gwa-msg-01.gcc.or.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
As for the subject line, it looks, at causal inspection, like that's been all been properly escaped and is RFC legal. I see absolutely no character with hi-bits set in that string.. Now it may contain 8-bit chars *after* it's been decoded.. but that is really only a good detection mechanism for people correctly using escape mechanisms to encode non-European character sets.
Subject: =?ks_c_5601-1987?B?UmU6ILCtvcK48CCw+sDltNQs?=
It does still however set off the SUBJ_FULL_OF_8BITS.. which, as best I can tell, it should not. That's a properly escaped and encoded subject line in an IANA registered Korean character set.
Is there something I'm missing.. is there a *good* reason to run the 8bit subject test after character set translation occurs? Is the intention for this rule to detect non European charsets, or to detect invalid headers?
At 05:53 PM 1/24/2003 -0500, [EMAIL PROTECTED] wrote:
Thanks a lot. That is what I need to know. However, FYI, the mail was generated by Korean version of MS outlook... Following is the full header.
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
