(08-28-2020, 10:44 AM)Asger-P Wrote: I don't think you will find anywhere in the RFC that it says: "if you encounter a slash or a backslash you
can safely assume that everything before that is illegal path information and delete it", either. ;-)
RFC 2183 does say:
Quote: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.
Not quite the same thing, though, I suppose. Looking at the current implementation of TIdMessageDecoderMIME.RemoveInvalidCharsFromFilename(), if I were to remove/disable the logic that truncates on the last '/' or '\' character, the remaining logic would convert them to '_' instead. So, it may be worth considering for a future release. Perhaps by making the behavior configurable at runtime via a global variable or something.