[Email-SIG] Patch: Improve recognition of attachment file name, with encodings

[Nando]

Looks like I forgot to attach the patch. Sorry. Here it is.

Nando Florestan
===============
[skype]    nandoflorestan
[phone]  + 55 (11) 3675-3038
[mobile] + 55 (11) 9820-5451
[internet] http://oui.com.br/
[À Capela] http://acapela.com.br/
[location] São Paulo - SP - Brasil



Nando wrote:
> Decoding of RFC 2047 encoded filenames... I attach an updated patch. Now 
> it is off by default, but can be enabled by flipping a flag. I have 
> updated the docstring for the get_filename() method. Let me know if I am 
> forgetting something.
>
> Two questions:
>
> 1) I have done this for the get_filename() method only. The flag that 
> needs to be set is called *garbage_filename_decoding*. Look, it says 
> "filename" in there. But are there any other parameters where the 
> improper usage of RFC 2047 also commonly occurs? If so, maybe a single 
> flag for all of them would be more appropriate...
>
> 2) Is there some flaw in decode_header()? Something that Thunderbird 
> displays as "Eduardo & Mônica" is being decoded with the wrong character 
> in place of the ô:
> repr(decode_header(m["subject"])[0][0])
> 'Eduardo & M\xf4nica'
> The header being tested is:
> Subject: =?iso-8859-1?Q?Eduardo_&_M=F4nica?=
> In case we are again doing the Right Thing, then why does Thunderbird 
> display it the way it was intended?
>
> I am not familiar with the RFCs. When I read Stephen Turnbull's message 
> explaining that these are in fact malformed messages, I was very 
> worried. (I want the email library to just work...) Fortunately we can 
> do the right thing by default, while still supporting decoding of the 
> malformed messages.
>
> I hope you can approve this small patch...
>   
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
Url: http://mail.python.org/pipermail/email-sig/attachments/20080216/bee0203b/attachment.txt