On Mon, May 04, 2026 at 10:01:34AM +0200, Vincent Lefevre wrote: > I'm wondering whether the RFCs give a special meaning to the slashes > for the filename value (such as a directory separator, which should > be ignored),
AFAICT they don't--at least not with any specificity. However RFC 2183 does say the following: It is important that the receiving MUA not blindly use the suggested filename. The suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter. The filename should be treated as a terminal component only. Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft. I've skimmed some of the more recent RFCs that update this one, and it really seems like the authors go out of their way to avoid getting at all specific about the content of the filename field, beyond the above. There are some updates to specify non-ASCII filenames and such, but nothing that talks specifically about what characters should be considered special, or special handling thereof. I would just point out that there are uses besides dates for date-like strings, including e.g. hash directories, such that it may not be obvious when or whether to treat such things in the filename parameter as dates vs. path elements. [And FWIW, we use that style of date in the US as well, though we swap the date and month; and other countries also use it too.] It probably makes sense for Mutt to have a function that filters a list of filesystem-special characters, defined at compile time for your particular platform, that get swapped in the passed-in path to '_' or some such (that also could be platform-specific, though I'm not aware of any platform for which underscore is unavailable). In that case, though, it should also have some mechanism for resolving collisions, at least for attachments saved from the same message... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
