Bug 311158 - Make "filename" attribute take precedence to "name" attribute
Summary: Make "filename" attribute take precedence to "name" attribute
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Unclassified
Component: general (show other bugs)
Version: 4.10 pre
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-04 19:30 UTC by Bernd Oliver Sünderhauf
Modified: 2017-01-07 22:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.10


Attachments
test case (2.02 KB, application/mbox)
2012-12-04 19:32 UTC, Bernd Oliver Sünderhauf
Details
another test case regarding aspect #3 (2.04 KB, application/mbox)
2012-12-05 09:16 UTC, Bernd Oliver Sünderhauf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Oliver Sünderhauf 2012-12-04 19:30:55 UTC
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.
Comment 1 Bernd Oliver Sünderhauf 2012-12-04 19:32:49 UTC
Created attachment 75625 [details]
test case
Comment 2 Laurent Montel 2012-12-05 07:14:16 UTC
I confirm it.
will look at soon
Comment 3 Laurent Montel 2012-12-05 07:38:04 UTC
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
Comment 4 Bernd Oliver Sünderhauf 2012-12-05 09:16:39 UTC
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.
Comment 5 Bernd Oliver Sünderhauf 2012-12-05 09:23:08 UTC
Aspect #4 is now split off to the new Bug #311179.
Reopening as a normal bug because of security implications.
Comment 6 Laurent Montel 2012-12-05 09:32:25 UTC
So what we must to show ?:
name or filename ?
Comment 7 Bernd Oliver Sünderhauf 2012-12-05 10:10:41 UTC
"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!)
Comment 8 Denis Kurz 2016-09-24 18:00:51 UTC
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.
Comment 9 Denis Kurz 2017-01-07 22:41:17 UTC
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.