Encryption Settings

Using an S/Notify release before version 4.0? Then please refer to Earlier Versions for the appropriate documentation.

Under this configuration entry, you will find the following configuration options:

Encryption Type Priority

In this section of the S/Notify configuration settings, you can select which encryption method to use or prefer.

S/Notify encrypts emails for the recipient, and also for the sender if the sender's public key is available from the server keystore.

S/MIME only

Use only S/MIME encryption, even if a PGP key would be available. This also hides the PGP section in the user profile.

S/MIME preferred

Use S/MIME encryption, if an S/MIME certificate is available. Otherwise use PGP encryption, if possible.

PGP preferred

Use PGP encryption, if a PGP key is available. Otherwise use S/MIME encryption, if possible.

PGP only

Use only PGP encryption, even if an S/MIME certificate would be available. This also hides the S/MIME section in the user profile.

Encryption Fallback

In this section of the S/Notify configuration settings, you can configure how S/Notify should process emails which cannot be sent encrypted for any reason whatsoever.

Note that, independent from what you select here, the reason for the encryption failure is always documented in the Jira log file.

Allow unencrypted notifications

S/Notify will try to encrypt emails, but if encryption fails for any reason, the message will be sent unencrypted.

Note that this option allows unencrypted emails to be sent out without further notice!

We recommend to use this option only until you have fully setup S/Notify and provided all necessary certificates and/or keys required to encrypt notifications for all Jira users.

Do not allow unencrypted notification - send problem report instead

S/Notify will try to encrypt all emails. If the encryption fails for any reason, an unencrypted problem report will be sent to the user instead. In the message, the user will be asked to get in contact with a Jira admin.

Use this option, if you have setup S/Notify with all required certificates, but want to make sure that any encryption problems will be reported via an email, so the user will be warned that he or she has missed a notification.

We recommend to use this option for production.

Sub-option: Include link to the issue that triggered the email

When this option is active, if possible, S/Notify includes a link in the problem report, so the recipient can click on it to open the browser and get directly to the Jira issue that triggered the email.

Do not allow unencrypted notifications - skip entirely

S/Notify will try to encrypt all emails. If the encryption fails for any reason, the email will not be sent out. Note that the user will not know that he or she has missed a notification.

Use this option, if you have setup S/Notify with all required certificates, and you do not even want any encryption problem warnings to be sent unencrypted. Be aware that, in this case, it is strongly advised to monitor the Jira log file for encryption failures, to make sure they do not go undetected.

Per Project Encryption

In this section, you can set up S/Notify to selectively encrypt emails based on the project they refer to. Once per project configuration has been enabled, additional options will appear.

In order to make this selection, S/Notify examines the emails to identify the project they refer to, then looks up the per project encryption setting and takes the appropriate action.

When this option is active, project administrators can switch on or off encryption for their projects in the Email Security section of the Project Settings.

Allow project configuration

When this option is checked, project administrators will be allowed to switch encryption on or off independently for each of their project from the section Email Security in the project settings pages. When this option is not checked, encryption can be controlled only from the above global configuration settings.

Once activated, the following options will become available:

Encrypt by default

This setting specifies what to do for projects that have not configured email encryption yet. This applies to all projects when you activate per project configuration for the first time, as well as to all projects that are created after that. When selected, emails for these projects will be encrypted, otherwise they will be sent unencrypted.

Encrypt ambiguous

This setting specifies what to do with emails that refer to more to one project with different encryption settings if S/Notify cannot determine which of these projects was sent for. Note that emails referring to multiple projects which all have the same encryption setting are not considered ambiguous. When selected, ambiguous emails will be encrypted, otherwise they will be sent unencrypted. We recommend to encrypt ambiguous emails.

Encrypt other

This setting specifies what to do with emails that do not refer to any project. For example, any account related emails would fall in this category, like password reset emails. When selected, such emails will be encrypted, otherwise they will be sent unencrypted.

Exemptions

This section provides options to exempt specific emails from encryption. If set, these options override all other settings, so email that match one of the criteria will never be encrypted.

Password reset emails

When enabled, emails that are sent to users to recover access to Jira will always be sent unencrypted. Use this if your users should be able to reset their password in Jira. Note that this might not be useful if user credentials are managed outside of Jira.

When enabled, the following types of emails are never encrypted

initial user invite
request to reset the password
account email confirmation

In Jira Service Management, this also applies to customers.

User group

Use this to exempt all emails that are sent to members of a specific user group from encryption. Users in this group will receive only unencrypted emails.

Email Subject

In this section, you can switch on encryption of the subject header. Email headers are not normally encrypted. This option activates an extension to S/MIME and PGP/MIME. See below for details.

Encrypt subject

When enabled, the subject header will be moved to the encrypted part while the email subject will be replaced by three dots.

Note that support for encryption of the subject header is somewhere between weak and non-existent in most email clients, and there are different approaches to this problem. If you activate this option, S/Notify will encrypt the subject according to the legacy mode described in Protected Headers for Cryptographic E-mail. We found this approach to be the most compatible and least confusing to the user.

However, we also support header encryption according to the recommendations in RFC8551 (S/MIME). Please get in touch with us if this is your preferred choice.

With regard to inbound email, both types of subject encryption are recognized and treated correctly which means that the encrypted subject is automatically decrypted and extracted.

