Hi,

I noticed that several MUAs (including Microsoft Outlook Express) fail
to decode MIME-encoded subjects which are composed with Gnus.  In
order to check the detail of this problem, I send three mails that
have MIME-encoded subjects to my friend who uses Microsoft Outlook
Express, and ask him to check whether these subjects are successfully
decoded or not.  The result is here:

        MIME-encoded subject field      |   Result
  --------------------------------------+-------------
    =?iso-2022-jp?b?GyRCNEE7ehsoQg==?=  |  undecoded
    =?iso-2022-jp?B?GyRCNEE7ehsoQg==?=  |   decoded
    =?ISO-2022-JP?B?GyRCNEE7ehsoQg==?=  |   decoded

This result shows that this broken decoder decodes MIME-encoded words
whose encodings are specified in the uppercase letter "B", and shows
that it does not decode a word whose encoding is specified in the
lowercase letter "b".

I think that a careless programmer implemented this decoder reading
the fourth section of RFC2047,

   4. Encodings
      Initially, the legal values for "encoding" are "Q" and "B".

and he/she failed to notice the second section.

   2. Syntax of encoded-words

        encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
        charset = token    ; see section 3
        encoding = token   ; see section 4

      Both 'encoding' and 'charset' names are case-independent.  Thus
      the charset name "ISO-8859-1" is equivalent to "iso-8859-1", and
      the encoding named "Q" may be spelled either "Q" or "q".

It is true that my reporting problem is not caused by Gnus, but I
think that the attached change may be useful for Gnus users who are
forced to communicate with users of such broken MUAs, and that it is
not harmful to Gnus at least.

Can I commit this change?

--
TSUCHIYA Masatoshi