The ParameterList class should support non us-ascii paramaters as per RFC 2231.
Also investigate whether this requires API changes ..

  xxxxx@xxxxx   2000-08-07
As far as I know, almost no other email clients support RFC 2231, thus
adding this support would not increase interoperability.  More investigation
is needed.  Since very few programs, applications, or users make use of
encoded parameter values, this is not particularly important.


  xxxxx@xxxxx   2003-03-19
First of all, encoded filenames of the form

    =?ISO-8859-15?B?5OTkLUluZm8ucGRm?=

are *not* part of the MIME spec.  A filename of
the form "=?A?B?C?=" is a perfectly valid filename,
not an incorrectly encoded filename.  JavaMail does
not encoded and decode filenames because *doing so
would violate the MIME spec*.

RFC 2231 defines a new way to include encoded paramters,
including filenames, in MIME headers.  It is *not*
compatible with the de facto way that many applications
illegally encode filenames.  Supporting RFC 2231 would
*not* allow JavaMail to interoperate with these existing
programs.  As far as I know, very few existing programs
support RFC 2231.

If you choose to violate the MIME spec, in order to
interoperate with other programs that also violate the
MIME spec, JavaMail gives you all the tools you need to
do so.

The workaround for decoding a filename is simple:

    String name = MimeUtility.decodeText(part.getFileName());

(You get to decide whether an encoded filename is "text"
or a MIME "word"; the decodeWord usage is slightly more
complicated.)

Still, there's only so much you can do with messages
that don't even come close to following the MIME
spec.  A filename that's MIME encoded will include
the special character "=", and thus *must* be quoted.

A parameter of the form

    filename==?ISO-8859-15?B?5OTkLUluZm8ucGRm?=

is illegal.  It should be

    filename="=?ISO-8859-15?B?5OTkLUluZm8ucGRm?="

This is why JavaMail can't extract the file name.

If you get a message of this form, you can try to parse
it yourself.  Use

    getHeader("Content-Disposition")

to extract the header.

Encoding filenames is a minor transgression, and a
reasonable workaround to the limitations of older versions
of the MIME spec.

Failing to properly quote a  parameter is a major flaw.
Manufacturers of software with such flaws should be told
to fix their product.

Finally, JavaMail can be used world-wide; it is not in any
way limited to the United States.

Can javamail be used only in the United States?

This is important! Attachments sent with a non-US filename 
(and non-US pc users often name their files using their native 
language) result in a screwed up getFilename()!

the simplified workaround for the receiving end is something 
like

String name = part.getFileName();
if (name != null && name.startsWith("=?"))
  name = MimeUtility.decodeWord(name);

but there's no reason JavaMail shouldn't do the decoding 
internally as it does with the other fields and content!

This workaround doesn't work, since part.getFileName() 
retruns 
null if the filename is encoded "quoted-printable". I have a 
message source code like:


Subject: =?ISO-8859-15?B?5HR0YWNobWVudA==?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------
44B46F3E4197AD"
Status: RO

------------44B46F3E4197AD
Content-Type: application/pdf; name==?ISO-8859-15?B?
5OTkLUluZm8ucGRm?=
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename==?ISO-8859-15?B?
5OTkLUluZm8ucGRm?=

JVBERi0xLjMNkz... (begin of data)


I have no problem getting the decoded subject and get 
correct returns from 
part.getContentType() and part.getSize(). But 
part.getFileName() and 
part.getInputStream() return null. The same thing happens 
with any filename 
ending with a simple '=' in the message source code. Like:

Content-Disposition: attachment; filename=test=

The only workaround is to call message.getInputStream() and 
do all the 
work manually,but this is not really a solution, since then I 
don't need 
a javamail API.

1. From what I understood in RFC 2231, there is no clash with 
existing programs, since these RFC 2231 encoded fileds have 
an asterisk as the last character of the parameter name, to 
distinguish them from the existing encodings.

2. In the spirit of the RFCs, "[be] strict when sending and 
tolerant when receiving" [RFC1958]. Today there are many 
mail clients out there that are not rfc compliant. They should 
be fixed, but until all non-compliant versions are extinct, they 
cannot simply be ignored, because that only degrades 
JavaMail robustness and reliability in real-world applications.

3. In many platforms the '?' character is illegal in a filename, 
in others it is highly discouraged and very rare. a filename of 
the form "=?A?B?C?=" would be one in a billion (just a guess). 
It is better to be tolerant for the sake of many real-world 
cases, than being strict for the sake of one in a billion.

4. Since #3 is arguable, the strictness can always be set as a 
parameter, as it is now with address parsing (a wise move in 
making JavaMail useful for serious robust applications).

Big problem with parse MimePart content begins with
Content-Type: text/plain; name==?koi8-r?B?NDEwMDQxMzMw7V81MjExNi50eHQ?=