Keep task ID

Due to the weak client support for encrypted subjects, clients that organize emails in threads using the email subject will fail miserably because all email subjects look identical. To re-enable the thread view in clients without exposing too much information, this option will keep the Jira prefix and task ID in the subject (but the task title will still be removed), so email clients can still provide a correctly threaded view.

Outgoing Signature

This section allows you to sign outgoing emails.

Sign emails

When selected, S/Notify will attempt to sign all outgoing emails using an appropriate PGP key or S/MIME certificate retrieved from the key store(s) provided in Server Key Management. The PGP key or S/MIME certificate must be issued for signing purposes as well as for the sender email address. This is usually the email address configured under Outgoing Mail, but keep in mind that you might be using additional project specific email addresses. If you use multiple sender addresses, you can either use multiple keys or certificates, or one that has been issued for multiple email addresses (or even a mixture of both variants).

S/Notify will sign emails according to the encryption method selected under Encryption Type Priority. If you have configured S/Notify to support both encryption methods, then the email will be signed according to the actual method used for encryption. When an email is sent unencrypted for any reason, the method for signing is selected based on the preference setting for encryption. The PGP key or S/MIME certificate is selected based on each email's sender email address.

If more than S/MIME certificate or PGP key is available in the keystore for the sender email address, S/Notify selects the one that has the latest expiration date.

For S/MIME, any intermediate certificates will be included in the email signature, provided they are available from the server keystore.

Opaque S/MIME signatures

When selected, S/Notify uses so-called opaque S/MIME signatures instead of detached or clear-text signatures. With opaque signatures, the message contents is encoded and cannot be read in email clients that do not support opaque signatures.Therefore, we recommend not to use opaque signatures unless necessary.

Some email servers, especially MS Outlook servers, are known to reformat emails. This will break detached signatures, because the receiving email client will (rightly) complain about the message having been tampered with. This problem can only be avoided by the use of opaque signatures.

Prior to version 4.0, opaque signatures could only be enabled via the Advanced Settings dialog.

Incoming Email

If incoming emails are encrypted, S/Notify will always attempt to decrypt them. However, this section allows you to configure additional processing of incoming emails.

Add indicators

When selected, S/Notify will add information to all incoming emails that indicates

that the contents has been added via email
if applicable, that the email came encrypted
if applicable, that the email was signed

The information will be part of the Jira description or comment created by the email. This is an example of how this may look:

If encrypted and/or signed, its type is indicated as PGP or S/MIME. The following symbols are currently used:

	Issue description or comment was created from incoming email
	Email was encrypted, has been decrypted (encryption type preceding this symbol)
	Email was encrypted with a non-preferred cipher, yet has been decrypted (possible downgrade attack, optionally disable under Advanced Settings)
	Email was encrypted with an unknown key (that was not found in the server keystore), so could not be decrypted
	Email was encrypted, but could not be decrypted for any other reason (refer to log file for details)
	Email was signed, and signature has been successfully verified
	Email was signed with an unknown key (that was not found in any of the user keystores), so certificate issuer could not be verified
	Email signature verification failed, so email may have been tampered with

Remove signatures

When selected, S/Notify will remove email signatures (if exist) from all incoming emails after they have been verified. Use this option to avoid getting these signature files attached to the Jira issues over and over again.

For S/MIME, so-called opaque signatures will be decoded and the message contents passed on to inbound processing, while the original signature will either be dropped or re-attached to the decoded message according to what is configured here.

Decryption processing

Key or certificate selection

When S/Notify is installed and active, and Jira inbound processing has been configured to use the IMAP or POP protcol, decryption of incoming email will always be attempted. Every time an encrypted email is received, S/Notify checks if it has a private PGP key or S/MIME certificate available that can be used to decrypt the email.

If more than one private S/MIME certificate or private PGP key is in the keystore, S/Notify will automatically select the right one, which is the one the email was encrypted for using the corresponding public key.

If the email cannot be decrypted, it is passed on unchanged to Jira's inbound processing. Note that such an email usually looks like an empty message (not Text) with just an attachment to Jira, and may therefore be rejected, depending on the setup of the incoming mail handler.

Encrypted subjects

For encrypted emails with hidden (encrypted) subjects, S/Notify automatically recognizes them and restores the original subject field, so the Jira inbound handler can find the appropriate Jira issue.

For S/MIME, so-called opaque signatures will be decoded and the message contents passed on to inbound processing.

Signature verification

For verification of S/MIME signed emails, the certificate and certificate chain will be checked. If you use non-public custom company root certificates, they must have been added to the Java trust store of the Jira instance. For instructions how to do this, please see Java Trust Store.
For verification of PGP signed emails, the corresponding public PGP key must be available from one of the sources defined in User Key Management.
Signatures are always verified. However, if the option to add indicators is not active, any warnings about verification failures will only be apparent from the log file.

Note that the indicators added to the email will become part of the Jira description or comment. Therefore, if Jira users are authorized to edit these descriptions or comments, they are also able to modify these indicators. If this is considered a security risk, editing of descriptions and comments should be disabled.

Advanced Settings

On the top right, there is a button that takes you to Advanced Settings. Our customer service might ask you to enter specific values here for special customizing or trouble shooting purposes.

Some of these options are explained under Advanced Settings.