Encryption Settings

Using an S/Notify release before version 2.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 Bitbucket 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 Bitbucket 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 Bitbucket 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.

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 Bitbucket log file for encryption failures, to make sure they do not go undetected.

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 Bitbucket will always be sent unencrypted. Use this if your users should be able to reset their password in Bitbucket. Note that this might not be useful if user credentials are managed outside of Bitbucket.

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.

Outgoing Signature

This section allows you to configure if and how 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.

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.