[dev] MIME Encoding and RFC 2231

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

>> A viable idea would be to implement encoding the way that it appears 
>> mutt gets
>> around this problem - by sending both the invalid, RFC 2047 encoded 
>> header and
>> the RFC 2231 header.
>
> Hm, maybe I've misread it, but didn't someone say in this thread that mutt
> is *always* sending RFC 2231 headers? Or is this what you are talking
> about? How can you send headers in both formats?

My reading of this mutt option is that it will send a MIME 2047 encoded
parameter *in addition* to the 2231 encoded parameter.  i.e. something like
this:

Content-Type: text/plain;
  name="?UTF-8?q?RFC2047 encoded header?=";
  name*=UTF-8'en-us'RFC2231 encoded header

I *think* this might work because, for implementations that don't support RFC
2231, you get the following parsed parameter values:

'name' => RFC2047 encoded header
'name*' => UTF-8'en-us'RFC2231 encoded header

Obviously, a non-compliant mail client will ignore the 'name*' parameter since
it will never look for it.  Rather, it will incorrectly decode the 'name'
parameter and use that instead.

And, most likely, a RFC 2231 compliant mailreader will either skip the first
incorrectly encoded parameter and use the correctly encoded second one, or it
will go ahead and decode the first but this value will get overwritten when it
decodes the second parameter.

>> And I think the "holier than thou attitude" shown by the developer in that
>> thread is pretty repulsive.  I understand the need to follow standards, but
>> turning your back on the way the rest of the world operates doesn't 
>> seem to be
>> a valid response.  You think Outlook sucks?  That's your opinion, but that
>> doesn't mean you can just ignore it.
>
> Exactly. I think we should in any case support decoding this format for
> cases where the server doesn't do it on the fly.

This is my next step - obviously, we want to be able to at least decode 2231
encoded data.  This should be committed hopefully in a little bit.

> And if we have to use
> *one* of these formats, it would be cool if we could let the user decide.
> Making it a preference that can be turned on if most correspondents use
> broken mail clients.

Possibly.  Although this parameter might be very confusing for a lay user
(although an admin could simply lock this value then).  Maybe there 
could be an
option for "Send both encodings" also, if my above solution proves viable.

> It could be done even fancier with formatting depending on the recipients,
> storing their preferred format in Turba and automatically detecting and
> storing their user clients in Turba when reading mail. Well, that might be
> a bit overhead. :-)

Wow.  Have at this one - I think I'll pass for now :)

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder