The Security configuration dialog lets you fine-tune certain rich text (HTML) options. It also allows you to control encryption and decryption features, to adjust some built-in anti-phishing logic, and to specify how message disposition notification requests (aka return receipts) are handled. Notice that this dialog does not have anything to do with anti-virus security measures. See the Using KMail: The Anti-Virus Wizard chapter if you want anti-virus security.
On this tab you can configure security options that affect the way you read messages.
- Prefer HTML to plain text
By default KMail will show HTML messages in plain text. If you prefer to view messages with HTML formatting and layout automatically, select this option. However, we recommend leaving this option off, as security problems with HTML might show up.
You can still easily view messages in HTML format by clicking the plain message/HTML message toggle bar on the left hand side of the preview pane.
- Allow messages to load external references from the Internet
If checked, KMail can load external images, style sheets, etc. from the Internet when you view an HTML message. We strongly recommend that you leave this option off (although it has no effect until you enable HTML).
- Informs if message reading is a suspected email scam
As email has become more popular, email scams have proliferated. Email scams may include emails made to appear as if they come from legitimate companies, even though they really link to malicious web sites requesting your personal information. This may lead to identity theft, and worse. By default KMail analyzes messages for common scams, and will inform you if a message is a suspected scam. We recommend that you keep this feature enabled. If you wish to disable these warnings, uncheck Informs if message reading is a suspected email scam.
If legitimate emails are being flagged, (e.g., from trusted friends), you can add their email addresses to the Whitelist: by clicking the button and entering an address into the dialog that pops up. Please note that at this time, only complete email addresses can be whitelisted.
- Check URL with Phishing Google System
Select this option to force KMail to consult Google's database of suspected phishing web sites when URLs are embedded in a message, and to warn you whenever a match is found.
- Scan emails for tracking URLs
By default, KMail will automatically check URLs embedded in HTML messages, and warn you if any of them appear to be trying to track you.
- Attempt decryption of encrypted messages when viewing
By default, KMail will automatically attempt to decrypt encrypted messages when you view them. If you prefer to do this manually, unselect this option.
- Automatically import keys and certificate
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 does not affect that. It is also unrelated to GPG's
auto-key-retrievefeature, where GPG will try to import unknown keys from a key server.
- 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 email 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” (i.e., 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 MDNs 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 message has been acted upon; he just cannot tell whether it was deleted or read, etc.
- Always send
Always sends the requested disposition notification. This 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. Then, if you find KMail's 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 with MDNs.
No parts of the message other than the mandatory message-id and the original recipient are included in the MDN reply. This preserves enough information for the sender to uniquely identify the message 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 (and not just the headers) with 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 this option set to the default value (nothing).
- 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 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 a choice: either to send them when requested (option unchecked), or never (option checked).
If unsure, leave this option checked (the default value).
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 any more.
- 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 may 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 encryption 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 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.
Click on this button to open an extensive dialog which configures the interactions between KMail and GPG, the Gnu Privacy Guard program. GPG is too complex to document here. For details you should refer to The GNU Privacy Handbook. Unless you're an encryption expert, you probably ought to accept the default settings here.
- Re-Enable All "Don't Ask Again" Warnings
Apart from the main warnings described above, there are many warning and informational messages, each containing an option not to show them again. If you would like to re-enable these messages after suppressing them, you can achieve that by pressing this button. 
This tab contains selected entries from GpgSM's dynamic back end configuration dialog. Please refer to the GpgSM manual for a more detailed description of these options.
- Validate certificates using CRLs
If checked, S/MIME certificates are validated using Certificate Revocation Lists (CRLs). This is the default configuration option.
- Validate certificates online (OCSP)
If this option is selected, S/MIME certificates are validated using the Online Certificates Status Protocol (OCSP).
- OCSP responder URL:
Enter the address of the server for online validation of certificates. This URL usually starts with https://.
- 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.txtto check if a certificate policy is allowed. If this option is selected, such 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 the location of your HTTP Proxy here, which will be used for all HTTP requests relating to S/MIME. The syntax is “host:port”, for example, 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 be placed at the mail server (MTA) and not 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 the next time they appear.