Bug 136804 - Wrong "Help" for MDN (Message Disposition Notifications)
Summary: Wrong "Help" for MDN (Message Disposition Notifications)
Status: RESOLVED WORKSFORME
Alias: None
Product: kmail2
Classification: Applications
Component: MDN (show other bugs)
Version: 5.2.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-04 07:06 UTC by Rugart Fertsch
Modified: 2022-12-31 05:23 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
image with old Help text (55.16 KB, image/png)
2015-04-22 19:41 UTC, Rugart Fertsch
Details
image with "new" (present) Help text (34.71 KB, image/png)
2015-04-22 19:46 UTC, Rugart Fertsch
Details
kmail's MDN question - appears even if the configured Policy isn't 'Ask' (10.60 KB, image/jpeg)
2015-04-22 19:51 UTC, Rugart Fertsch
Details
attachment-24591-0.html (1.36 KB, text/html)
2017-07-31 19:07 UTC, Rugart Fertsch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rugart Fertsch 2006-11-04 07:06:39 UTC
Version:           1.9.5 (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-1 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.8.1-kanotix-10

When clicking at "Configure Kmail"/"Security"/"Reading" and then
"More" in the "Message Disposition Notifications" section, the yellow
help window that appears has wrong information. The last part states that 
"The following options are available to control KMail's sending
of MDN:
 ...
 .Always send: ... the author of the message gets to know ... what happened to it (displayed, deleted, etc.). ... "
 That's wrong! KMail's MDN doesn't tell the author of the e-mail message whether the message was deleted by the receiver. If the receiver chooses to delete the message immediately (before it is marked as read), the MDN won't be sent. And if the receiver chooses to delete the message one second later, when it is already marked as 'read', then the MDN is already in the 'Outbox', beeing sent. And this MDN states that  "The message sent on ... has been displayed. This is no guarantee that the message has been read or understood." 
 So, KMail's MDN only informs that the message has been displayed. Or 'acted upon', if the user has choosen the "Deny" Send Policy. And it 
doesn't inform at what time it was displayed.
 So, the right last part of the 'Help' text would be:
".Always send: Always sends the requested disposition notification. That means that the author of the message gets to know that it was displayed. This option is strongly ..." 
 So, in all appearances of the word "Disposition", it could be safely
substituted with "Exhibition" which is much more clarifying. Or all appearances of "Message Disposition Notifications" in KMail could just 
be substituted with "Read Receipts" which is much easier to understand.
Comment 1 Björn Ruberg 2009-12-30 23:37:39 UTC
Is this still an issue in KDE 4.3?
Comment 2 Rugart Fertsch 2009-12-31 05:01:55 UTC
 Hi, Björn Ruberg
 Due to hardware limitations, I don't use KDE 4.3 : still using the latest 
stable version, lenny, 3.5.10 . And kmail 1.9.9 (3.5.5.dfsg.1-6 in Debian ). 
Where the reported situation is unchanged. "Help" text has wrong information.
  Thanks for your attention.
Comment 3 Laurent Montel 2015-04-12 10:06:46 UTC
Thank you for taking the time to file a bug report.

KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2.

We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.
Comment 4 Rugart Fertsch 2015-04-22 19:41:32 UTC
Created attachment 92167 [details]
image with old Help text
Comment 5 Rugart Fertsch 2015-04-22 19:46:58 UTC
Created attachment 92168 [details]
image with "new" (present) Help text

Situation is unchanged. The 'Help' text about MDNs is now, with the latest 
available kmail (4.13.3-0ubuntu0.1), still the same wrong one as with kmail 
1.9.5. Only the background color changed, from yellow to black, as one can see 
at the 2 attached screenshots. 
 If the author of an e-mail message requests a disposition notification, and 
the receiver uses kmail and the message is deleted (deleted by the user 
himself without opening it, or deleted by a configured filter), no MDN is sent.
That's why the 'Help' text is wrong - the message sender does NOT get to know 
if the message was deleted. 
 And not sending a MDN upon message deletion doesn't conform to 
https://tools.ietf.org/html/rfc3798  and
https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-02 .
 A MDN should be sent even if the message is deleted.
 And there is more about how kmail deals with receiving messages containing 
MDN requests:
 When configuring kmail / Security / Message Disposition Notifications , Policy 
"Deny" is not respected. Policy "Always send" isn't either. In both cases, the 
user is asked whether he/she wants to send a 'denied' or normal response - 
there shouldn't be such a question, since the general policy was already 
configured to "Always send" or to "Deny" . This question should only appear if 
the configured policy is "Ask". 
 A screenshot, kmail4.13.3_MDN_question.png, is attached (at the next comment).
 Now, about what happens when answering the question: there are actually 3 
answers:
"Ignore"  sends nothing (which is the expected behavior).
"Send 'denied' " and "Send" : both send exactly the same text: 
 "The message sent on (date time) to (address)  with subject (...) has been 
displayed. This is no guarantee that the message has been read or understood."
 This is coherent with the "Send" answer, but if the user answered "Send 
'denied' ", the text should be quite different .
 Thanks,
   Rugart Fertsch
Comment 6 Rugart Fertsch 2015-04-22 19:51:35 UTC
Created attachment 92169 [details]
kmail's MDN question - appears even if the configured Policy isn't  'Ask'
Comment 7 Denis Kurz 2017-06-23 19:58:42 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 8 Rugart Fertsch 2017-07-31 19:07:12 UTC
Created attachment 106993 [details]
attachment-24591-0.html

 The situation is unchanged in KMail 5.2.3 / KDE Plasma 5.9.4 . The HELP
text is the same as in previous versions of KMail (1.9.5 and 4.13.3).
 Who sends an e-mail with a MDN (read receipt) request does not get to know
whether the e-mail was deleted by the other part.
 The 'Ask', 'Deny' and 'Always Send' options for the MDN "Send Policy"
produce the same effect : when the e-mail receiver opens the e-mail
message, a widget asks what he wants do do about the MDN. However, 3
different options should have 3 different results.
 And this widget has 3 answers: "Ignore", "Send" or "Send 'denied' ".
Clicking "Ignore" produces the expected behavior, sends nothing. But "Send"
and "Send 'denied' " send the same answer ( "Send 'denied' " does not
mention 'denied').
 Regards,
  Rugart Fertsch
Comment 9 Christoph Feck 2017-08-01 22:38:00 UTC
Thanks for the update; changing status.
Comment 10 Justin Zobel 2022-11-06 09:24:52 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 11 Bug Janitor Service 2022-11-21 05:11:54 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 12 Rugart Fertsch 2022-12-01 15:59:09 UTC
Hi,
 Sorry, but I'm not using KMail anymore for a long time; and my KDE version is not the latest.
 Regards,
  Rugart Fertsch
Comment 13 Bug Janitor Service 2022-12-16 05:13:05 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 14 Bug Janitor Service 2022-12-31 05:23:19 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!