On Thursday 15 June 2006 03:43, Alan Premselaar wrote:
> Aside from the QP scatter, this subject doesn't look like it's properly
> encoded. if memory serves, if the encoded subject needs to be broken
> across multiple lines, each line needs to have its own encoding
> start/end tags.
>
> so it should look something like:
>
> Subject: =?unicode-1-1-utf-7?Q?<encoded_part>?=
> =?unicode-1-1-utf-7?Q?<more_encoded_part>?=
>
> (someone correct me if i'm wrong)
In RFC 2047 section 2, it's clear you're right and M$ are wrong:
"... unencoded white space
characters (such as SPACE and HTAB) are FORBIDDEN within an
'encoded-word'. For example, the character sequence
=?iso-8859-1?q?this is some text?=
would be parsed as four 'atom's, rather than as a single 'atom' ..."
RFC 822 (which 2047 was based on) says that a CRLF followed by space or tab
is syntactically equivalent to just a space or tab. RFC 2822 has similar
language. Hence encoded-words cannot be split across lines.
> Of course it's hard to tell because of the QuotedPrintable encoding
> artifacts, but it looks like your MS mail server is in some way
> misconfigured.
Yes sorry about the extra QP coding on the attachments, I normally use mutt
so didn't realise kmail was going to mangle them. I can resend them if
you want, but they match what I sent except for the topmost Received line.
We don't have an M$ mail server (and I for one don't want one). We're a
Unix shop, as qmail and qpsmtpd in our own headers shows :)
I'm quite prepared to believe this is a MS bug, it certainly looks like it.
But it seems to be a long term one - seen in emails from SMTPSVC versions
5.0.2195.6713 and 6.0.3790.1830. Remote MS servers, configured for
foreign languages, sending genuine non-spam bounces to non-spam mails
cause SA to FP on this rule.
Nick
