Bug 128453 - protect privacy by sending receipts (MDN) after a random delay
Summary: protect privacy by sending receipts (MDN) after a random delay
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: MDN (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-01 18:37 UTC by Hauke Laging
Modified: 2012-08-19 03:02 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 Hauke Laging 2006-06-01 18:37:55 UTC
Version:            (using KDE KDE 3.5.1)
Installed from:    SuSE RPMs

I do not regard MDN messages as a problem in general. The sender should know that his message has arrived (and if I don't want him to I can still refuse in the dialog). But I don't think it's necessary that the sender knows the exact time of reading. I don't like questions why I read e-mail at 04:00... (bad enough if I send it then...)

This I would like to suggest to add some random delay to the MDN message. "You message ........ has been read within the last 12 hours (privacy protection, see http://www.kde.org/.....)".

This could be achieved in two ways:

1) Kmail itself waits for the determined delay to run out. If KMail is closed it can generate another random value (if the maximum delay has not exceeded yet - then it should be sent at once, and maybe the message text should be adapted to this fact).

2) KMail adds a "X-Send-at" header. I don't understand anyway why e-mail does not have such a feature. I find that important (web based SMS services offer that). If KMail implements that (locally only, of course) and other Clients take that over then there would be a chance that MTAs accept this feature after a while, too, which in turn would prevent my mum from asking me why I send e-mail to her at 04:00 (without me faking the date header myself), what an improvement.
Comment 1 Myriam Schweingruber 2012-08-18 08:59:39 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 2 Luigi Toscano 2012-08-19 00:34:07 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
Comment 3 Hauke Laging 2012-08-19 02:20:15 UTC
(In reply to comment #2)
> Instead of creating a new feature request, please confirm here if the
> wishlist is still valid for kmail2.

Still valid.