Known Limitations
This page lists all known limitations that are currently unresolved. For a list of resolved limitations, please see Resolved Issues.
General Limitations
Limitations that might affect normal usage of S/Notify in Jira, Confluence or Bitbucket
Error when uploading user S/MIME certificate
Preconditions
User uploads of S/MIME certificates are enabled
Description
When a user tries to uploads their S/MIME certificate in PEM format, the file might be rejected with the following error: Unable to initialize, java.io.IOException: Short read of DER length
The problem occurs when the encoded certificate and the public key in the PEM file are not in the expected order. The certificate must come before the key. Most tools seem to export certificates to PEM in the required order, but some may not.
While RFC 7468 is not specific about the order (“Whether the instances are ordered or unordered depends on the context.”), this seems to be a limitation in Java, expecting the certificate to be first.
Resolution
Newer versions of Java might support the certificate and public key in any order.
Work-around
Open the PEM file in an editor to simply swap the order of the certificate and the public key parts.
Bitbucket Issues
Issues within Bitbucket, affecting S/Notify in general
Malfunctioning Java Mail Library
Introduced in Bitbucket 8.16, fixed in Bitbucket 9.0
Preconditions
You use Bitbucket in version 8.16.x–8.19.x
Description
In Bitbucket 8.16, Atlassian has updated some of the Java libraries used by Bitbucket. Unfortunately, the updated Java mail library version 1.6.2 has introduced a problem that leads to S/Notify not being able to get hold of and encrypt emails any more. Details about the problem are documented here. The issue has been fixed in version 1.6.4 of the Java mail library.
The issue affects S/Notify from Bitbucket 8.16.x up to and including 8.19.x, and it is independent from the release version of S/Notify.
Resolution
Atlassian has fixed this issue in Bitbucket 9.0 by updating javax.mail-1.6.2.jar to jakarta.mail-1.6.7.jar.
Work-around
If you have to use Bitbucket 8.16–8.19, the following work-around must be applied.
Update the Java mail library
The cleanest way to fix is to update javax.mail-1.6.2.jar to jakarta.mail-1.6.7.jar. We recommend version 1.6.7, because a few more notable fixes have been made since 1.6.4.
To do so
stop your Confluence instance
go to the WEB-INF/lib directory of your Confluence installation
remove javax.mail-1.6.2.jar and javax.mail-api-1.6.2.jar
download the offical jakarta.mail-1.6.7.jar
copy it into the WEB-INF/lib directory of your Confluence installation
start Confluence
Note that, from version 1.6.4, the Java mail library has been moved to the Eclipse project Jakarta, and that's why the jar name has changed, but the internal package names are still javax.mail until version 2.0.0, so they are fully compatible with previous versions.
Alternative options
While the above fix is the preferred and recommended one, there are two more options you have:
Patch javax.mail-1.6.2.jar
You can patch javax.mail-1.6.2.jar to work properly by removing the WEB-INF/services folder inside the jar. For your convenience, we provide a patched version of javax.mail-1.6.2.jar that you can just download and use to replace the one in your Confluence installation with it.
Downgrade javax.mail-1.6.2.jar to java.mail-1.6.1.jar
You can go back to the previous version which does not have the issue.
Re-authentication for configuration
Preconditions
This is a general limitation.
Description
When accessing the S/Notify configuration pages, no re-authentication (re-entering the password) is requested.
Resolution
Re-authentication for administrative pages is supported starting with Bitbucket release 9.0.
Work-around
There is no work-around. This limitation affects all administrative pages in Bitbucket versions before 9.0.
Marginal Limitations
Limitations that occur only under very specific circumstances
Microsoft Graph API not supported
Preconditions
you want to decrypt incoming mail (Jira only)
you have configured the incoming mail server or email channel to use the Microsoft Graph AP protocol
Description
The proprietary Microsoft Graph API protocol is not supported. Emails will not be decrypted.
Resolution
It is not technically possible to provide support for MS Graph API, unless Atlassian implements support for apps to register so-called Graph API interceptors, which isn't currently the case. Please reach out to Atlassian if you need S/Notify to work with Microsoft Graph API.
Work-around
Configure the mail server or email channel to use the IMAP or POP protocol.
Signature validation failure
Preconditions
you want to validate the signature in incoming mail (Jira only)
you have activated the Add indicators feature
the PGP key or S/MIME certificate used to sign the email is different from the one used for encryption
Description
Under the above circumstances, the symbol added to the email falsely indicates that the email signature could not be verified because the corresponding PGP key or S/MIME certificate was not available.
Resolution
We are planning to improve the signature validation processing in the next release.
Work-around
Have the users sign their emails with the same PGP key or S/MIME certificate that is used for encryption.
Alias not found in S/MIME keystore
Preconditions
you use S/MIME encryption
you want to decrypt incoming mail or sign outgoing mail (or both)
in Server Key Management, you have configured a PKCS#12 keystore (file suffix pfx or p12)
Description
The issue appears only under rare circumstances which we haven’t been able to reproduce on our end. Please contact us to provide any input if you happen to be affected by this issue.
In these circumstances, if you run Verify Settings, an error displays saying that the private key with alias <some alias> was not found in the keystore.
Resolution
We are currently collecting more information to find out why this happens and how to fix it programmatically. Until then, please apply the work-around described below.
Work-around
The keystore can be fixed using the Java keytool utility like so:
keytool -importkeystore -srckeystore original_keystore.pfx -destkeystore fixed_keystore.p12 -deststoretype pkcs12This causes the keytool utility to read the original keystore and create a copy that has the internal issues fixed. Configure S/Notify to use this fixed copy.
Duplicate email addresses
Preconditions
you have two or more users sharing the same email address
and user uploads are allowed
Description
If, in your Jira or Confluence, multiple users share the same email address, S/Notify cannot determine which of these users the email is actually meant for. Usually, this doesn't matter, because all these users would have to share the same S/MIME certificate or PGP key anyway, as these are bound to the email address.
As a consequence, if S/Notify is to use an S/MIME certificate or PGP key uploaded to the user profile, the upload should be made to the user profiles of all users with that email address. When uploading different S/MIME certificates or PGP keys to users that share the same email address, it is undetermined which of them will be used to encrypt an email.
Note that this is not a problem if S/Notify is configured to get S/MIME certificates and PGP keys from a key store or key server rather than from the user profile.
Resolution
In the unlikely case that different users with the same email address have uploaded different S/MIME certificates or PGP keys, it is impossible to determine which of them is the desired one for a specific email. Therefore, this specific issue cannot be resolved completely by the app.
However, S/Notify displays a warning in the user profile if there is another active user using that email address.
Work-around
Different users having the same email address should not have different S/MIME certificates or PGP keys uploaded to their user profile.
Calendar invites in encrypted emails not visible in MS Outlook
Preconditions
outbound email encrypted with S/MIME
outgoing mail contains an ics file attachment for a calendar invite
recipient views message in Microsoft Outlook client
Description
Note that this issue is not specific to S/Notify, but it occurs with any invite in an encrypted email viewed in Microsoft Outlook.
If an encrypted message contains a calendar invite, the invite cannot be seen in a Microsoft Outlook client. If the message is not encrypted, the invite works as expected.
This is a long-standing problem in the Microsoft Outlook client. Outlook tries to recognize calendar invites in order to present a dialog to accept or deny them. However, to do so, Outlook relies on a message header with Content-Type: text/calendar, but when a message is encrypted, this message header is inside the encrypted part. Obviously, Outlook does not decrypt the message when checking for that header, but later nonetheless hides the corresponding ics file attachment. As a result, neither the dialog nor the attachment can be seen, and the invite seems to have disappeared.
Resolution
There is no working solution. Microsoft needs to fix this, but hasn’t yet.
Work-around
As the only existing work-around, Microsoft always sends invites unencrypted.
You can configure S/Notify to send emails unencrypted when they include ics attachments. Refer to Key skipEncryptionRegex under Advanced Settings for the relevant setting and reach out to our service desk if you run into this problem.
Third-party App Limitations
Limitations that might occur in combination with other apps
Note that S/Notify is designed in a way that allows for maximum compatibility with other apps sending or receiving emails. Although we cannot guarantee compatibility with any app out there, we will always do our best to provide you with a solution, should you run into any issues. Apps that use the standard mail functionality of Jira or Confluence should always work without problems.
Jira Email This Issue
The app Jira Email This Issue extends (and replaces) Jira’s mail functionality.
S/Notify Email Encryption works seemlessly with the Classic Mail Handler in Jira Email This Issue
If Jira Email This Issue is used with its own custom built-in mail handler of this app, a patch is required to make it work with S/Notify Email Encryption (see description under Work-around)
As of Email This Issue 9.2.0-GA, support for Classic Mail Handlers has been dropped. For details, please refer to the release notes of Email This Issue.
Incoming mail with Jira Email This Issue Next Gen Mail Handler
Precondition
Jira Email This Issue app is configured to receive emails over its own built-in Next Gen Mail Handler
Description
S/Notify is not being invoked by the Next Gen mail handler. As a result
incoming mail cannot be decrypted
signature attachments cannot be removed
indicators cannot be added
Resolution
As of version 9.10.0.1-GA, Email This Issue support decryption of incoming S/MIME emails. Please refer to the respective documentation Secure the email channel with Email This Issue for details.
Note that the implementation in Email This Issue has the following limitations in comparison with S/Notify Email Encryption:
No signature verification available
PGP not supported, only S/MIME
No support for adding indicators
Other limitations may apply that we are not aware of.
Work-around
The following option enables the features of S/Notify Email Encryption with the Next Gen incoming mail handler of Email This Issue.
There is a proven work-around using a simple patch in Email This Issue. In order to enable Email This Issue to use the email decryption handlers in S/Notify, create a text file named javamail.providers with the following contents:
protocol=smtp; type=transport; class=net.savignano.snotify.jira.mailer.smtp.SnotifySmtpTransport; vendor=savignano software solutions, http://www.savignano.net;
protocol=smtps; type=transport; class=net.savignano.snotify.jira.mailer.smtp.SnotifySmtpsTransport; vendor=savignano software solutions, http://www.savignano.net;
protocol=imap; type=store; class=net.savignano.snotify.jira.mailer.imap.SnotifyImapStore; vendor=savignano software solutions, http://www.savignano.net;
protocol=imaps; type=store; class=net.savignano.snotify.jira.mailer.imap.SnotifyImapsStore; vendor=savignano software solutions, http://www.savignano.net;
protocol=pop3; type=store; class=net.savignano.snotify.jira.mailer.pop3.SnotifyPop3Store; vendor=savignano software solutions, http://www.savignano.net;
protocol=pop3s; type=store; class=net.savignano.snotify.jira.mailer.pop3.SnotifyPop3sStore; vendor=savignano software solutions, http://www.savignano.net;or just download the file from https://download.savignano.net/snotify/jira/releases/patch/javamail.providers
Now you can apply the patch:
download the Email This Issue app to your computer
open the jar file using a ZIP utility (all jars are archives in zip format)
add the mail providers file to the archive under
META-INF/javamail.providerssave and close the jar file
You have now successfully applied the patch.
Next, go to Jira administration > Manage apps, then click Upload app and select the patched jar file.
Now you can use Email This Issue to receive encrypted email and get it automatically decrypted by S/Notify.
There’s a little downside to this solution: if you ever choose to uninstall S/Notify, you will have to remember to remove the patch in Email This Issue at the same time.
Other Third-party Limitations
Microsoft Exchange Server Issues
Invalid signatures in outgoing email or incoming email
Precondition
Signed-only emails are sent through an Exchange server
Description
The signature of signed-only (not encrypted) emails sent through a Microsoft Exchange server are shown as invalid in the receiving email client.
This is caused by the Exchange Server reformatting emails, which leads to the receiving client rightly complaining about an invalid signature due to the email being modified during transport.
Resolution
Microsoft Exchange should not reformat emails at all, but at least not signed emails.
Work-around
To fix outgoing email, under Encryption Settings > Outgoing Signature, enable Opaque S/MIME signatures, which efficiently prevents the Exchange Server from reformatting the email.
As a work-around for incoming email, ask the sender to use opaque signatures. There’s no way for the receiving email client to implement a work-around for reformatted emails.
Microsoft Outlook Client Issues
Invalid signatures in incoming email
Precondition
Signed-only emails sent from an Outlook client are recognized as invalid and possibly tampered with
Description
The signature of signed-only (not encrypted) emails sent from a Microsoft Outlook client are shown as invalid.
This is caused by an incorrect implementation of the SMTP protocol in the latest Outlook client releases. A full stop character at column 1 of a message text line has a special meaning in SMTP. It is interpreted and removed by the SMTP server when the client delivers the email. Because of this, https://www.rfc-editor.org/rfc/rfc5321#section-4.5.2 requires hat the client adds an extra full stop character in this case. However, Outlook fails to do so, which leads to the receiving client rightly complaining about an invalid signature due to the email being modified during transport.
It is notable that even Outlook itself complains about its own signatures being invalid.
Resolution
Microsoft needs to fix the SMTP implementation in Outlook.
Work-around
The use of opaque signatures seems to avoid the SMTP issue. However, the latest Outlook does not seem to provide an option to use opaque signatures.
There’s no way for the receiving email client to implement a work-around.