You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
218 lines
20 KiB
218 lines
20 KiB
<?xml version="1.0" encoding="UTF-8"?> |
|
<ui version="4.0"> |
|
<class>SecurityPageGeneralTab</class> |
|
<widget class="QWidget" name="SecurityPageGeneralTab"> |
|
<property name="geometry"> |
|
<rect> |
|
<x>0</x> |
|
<y>0</y> |
|
<width>734</width> |
|
<height>425</height> |
|
</rect> |
|
</property> |
|
<layout class="QVBoxLayout" name="verticalLayout_2"> |
|
<item> |
|
<widget class="QGroupBox" name="groupBox"> |
|
<property name="title"> |
|
<string>HTML Messages</string> |
|
</property> |
|
<layout class="QVBoxLayout" name="verticalLayout"> |
|
<item> |
|
<widget class="QLabel" name="labelWarnHTML"> |
|
<property name="text"> |
|
<string><b>WARNING:</b> Allowing HTML in email may increase the risk that your system will be compromised by present and anticipated security exploits. <a href="whatsthis1">More about HTML mails...</a> <a href="whatsthis2">More about external references...</a></string> |
|
</property> |
|
<property name="wordWrap"> |
|
<bool>true</bool> |
|
</property> |
|
<property name="textInteractionFlags"> |
|
<set>Qt::LinksAccessibleByKeyboard|Qt::LinksAccessibleByMouse</set> |
|
</property> |
|
</widget> |
|
</item> |
|
<item> |
|
<widget class="QCheckBox" name="mHtmlMailCheck"> |
|
<property name="whatsThis"> |
|
<string><qt><p>Messages sometimes come in both formats. This option controls whether you want the HTML part or the plain text part to be displayed.</p><p>Displaying the HTML part makes the message look better, but at the same time increases the risk of security holes being exploited.</p><p>Displaying the plain text part loses much of the message's formatting, but makes it almost <em>impossible</em> to exploit security holes in the HTML renderer (Konqueror).</p><p>The option below guards against one common misuse of HTML messages, but it cannot guard against security issues that were not known at the time this version of KMail was written.</p><p>It is therefore advisable to <em>not</em> prefer HTML to plain text.</p><p><b>Note:</b> You can set this option on a per-folder basis from the <i>Folder</i> menu of KMail's main window.</p></qt></string> |
|
</property> |
|
<property name="text"> |
|
<string>Prefer HTML to plain text</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item> |
|
<widget class="QCheckBox" name="mExternalReferences"> |
|
<property name="whatsThis"> |
|
<string><qt><p>Some mail advertisements are in HTML and contain references to, for example, images that the advertisers employ to find out that you have read their message (&quot;web bugs&quot;).</p><p>There is no valid reason to load images off the Internet like this, since the sender can always attach the required images directly to the message.</p><p>To guard from such a misuse of the HTML displaying feature of KMail, this option is <em>disabled</em> by default.</p><p>However, if you wish to, for example, view images in HTML messages that were not attached to it, you can enable this option, but you should be aware of the possible problem.</p></qt></string> |
|
</property> |
|
<property name="text"> |
|
<string>Allow messages to load external references from the Internet</string> |
|
</property> |
|
</widget> |
|
</item> |
|
</layout> |
|
</widget> |
|
</item> |
|
<item> |
|
<widget class="QGroupBox" name="groupBox_2"> |
|
<property name="title"> |
|
<string>Encrypted Messages</string> |
|
</property> |
|
<layout class="QVBoxLayout" name="verticalLayout_3"> |
|
<item> |
|
<widget class="QCheckBox" name="mAlwaysDecrypt"> |
|
<property name="text"> |
|
<string>Attempt decryption of encrypted messages when viewing</string> |
|
</property> |
|
</widget> |
|
</item> |
|
</layout> |
|
</widget> |
|
</item> |
|
<item> |
|
<widget class="QGroupBox" name="groupMessageDisp"> |
|
<property name="title"> |
|
<string>Message Disposition Notifications</string> |
|
</property> |
|
<layout class="QGridLayout" name="gridLayout"> |
|
<item row="1" column="0"> |
|
<widget class="QLabel" name="labelSend"> |
|
<property name="text"> |
|
<string>Send policy:</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="1" column="1"> |
|
<widget class="QRadioButton" name="radioIgnore"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Ignore</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="1" column="2"> |
|
<widget class="QRadioButton" name="radioAsk"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Ask</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="1" column="3"> |
|
<widget class="QRadioButton" name="radioDeny"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Deny</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="1" column="4"> |
|
<widget class="QRadioButton" name="radioAlways"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Always send</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="2" column="0"> |
|
<widget class="QLabel" name="labelQuote"> |
|
<property name="text"> |
|
<string>Quote original message:</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="2" column="1"> |
|
<widget class="QRadioButton" name="radioNothing"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Nothing</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="2" column="2"> |
|
<widget class="QRadioButton" name="radioFull"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Full message</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="2" column="3"> |
|
<widget class="QRadioButton" name="radioHeaders"> |
|
<property name="whatsThis"> |
|
<string><qt><h3>Message Disposition Notification Policy</h3><p>MDNs are a generalization of what is commonly called <b>read receipt</b>. 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 <b>displayed</b> (i.e. read), <b>deleted</b> and <b>dispatched</b> (e.g. forwarded).</p><p>The following options are available to control KMail's sending of MDNs:</p><ul><li><em>Ignore</em>: Ignores any request for disposition notifications. No MDN will ever be sent automatically (recommended).</li><li><em>Ask</em>: 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><em>Deny</em>: Always sends a <b>denied</b> notification. This is only <em>slightly</em> 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><em>Always send</em>: 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></string> |
|
</property> |
|
<property name="text"> |
|
<string>Only headers</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="3" column="0" colspan="5"> |
|
<widget class="QCheckBox" name="mNoMDNsWhenEncryptedCheck"> |
|
<property name="text"> |
|
<string>Do not send MDNs in response to encrypted messages</string> |
|
</property> |
|
</widget> |
|
</item> |
|
<item row="0" column="0" colspan="5"> |
|
<widget class="QLabel" name="labelWarning"> |
|
<property name="text"> |
|
<string><b>WARNING:</b> Unconditionally returning confirmations undermines your privacy. <a href="whatsthis3">More about MDNs...</a></string> |
|
</property> |
|
<property name="wordWrap"> |
|
<bool>true</bool> |
|
</property> |
|
<property name="textInteractionFlags"> |
|
<set>Qt::LinksAccessibleByKeyboard|Qt::LinksAccessibleByMouse</set> |
|
</property> |
|
</widget> |
|
</item> |
|
</layout> |
|
</widget> |
|
</item> |
|
<item> |
|
<widget class="QGroupBox" name="groupBox_4"> |
|
<property name="title"> |
|
<string>Certificate && Key Bundle Attachments</string> |
|
</property> |
|
<layout class="QVBoxLayout" name="verticalLayout_4"> |
|
<item> |
|
<widget class="QCheckBox" name="mAutomaticallyImportAttachedKeysCheck"> |
|
<property name="text"> |
|
<string>Automatically import keys and certificate</string> |
|
</property> |
|
</widget> |
|
</item> |
|
</layout> |
|
</widget> |
|
</item> |
|
<item> |
|
<spacer name="verticalSpacer"> |
|
<property name="orientation"> |
|
<enum>Qt::Vertical</enum> |
|
</property> |
|
<property name="sizeHint" stdset="0"> |
|
<size> |
|
<width>20</width> |
|
<height>26</height> |
|
</size> |
|
</property> |
|
</spacer> |
|
</item> |
|
</layout> |
|
</widget> |
|
<resources/> |
|
<connections/> |
|
</ui>
|
|
|