[Mimedefang] Filenames with path

[Steffen Kaiser]

On Thu, 19 Jan 2006, Joseph Brennan wrote:

>
>> Content-Type: text/html;
>>          name*0="file:///C|/DOKUME%7E1/ANDRE/LOKALE%7E1/TEMP/nsmail-1.htm"
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline;
>> 
>> filename*0="file:///C|/DOKUME%7E1/ANDRE/LOKALE%7E1/TEMP/nsmail-1.htm"
>> 
>> In this particular sample, the path (well, the complete filename) is of
>> no use at all, but in general: There is no real reason, why the filename
>> spec should contain a path component, is it?
>
>
> That's not the only thing strange.  Why does this have '*0=' for '=',
> a pipe after 'C', and '~' (as %7E) in odd places?
>
> Was this actually legit mail?

Yes, MUA: Thunderbird 1.5 (Windows/20051201)
It is a forwarded MIME mail, however, all original parts has been 
regrouped into a flat MIME stream (I mean: the mail was not forwarded as 
application/rfc822 or what the contaoner type is usually named).
That particular part is a part from the forwarded mail, spooled into a 
temp file, then re-added.

The file:///C|/ is common notation for local file: URLs, the pipe symbol 
replaces the colon of the Windows path, e.g.:

C:\Doku... becomes file:///C|/Doku...

WBrown's guess is completely correct, the sender is using a German Windows 
XP and the profile path (aka the dot-file location of an Unix-user's 
homedirectory) is "C:\Dokument und Einstellungen\Andre\..." However, 
Thunderbird uses the short (Dosstyle 8.3) filename for the path -- well, 
they do not seem to recognize that the relationship between the long and 
short filenames is pretty weak, e.g. NT's own backup program does not 
restore the short filenames the same, but creates them anew.

So the path by itself is correct, the mail is legit, but I do not see any 
real avail for a path spec in the MIME part? Actually, I wagered to remove 
all path specs in the MIME filename spec (along with other problematic 
formats and characters).

Bye,

-- 
Steffen Kaiser