aenetmail
aenetmail copied to clipboard
andyedinborough
Attachment filenames not being fetch in some cases
The case specifically looks like:
Content-Type: application/msword; name_0_=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20de%20; name_1_=or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc Content-Disposition: attachment; filename_0_=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20d; filename_1_=e%20or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc Content-Transfer-Encoding: base64
name_0_ and name_1_ get appended to rawvalue of contente-type and filename_0_ and filename_1_ get appended to rawvalue of contente-disposition - both without decoding the name and beeing kept separate
attachement.Headers["Content-Type"].rawvalue == "application/msword;\r\n\tname_0_=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20de%20;\r\n\tname_1_=or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc\r\n";
Is there a newline before name*0* and filename*0* in the actual header? Do you have an example of a full email you could forward to me at [email protected]?
Oh nevermind. I'm sorry, your code shows there should be a newline and tab preceeding both. Let me look into this more.
will send you an example in the morning - and yes there are newlines AND tabs there as per my final equality shows - Also the filenames are encoded - looks like some form of URL encoding but with the ISO-8859-1 charset specified
Just noticed that some mail cliente apps (tested with Windows Live Mail) will not retrieve the filenames properly and just replace that with one in the form ATTxxxxx.ext with xxxxx being digits with no particular order i can see.
It does get the extension file correct though somehow
This leads me to the question - could there be something off with that file name scheme? not follow standard or something like that? or was the mail client devs just lazy and not implement it?
