(3.x) Encryption Settings - S/Notify for Jira
Orange colored text describes functional differences in previous 3.x releases
Under this configuration entry, you will find the following configuration options:
Encryption Settings
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.
Prior to version 3.1, emails were encrypted only for the recipient.
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.
Prior to version 3.6, this option was not available.
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.
Prior to version 3.1, only the option Encrypt ambiguous was available and referred to any email with multiple project references or none at all.
Exemptions
Prior to version 3.6, this section was named Exemption Allowlist and provided only the user group exemption.
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.
Prior to version 3.6, this option was not available.
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.
Prior to version 3.1, this option was not available.
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.
Prior to version 3.2, subject encryption was not available.
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.
Prior to version 3.3, this option was not available.
Signatures
This section allows you to configure how to handle email signatures.
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.
Prior to version 3.1, intermediate certificates were not included.
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.
Prior to version 3.5, this section was called Incoming Signatures, and the Add indicators feature was not available.
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:
Prior to version 3.5, this functionality was not available.
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 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, but 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.
Prior to version 3.1, opaque signature decoding required the Remove signatures option to be active.
Decryption processing
Key or certificate selection
When S/Notify is installed and active, and Jira inbound processing has been configured, 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.
Prior to version 3.1, opaque signature decoding required the Remove signatures option to be active.
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 (3.x) 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 (3.x) Advanced Settings.