On Tue, Oct 4, 2016 at 7:44 AM, Ralph Corderoy wrote: > Content-Type: inode/x-empty; name*=UTF-8''%41%00%42 > Content-Disposition: attachment; filename*=UTF-8''%41%00%42 > > `mhstore -auto' creates `./A'. Perhaps the RFCs rule out %00? But then > again, we're talking about crap that doesn't follow the RFCs. If it's > %41%2F%42 then `A/B' is created if A exists, so that seems OK.
It not okay. Filenames specified in email is considered informative only since there are security implications of blindly using what is provided. For any file nmh creates based on email parameter input, it should run it through a sanitizer to remove any characters deemed invalid and remove any pathname components. For example, what if I have: Content-Type: application/octet-stream Content-Disposition: attachment; filename="/etc/passwd" or relative pathname attacks using "../.."? I do not recall if nmh checks if a file with same name already exists. If we are to be security conscience, filename parameter should be ignored, with files stored based on content-type, or at a minimum, just use the filename parameter extension. An option can be provided to specify that the filename parameter be honored, but even then, only use the basename after it has been sanitized. --ewh _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers