SecurityPageMDNTab 0 0 672 419 QFormLayout::ExpandingFieldsGrow Send policy: radioIgnore <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Ignore <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Ask <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Deny <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Always send Qt::Vertical QSizePolicy::Fixed 20 24 Quote original message: radioNothing <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Nothing <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Full message <qt><h3>Message Disposition Notification Policy</h3>MDNs are a generalization of what is commonly called read receipt. The message author requests a disposition notification to be sent and the receiver's mail program generates a reply from which the author can learn what happened to his message. Common disposition types include displayed (i.e. read), deleted and dispatched (e.g. forwarded).The following options are available to control KMail's sending of MDNs:<ul><li>Ignore: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li>Ask: Answers requests only after asking the user for permission. This way, you can send MDNs for selected messages while denying or ignoring them for others.</li><li>Deny: Always sends a denied notification. This is only slightly better than always sending MDNs. The author will still know that the messages has been acted upon, he just cannot tell whether it was deleted or read etc.</li><li>Always send: Always sends the requested disposition notification. That means that the author of the message gets to know when the message was acted upon and, in addition, what happened to it (displayed, deleted, etc.). This option is strongly discouraged, but since it makes much sense e.g. for customer relationship management, it has been made available.</li></ul></qt> Only headers Qt::Vertical QSizePolicy::Fixed 20 24 Do not send MDNs in response to encrypted messages Qt::NoContextMenu WARNING: Unconditionally returning confirmations undermines your privacy. <a href="whatsthis-mdn">More about MDNs...</a> true Qt::LinksAccessibleByKeyboard|Qt::LinksAccessibleByMouse radioIgnore radioAsk radioDeny radioAlways radioNothing radioFull radioHeaders mNoMDNsWhenEncryptedCheck