Known Limitations

This page lists all known limitations that are currently unresolved. For a list of resolved limitations, please see


General Limitations

Limitations that might affect normal usage of S/Notify in Jira or Confluence

There are currently no known limitations in this category.

Marginal Limitations

Limitations that occur only under very specific circumstances

Alias Not Found in S/MIME Keystore


  • 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)


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.


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.


The keystore can be fixed using the Java keytool utility like so:

1 keytool -importkeystore -srckeystore original_keystore.pfx -destkeystore fixed_keystore.p12 -deststoretype pkcs12

This 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.

GPG Keybox Format


  • you use GPG 2.1 or newer which stores its PGP keyring in the new keybox format

  • you want to use the same GPG keystore file with S/Notify


Under the above circumstances, S/Notify accepts the keystore file, but cannot read any keys from the keystore.

When you hit Verify Settings, it returns: IOException - invalid armor.


S/Notify does not currently support the new keybox format.


Either configure GPG to use the old keystore format, or export the keys in ASCII-armored or (old) GPG binary format.

Duplicate Email Addresses


  • you have two or more users sharing the same email address

  • and user uploads are allowed


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.


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.


Different users having the same email address should not have different S/MIME certificates or PGP keys uploaded to their user profile.

Inline PGP Not Supported (Jira only)


  • inbound email processing is active with PGP support

  • and users may decide to send PGP/inline encrypted emails


S/Notify supports the only standard there is for sending OpenPGP Mails, which is PGP/MIME. PGP/inline is an undocumented non-standard format, which leads to several problems, which is why it should not be used any more. In the past this was a controversial question, but recently there’s come to be a consensus: use PGP/MIME whenever possible.

This should not be a problem for outgoing emails, but note that incoming PGP encrypted emails are not recognized when they are in PGP/inline format. 


We are currently working on optional support for PGP/Inline in incoming emails. Until then, PGP/Inline encrypted emails will not get decrypted, but passed on unchanged to Jira.


Users should use PGP/MIME only to PGP encrypt emails sent to Jira.

Invites in Encrypted Emails Not Visible in MS Outlook


  • outbound email encrypted with S/MIME

  • outgoing mail contains an ics file attachment for an invite

  • recipient views message in Microsoft Outlook client


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 an 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 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.


There is no working solution. Microsoft needs to fix this, but hasn’t yet.


As the only existing work-around, Microsoft always sends invites unencrypted. However, S/Notify does not currently check outgoing emails for invites. Please let us know 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 (also known as: JETI) significantly extends Jira’s mail functionality. To date, there is a known issues with Jira Email This Issue when not used with Jira’s mail handler, but with the custom built-in mail handler of this app.

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 JETI Next Gen Mail Handler


  • Jira Email This Issue app is configured to receive emails over its own built-in Next Gen Mail Handler


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


We have proposed a solution to the vendor of Email This Issue to make S/Notify and JETI Next Gen Mail Handlers compatible with each other. We are still waiting for them to restore full compatibility between our apps.

Customers interested in the integration are encouraged to contact META-INF, the vendor of Email This Issue to ask for their current progress status.


There is a 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:

1 2 3 4 protocol=imap; type=store; class=net.savignano.snotify.jira.mailer.imap.SnotifyImapStore; vendor=savignano software solutions,; protocol=imaps; type=store; class=net.savignano.snotify.jira.mailer.imap.SnotifyImapsStore; vendor=savignano software solutions,; protocol=pop3; type=store; class=net.savignano.snotify.jira.mailer.pop3.SnotifyPop3Store; vendor=savignano software solutions,; protocol=pop3s; type=store; class=net.savignano.snotify.jira.mailer.pop3.SnotifyPop3sStore; vendor=savignano software solutions,;

or just download the file from

Install S/Notify if not done so already (minimum version 3.6.1). Now you can apply the patch:

  1. download the Email This Issue app to your computer

  2. open the jar file using a ZIP utility (all jars are archives in zip format)

  3. add the mail providers file to the archive under META-INF/javamail.providers

  4. save 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 is 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.

Incoming encrypted mail


  • Send Email To Page app is installed in Confluence to process incoming emails

  • Users send encrypted emails


Incoming email won’t get decrypted because in Confluence, there is usually no support for incoming email, so S/Notify for Confluence does not include the functionality.


While S/Notify could process incoming email with Send Email To Page, to date, we haven’t seen any requests.

Customers interested in the integration are encouraged to let us know!


There’s no way currently. Please contact our service desk for available options.