On this tab you can configure security-relevant options for reading messages.
- Prefer HTML to plain text
If checked, KMail will show HTML messages with their HTML formatting and layout. We strongly recommend to leave this option off, as security problems with HTML might show up. When this option is off, you can still read HTML messages, but only as plain text.
- Allow messages to load external references from the Internet
- Message Disposition Notifications
MDNs are a generalization of what is commonly called a “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 (listed as Send policy) are available to control when KMail sends MDNs:
- Ignore (recommended)
Ignores any request for disposition notifications. No MDN will ever be sent automatically.
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.
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.
- 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 sense where privacy is not a concern, e.g. in customer relationship management, it has been made available.
If you are unsure, experiment a while with Ask and if you find KMails questions annoying, switch to Ignore.
The following options (listed as Quote original message) are available to control how much of the original message KMail sends back in MDNs.
No parts of the message other than the mandatory message-id and the original recipient is included in the MDN reply. This preserves enough information for the sender to find the message in his sent messages for which this MDN was generated.
- Full message
Attaches the complete message to the disposition notification. Usually, this is overkill. It does not add any valuable information that cannot be deduced from the message headers alone, but people sometimes insist on this, since it is much easier for humans to correlate the content of the message than just the headers to what they sent earlier.
- Only headers
Attaches only the headers to the disposition notification. This is usually enough to enable both humans (by subject) and computers (by message-id) to easily correlate MDN and original message.
If unsure, leave the option at the default.
- Do not send MDNs in response to encrypted messages
This option suppresses the sending of MDNs if the message is encrypted (partially or in whole). This thwarts attempts to use KMail's MDN feature as an oracle to deduce whether you were able to decrypt the message or not.
Strictly speaking, this option is not needed, since KMail sends MDNs regardless of whether the message could be successfully decrypted or not (the disposition notification request resides in the unencrypted part of the message), but it gives the security-conscious user the choice to either send them always if requested (option unchecked), or never (option checked).
If unsure, leave the option checked.
- Automatically import keys and certificates
If checked, KMail automatically imports any attachments containing OpenPGP keys into your local keyring, and any attachments containing S/MIME keys into your local key box.
Verifying S/MIME signatures always involves importing the contained certificates. This option thus does not affect this. It is also unrelated to GPG's
auto-key-retrievefeature, where GPG will try to import unknown keys from a key server.
On this tab you can configure security-relevant options for composing messages.
- Automatically sign messages
If checked, the → option in the composer will default to on.
However, you can still switch it on and off on a per-message basis.
- When encrypting emails, always also encrypt to the certificate of my own identity
If checked, any message that is encrypted to the recipients will additionally be encrypted to yourself.
If you uncheck this option, you may not be able to decrypt the messages written by yourself and encrypted to other people anymore.
- Store sent messages encrypted
If checked, messages are stored in your sent-mail folder just as you sent them (i.e. if they were encrypted, they are also stored that way).
If unchecked, messages will always be stored unencrypted in your sent-mail folder, even if they are sent encrypted.
- Always show the encryption keys for approval
If checked, every time you encrypt a message, a dialog will appear that presents you with the encryption keys that will be used for each recipient. You can then review the choice of keys, change them, and approve or cancel the encryption operation. We recommend to keep this option checked, since it makes the encryption process more transparent.
- Automatically encrypt messages whenever possible
Also called “opportunistic encryption”. If checked, KMail will try to match recipients to (OpenPGP or S/MIME) keys even when you did not specifically request encryption. If usable keys are found for all recipients, KMail will ask whether or not you want to encrypt the message.
It is highly recommended to turn this on, as it makes encrypting messages really easy to use.
- Never sign/encrypt when saving as draft
If checked, KMail will not attempt to sign and/or encrypt messages that are merely saved to the drafts folder. This is more convenient, and does not result in a gross loss of security, provided the drafts folder is safe. IMAP users might want this option turned off, if their drafts folder is on the server.
On this tab you can switch security-relevant warnings on and off.
- Warn when trying to send unsigned messages
If checked, KMail will show a warning if for whatever reason a message would be sent without being digitally signed.
- Warn when trying to send unencrypted messages
If checked, KMail will show a warning if for whatever reason a message would be sent without being encrypted.
While it is common to sign all outgoing messages, encrypting them is not. So unless your company has a policy of never sending any unencrypted messages, it might be a good idea to keep this option switched off and rely on opportunistic encryption to alert you if you could send encrypted messages, but did not request it.
- Warn if receiver's email address is not in certificate
If checked, KMail will emit a warning if an S/MIME certificate or OpenPGP key will be used for a recipient whose email address is not listed in the email addresses stored in the certificate.
Situations in which this warning will trigger include when configuring your per-identity OpenPGP keys or S/MIME certificates, when encrypting, and when verifying signatures, if the signature was made with a certificate that does not include the email address of the sender.
- Warn if certificates/keys expire soon
If checked, KMail will warn when an S/MIME certificate or OpenPGP key is used which will expire soon.
The period in which to warn before key/certificate expiration can then be configured separately for signing and encryption keys, as well as (in the case of S/MIME), for end-user certificates, intermediate CA certificates and root certificates.
- Re-Enable All "Don't Ask Again" Warnings
Apart from the main warnings described above, there are more warning and information messages, which contain an option to not show them again. If you would like to re-enable them after choosing not to show them again, you can achieve this by pressing this button.
This tab contains selected entries from GpgSM's . Please refer to the GpgSM manual for a description of these options.
- Validate certificates using CRLs
If checked, S/MIME certificates are validated using Certificate Revocation Lists (CRLs).
- Validate certificates online (OCSP)
If this option is selected, S/MIME certificates are validated using the Online Certificates Status Protocol (OCSP).
Fill in the URL of the OCSP responder in the field reserved at this effect.
- OCSP responder URL
Enter the address of the server for online validation of certificates. The URL is usually starting with http://.
- OCSP responder signature
Select or change and enter the S/MIME key to use.
- Ignore service URL of certificates
Check this option to skip online validation using the OCSP. This Option requires dirmngr >= 0.9.0.
- Do not check certificate policies
By default, GnuPG uses the file ~/.gnupg/policies.txt to check if a certificate policy is allowed. If this option is selected, policies are not checked.
- Never consult a CRLs
If this option is checked, Certificate Revocation Lists are never used to validate S/MIME certificates.
- Fetch missing issuer certificates
Check this option if you want the missing issuer certificates to be fetched when necessary. This applies to both validation methods, CRLs and OCSP.
- Do not perform any HTTP requests
Entirely disables the use of HTTP for S/MIME.
- Ignore HTTP CRL Distribution Point of certificates
When looking for the location of a CRL, “the "to-be-tested"”certificate usually contains what are known as CRL Distribution Point (DP) entries, which are URLs describing the way to access the URL. The first found DP entry is used. With this option all entries using the HTTP scheme are ignored when looking for a suitable DP.
- Use system HTTP proxy
If this option is selected, the value of the HTTP proxy shown on the right (which comes from the environment variable http_proxy) will be used for any HTTP request.
- Use this proxy for HTTP requests
Enter here the location of your HTTP Proxy, which will be used for all HTTP requests relating to S/MIME. The syntax is “"host:port"”, for instance myproxy.nowhere.com:3128.
- Do not perform any LDAP requests
Entirely disables the use of LDAP for S/MIME.
- Ignore LDAP CRL Distribution Point of certificates
When looking for the location of a CRL, the “"to-be-tested"” certificate usually contains what are known as CRL Distribution Point (DP) entries, which are URLs describing the way to access the URL. The first found DP entry is used. With this option all entries using the LDAP scheme are ignored when looking for a suitable DP.
- Primary host for LDAP requests
Entering a LDAP server here will make all LDAP requests go to that server first. More precisely, this setting overrides any specified host and port part in a LDAP URL and will also be used if host and port have been omitted from the URL. Other LDAP servers will be used only if the connection to the proxy failed. The syntax is HOST or HOST:PORT. If PORT is omitted, “port 389” (standard LDAP port) is used.
 This option enables a mode of using mail encryption that is sometimes (misleadingly) called “transport-only” encryption. In this mode of operation, the message encryption is stripped off as soon as the message has reached its destination. The encryption lasts only while the message is on its way.
KMail supports this mode half-heartedly, since such functionality should better placed at the mail server (MTA) than at the mail client (MUA) level. Thus, future versions of KMail may drop support for this option.
 This will re-enable all such warnings for KMail. It does not make much sense to allow more fine-grained selection of which warnings to show since you can just check the option to suppress them again when they next show up.