[quote user="David Harris"]
I'm happy to write in support for this type of encoding, but we're now too close to the release of v4.62 for me to be comfortable about trying to squeeze in there before release. You can expect to see support for it in the next release though.
[/quote]

 That would be great. Thanks a lot,

bb

Hello everybody,

 I've got some trouble with a few attachments. Pegasus recognizes the name as '-' and the extension as unkown. Maybe there is an encoding error in the email client of the sender, here is the raw view of such an email: 

Content-Type: application/pdf;
  name*=iso-8859-1''Gro%DFm%2Epdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
    filename*=iso-8859-1''Gro%DFm%2Epdf

This one works:

Content-Type: application/pdf;
    name="=?iso-8859-1?Q?Stra=DFe.pdf?="
Content-Description: =?iso-8859-1?Q?Stra=DFe.pdf?=
Content-Disposition: attachment;
    filename="=?iso-8859-1?Q?Stra=DFe.pdf?=";
    size=340278; creation-date="Fri, 27 May 2011 10:19:12 GMT";
    modification-date="Fri, 27 May 2011 10:19:12 GMT"
Content-Transfer-Encoding: base64
 

I don't know much about encoding standards, maybe the email client of the sender did something wrong. Anyway, it says: "Content-Type: application/pdf", why can't Pegasus set the ".pdf" extension? Since I have some people arround who can't analyze the raw email text: Is there any other way than guessing file extensions to get the correct file out of such emails?

Thanks in advance,

cheers, bb

[quote user="beezlebug"]I don't know much about encoding standards, maybe the email client of the sender did something wrong. [/quote]

The format used in your first sample obviously conforms to RFC 2231 which is still categorized as proposed standard, and AFAIK David Harris only implements fully effective standards. I'll forward this request to him nevertheless.

As Michael pointed out, this is the notation recommended by RFC2231.

My position on RFCs is that I'll generally support them once I'm sure they're stable, and that they're actually being reasonably widely-used. In this case, the RFC dates from 1997, so it fits the "stable" test, and since it appears to be the only standard-driven way of including filename information that contains international characters, that will serve for the "widely-used" test.

I'm happy to write in support for this type of encoding, but we're now too close to the release of v4.62 for me to be comfortable about trying to squeeze in there before release. You can expect to see support for it in the next release though.

Cheers!

-- David --