NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Origin of those bytes (Score:1)
Rewriting in hex notation makes those bytes a little more familiar:
If that’s still not familiar, Encode might help:
And what’s U+FEFF?
It’s a zero-width non-breaking space, also known as a “byte-order mark”. At the start of a document, a zero-width non-breaking space has no visual effect, so it was originally intended to allow programmatic distinction of little-endian and big-endian 16-bit encodings of Unicode. (There’s guaranteed to be no Unicode character with the codepoint U+FFFE, so it’s safe to use it in that way.) Eventually the same technique got applied to UTF-8, despite the fact that it doesn’t typically provide any benefits under UTF-8, and is often actively harmful.
So it seems that Hotmail’s server sometimes generates bounces that both are inappropriately in a non-US-ASCII encoding, and also inappropriately begin with a byte-order mark. This is what would be technically described as a bug.
The Wikipedia article on byte-order marks [wikipedia.org] may be helpful.
Reply to This
Re: (Score:1)
Pah, you beat me to the punch. :-)
Re: (Score:2)
despite the fact that it doesn’t typically provide any benefits under UTF-8
Well, it's a marker that the following text is in UTF8. So it may be somewhat useful, though of limited use.
Of course, it is completely out of place in mail headers.
But I'm still wondering about the extra newline in front of the mangled
From/code> header. Did Hotmail put it there, or did an intermediate SMTP server see the mangled header, and separated it from the rest of the other, properly formed, headers above it?