Bug 311158

Summary:	Make "filename" attribute take precedence to "name" attribute
Product:	[Applications] kmail2	Reporter:	Bernd Oliver Sünderhauf <pancho.s>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	montel
Priority:	NOR
Version:	4.10 pre
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:	http://commits.kde.org/kdepim/b7f82d208fe74043ecc11d63f718e8b5b9b7b06b	Version Fixed In:	4.10
Sentry Crash Report:
Attachments:	test case another test case regarding aspect #3

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.