If an attachment is named using the Content-Disposition header's "filename" parameter only, the attachment properties dialog doesn't display any name at all, even though this is perfectly RFC conform behaviour. Reproducible: Always Expected Results: 1. The "filename" parameter needs to be discovered and used in the properties dialog. 2. When saving the attachment or editing the message, the filename however is correctly determined. So obviously, our code has two ways of reading out the parameters of attachments, which indicates code duplication. If that's the case, it should be merged. 3. If in an incoming message, both the "filename" parameter (Content-Disposition) and a "name" parameter (Content-Type) are given, but do contradict (which is incorrect), then the "filename" parameter should take precedence. If only one or the other is given, it is fine to be tolerant and use whichever has been given. 4. In order to proliferate a standards-conform use of headers the corresponding field in the properties dialog should be renamed to "filename". For named MIME-parts, the use of the "filename" parameter within the Content-Disposition header is strongly preferred to a non-standard "name" parameter within the Content-Type header. The latter is only an optional redundancy in order to be compatible with older systems that don't adhere to the RFCs. (See: http://www.imc.org/ietf-smtp/mail-archive/msg05023.html) The choice of parameter encodings etc. might also need some doublechecking, but is not subject of this bug ticket.
Created attachment 75625 [details] test case
I confirm it. will look at soon
Git commit b7f82d208fe74043ecc11d63f718e8b5b9b7b06b by Montel Laurent. Committed on 05/12/2012 at 08:37. Pushed by mlaurent into branch 'master'. Fix Bug 311158 - Attachment properties dialog doesn't understand "filename" attribute FIXED-IN: 4.10 M +1 -1 messagecore/attachmentpropertiesdialog.cpp http://commits.kde.org/kdepim/b7f82d208fe74043ecc11d63f718e8b5b9b7b06b
Created attachment 75633 [details] another test case regarding aspect #3 Regarding aspect #3, the case of contradicting filename and name properties, here's a second test case: filename says "dangerouscode.doc", while name says "justsome.txt". Now, - Enterprise or fancy headers pretends "justsome.txt" and shouldn't - Editing the message pretends "justsome.txt" and shouldn't This is security-relevant just because the file is correctly saved to "dangerouscode.doc" Other places seem to be fine. The case of contradicting MIME headers and filename extensions might also be security relevant, but is not subject of this bug ticket. Finally, aspect #4 should be split off to a separate ticket.
Aspect #4 is now split off to the new Bug #311179. Reopening as a normal bug because of security implications.
So what we must to show ?: name or filename ?
"filename" is the RFC-standard attribute, according to the IETF (see http://www.imc.org/ietf-smtp/mail-archive/msg05023.html). The "name" attribute isn't RFC-standard (and has been only erroneously for some limited time). Mostly it is only result of a wrong but widespread implementation, so for compatibility it is still recommended to be sent as a redundancy, but shouldn't take precedence when receiving a message. (This is potentially security-relevant. Still I'm aware and sorry that these are nit-picking details compared to the "real", the major bugs that are still waiting to be fixed... :) But in the end, I can (and will) just report whatever I come across. Thanks for being so responsive!)
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.