Bug 191050 - Warning should be shown when Disposition-Notifications haven't come back
Summary: Warning should be shown when Disposition-Notifications haven't come back
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: MDN (show other bugs)
Version: 4.14.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-29 17:33 UTC by Adrien Cordonnier
Modified: 2018-01-31 16:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrien Cordonnier 2009-04-29 17:33:26 UTC
Version:           1.11.2 (using 4.2.2 (KDE 4.2.2), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.28-11-generic

There is no easy way to check if a message has been sent with a disposition notification. If a problem occurs in the transmission, there is no warning nor easy way to notice that the disposition notification did not came back. Thus the user can see two types of mails:
a) messages with a disposition notification which came back
b) messages without disposition notification or whose disposition notification did not came back, possibly because of a transmission problem.

Messages sent with disposition notification should be marked as such (currently, one has to manually check for a "Disposition-Notification-To:" line in the full header). Has long as the message notification did not came back, the message should be marked with a warning sign.
Comment 1 Laurent Montel 2015-04-12 09:57:55 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 2 Adrien Cordonnier 2015-04-14 21:10:59 UTC
Tested with Kmail in KDE 4.14.1 (Kubuntu 14.10).

The bug is still present:

1) by default, it cannot be seen that a message was sent with a disposition-notification. The only way to see it is to find the line "Disposition-Notification-To: ..." in the full header view (or in the message source). This might be solved with a header style sheet displaying an icon or line of text based on "Disposition-Notification-To:" similarly to what is displayed in bugzilla generated email headers (based on X-Bugzilla-Product, X-Bugzilla-Component and X-Bugzilla-Status).

2) it is still difficult to know if a notification came back. A search may be performed to find a notification related to the message-id and the result of the search should be displayed in the header of the sent mail (i.e. a notification-read, a notification-denied, or no-notification came back).
Comment 3 Laurent Montel 2015-04-16 05:50:54 UTC
Git commit 38b5d905e11283c9aea1cb92dfaa191fad2d1bbe by Montel Laurent.
Committed on 16/04/2015 at 05:50.
Pushed by mlaurent into branch 'KDE/4.14'.

Show in header the MDN

M  +10   -0    messageviewer/header/fancyheaderstyle.cpp
M  +1    -1    messageviewer/header/headerstrategy_p.h

http://commits.kde.org/kdepim/38b5d905e11283c9aea1cb92dfaa191fad2d1bbe
Comment 4 Laurent Montel 2015-04-16 05:52:19 UTC
I added it in header (in 4.14.7)

For the come back it's hard to implement it.
I didn't find a method yet.
Comment 5 Adrien Cordonnier 2015-04-17 19:47:54 UTC
For each  recipient of a message with a MDN request, we should search for a message from this recipient whose Reply-to field matches the original Message-ID plus some magic to differentiate a MDN from a human reply to the message content. Depending of the result (no MDN, MDN received or MDN denied), some text should follow the recipient name and e-mail address.

I have tried to configure the "Find message" window so that the result would list only the matching MDN. It does not seem that easy. You cannot search the "In-Reply-To" field but only the full headers. Several messages seem to have the same message-ID. Plus it has brought my computer to its knees.

It might be interesting to add a button after each recipient. The button would trigger the appropriate search. The button would then display the current MDN status. Yet this may require to expose a C++ function to a Javascript button. I understand that this was possible with QtWebkit but not anymore with QtWebEngine.

The first step might be to get the right search result. I will investigate a bit more with the Kmail find message window.
Comment 6 Adrien Cordonnier 2015-04-18 19:44:24 UTC
An MDN is normally a direct child of the message with the MDN request. There is already the possibility to display messages by threads so the code to find direct children exists (at least children in the same folder). According to the "Customize Message Aggregation Modes" window, there are three threading policies: "perfect only", "perfect and by references", and "perfect, by references and by subject". Here the subject is likely to be changed (for example, Kmail replies with the subject "Message Disposition Notification" and add the original subject in the message body). It is also likely that the MDN and original message are in separate folders (respectively inbox and sent-mail).

Kmail displays correctly an MDN as a child of the original message if they are in the same folder (with "Aggregation/Thread starters" view which uses threading "perfect, by references and by subject").
Comment 7 Denis Kurz 2017-06-23 20:05:12 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 Denis Kurz 2018-01-31 16:50:23 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.