On Thu, 26 Jun 2008, Ricardo SIGNES wrote:

RS>Wow.  I had never noticed this bit of HORRIBLENESS before.

Um... thanks?

RS>Email::MIME, once again, is shown to be useful for a very, very small set of
RS>email.  That is, email that is not wrong; all correct email won't work 
RS>but this email is failing because it's not to-spec.

Yeah. (It was a forwarded Chinese spam, and to complicate things it was 
probably forwarded back when Pine didn't deal with weird character sets 
either. So there's a high probability even with a known encoding it could 
be corrupted.)

Failing would generally be okay, but I'd like it to fail when the 
Email::MIME object is created, not spring a surprise on me later. Which is 
probably not feasible without an unacceptable performance hit, but I can 
still want it.

RS>Probably.  I'm not sure if the encoding in a encoded-word needs to be in a
RS>registry somewhere, and whether X-UNKNOWN is.

It does, and it isn't. Though "needs to be" is flexible; you can tell 
Encode what to do with it, just Encode::Unicode doesn't apparently respect 
your choices.

RS>Headers *must* be encoded into a seven bit format.  I have no idea what
RS>"unicode" means as the first arg to encode, but I doubt that it's 7-bit safe.
RS>You'll want to use Encode::MIME::Header, which means you'll need to have a
RS>utf-8 string first.

Oh hey, I hadn't thought of that. I'm not really sure what it means 
either. Hmm. (I'm still cargo-culting this whole unicode thing.  I'm going 
to have to dig into how that actually works sooner or later, I've just 
been hoping for, y'know, later.) 

The critter needs to be unicode'd when it's stored in the database, but I 
could do that on the string *after* it's Email::MIME'd.

Reply via email to