Open 537mfb opened 11 years ago
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 andy.edinborough@gmail.com?
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
Mail exemple sent - let me know if you need something
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?
The case specifically looks like:
Content-Type: application/msword; name0=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20de%20; name1=or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc Content-Disposition: attachment; filename0=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20d; filename1=e%20or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc Content-Transfer-Encoding: base64
name0 and name1 get appended to rawvalue of contente-type and filename0 and filename1 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\tname0=ISO-8859-1''0305%20-%20MULTILINGUES%20-%20Solicita%E7%E3o%20de%20;\r\n\tname1=or%E7amento%20%28Alem%E3o%20Portugu%EAs%29.doc\r\n";