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
You can't even think about them!"
--Larry Wall in Configure from the perl distribution
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Good and bad (Score:2)
However, converting it to ISO-8859-1 is bad bad bad. It has no right to do that IMHO
Re:Good and bad (Score:2)
Is there any hope for the mail infrastructure to be fixed one of these days? I don't remember hitting a 7bit MTA since 97 or something. Will we also have to QP encode addresses when IRIs start appearing all over?
-- Robin Berjon [berjon.com]
Re:Good and bad (Score:2)
You imply it's broken. By the same theory IPv4 is also broken. But I don't see much of a rush to switch to IPv6, and I very much doubt we'd see a big rush to a new mail infrastructure. The pain would be worse than the gain.
Will we also have to QP encode addresses when IRIs start appearing all over?
I suspect we'll see more and more base64 and QP encoded emails over time, yes.
There are many email clients that send out broken crap, and sadly MTA's often just accept their garbage. This leads to the current situation.
It's very much analogous to the HTML/XML situation. Would you have XML parsers try their best to accept any old crap just because you want to produce it?
Reply to This
Parent
Re:Good and bad (Score:2)
I knew you'd say that :-p. I'm implying that what is broken is that it's supposed to be a text-based protocol and yet it's impossible to use text in it without encoding it to US-ASCII through QP/B64. I can see the point in having UTF8 mail set to be the standard mail content (perhaps alongside UTF16, just as it is for XML) so that all languages can be supported without special encodings and we only resort to ugly hacks for binary content.
My email is sent out in UTF8 with clear and clean headers say
-- Robin Berjon [berjon.com]