This page lists earlier issues that have been resolved. For a list of current limitations, please see https://savignano.atlassian.net/wiki/spaces/SNOTIFY/pages/877199383.

Jira Issues

Issues within Jira and/or JiraService Desk, affecting S/Notify in general

Resolved with Jira Service Management 4.22.2

No ‘Other’ Email Channel in Jira Service Management 4.22

Preconditions

• you use Jira Service Management 4.22 for Server

• you want to add an email request channel for a JSM project

Description

In Jira Service Management 4.22.0, Atlassian introduced a bug (JSDSERVER-11219) that causes the Email service provider option Other to be missing. Therefore it is not possible to create a new Email request channel from a custom mail server.

The issue occurs only in the Server, but not in the Data Center edition of JSM.

Resolution

Atlassian has fixed this bug in version 4.22.2 of Jira Service Management.

Resolved with Jira 8.12 and Jira Service Desk 4.12

Duplicate Java Mail Library

Introduced in Jira 8.10 and Jira Service Desk 4.10

Preconditions

• You use Jira in version 8.10–8.11, or Jira Service Desk in version 4.10–4.11

Description

In Jira 8.10, Atlassian updated Java mail library to jakarta.mail-1.6.5.jar, but unfortunately, they also deliver the older mail library version 1.6.2 which has an issue that prevents S/Notify from working as expected. 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 with Jira 8.10–8.11, including Jira Service Desk 4.10–4.11. It is independent from the release version of S/Notify. 

Resolution 

Atlassian has resolved the issue with Jira 8.12 and Jira Service Desk 4.12.

Work-around

Do not use Jira 8.10 and 8.11 or Jira Service Desk 4.10 and 4.11. Update to Jira 8.12 or Jira Service Desk 4.12.

If, for some reason, you have to use Jira in one of the problem versions, you can apply the following fix manually:

Remove the problem version

The cleanest way to fix the issue is to remove javax.mail-1.6.2.jar and javax.mail-api-1.6.2.jar.

To do so

1. stop your Jira instance

2. go to the WEB-INF/lib directory of your Jira installation

3. remove javax.mail-1.6.2.jar and javax.mail-api-1.6.2.jar

4. start Jira

Note that, from version 1.6.3, the Java mail library has been moved to the Eclipse project Jakarta, and that's why the jar name has changed.

Confluence Issues

Issues within Confluence, affecting S/Notify in general

Resolved with Confluence 7.5

Malfunctioning Java Mail Library

Introduced in Confluence 7.0

Preconditions

• You use Confluence in version 7.0–7.4

Description

In Confluence 7.0, Atlassian has updated some of the Java libraries used by Confluence. 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 with Confluence 7.0, 7.1, 7.2, 7.3, up to 7.4. It is independent from the release version of S/Notify. 

Resolution 

In Confluence 7.5, Atlassian has fixed this issue by replacing the broken version by jakarta.mail-1.6.5.jar. We recommend that you update to Confluence 7.5.

Work-around if you cannot update

If, for some reason, you have to use Confluence 7.0–7.4, one the following work-arounds can 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.4.jar.

To do so

1. stop your Confluence instance

2. go to the WEB-INF/lib directory of your Confluence installation

3. remove javax.mail-1.6.2.jar and javax.mail-api-1.6.2.jar

4. download the offical jakarta.mail-1.6.4.jar

5. copy it into the WEB-INF/lib directory of your Confluence installation

6. start Confluence

Note that, from version 1.6.3, the Java mail library has been moved to the Eclipse project Jakarta, and that's why the jar name has changed.

Alternative options

While the above fix is the preferred one, there are two more options you have:

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.

You can go back to the previous version which does not have the issue.

Issues Resolved with S/Notify 3.6.1

IMAP Server Collision in JSM

Preconditions

• you use Jira Service Management with JSM email handlers (“email request channels”)

• you also use a standard incoming email handler

• both email handlers are configured to use the same IMAP server account with different email recipient addresses

• the standard incoming email handler is configured to use the IMAP inbox folder

Description

Under the above circumstances, emails are not properly received by the JSM email handler.

Resolution

With S/Notify 3.6.1, we have fixed an issue that caused incoming email checked by the standard email handler to be marked ‘seen’, causing the JSM mail handler to skip them in subsequent retrievals.

Issues Resolved with S/Notify 3.6.0

Inline PGP Not Supported (Jira only)

Preconditions

• inbound email processing is active with PGP support

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

Description

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. 

Resolution

Support for PGP/Inline in incoming emails can now be enabled. For security reasons, it is disabled by default.

Please refer to https://savignano.atlassian.net/wiki/spaces/SNOTIFY/pages/2624880659/Advanced+Settings#Support-Incoming-PGP/Inline for details.

Issues Resolved with S/Notify 3.4.2

SMTP connection in Jira Email This Issue

The app Jira Email This Issue (also known as: JETI) significantly extends Jira’s mail functionality.

Outgoing mail with JETI SMTP Connection

Precondition

• You use the Jira Email This Issue app

• Jira Email This Issue app is configured to send emails over its own built-in SMTP Connection handler

Description

A ClassNotFound or UnsupportedDataType exception occurs when S/Notify tries to encrypt the email. This is due to an issue with the class loader not finding existing classes.

Resolution

With S/Notify 3.4.2, we have provided a solution for this issue

Issues Resolved with S/Notify 3.2.3

Jira Service Management 4.10+ Class Loader Issue

Jira Service Management was formerly known as JiraService Desk

Also affects Jira 8.10+ with Jira Service Management added

Class Loader Issue with Java Mail Library

Preconditions

• You use Jira 8.10 and newer with Jira Service Management installed as an app, or you use Jira Service Management 4.10 and newer 

• You use project-specific email channels as configured under Jira Administration > Projects > Email requests

Description

In Jira 8.10, Atlassian updated Java mail library to jakarta.mail-1.6.5.jar to fix an issue with javax.mail-1.6.2.jar, but unfortunately, while doing so, they obviously introduced a class loader issue. Due to this issue, an error occurs when using project-specific email channels (Project Settings > Email Requests > Setup you email channel) if S/Notify is installed. 

javax.mail.Provider: Provider net.savignano.snotify.jira.mailer.provider.SnotifySmtpProvider not found

The issue affects S/Notify with Jira Service Management 4.10 and newer or Jira 8.10 and newer with Jira Service Management (any version) installed as an app.

Resolution 

We have reported this problem to Atlassian. 

Fortunately, we have also found a way to get around this issue from within the app. The work-around has been released with S/Notify 3.2. for Jira.

Issues Resolved with S/Notify 3.2.2

POP Mail Server issue with Jira Service Desk

Preconditions

• You use Jira Service Desk

• You have configured a POP mail server account for incoming mail

• You use S/Notify 3.2.1

Description

With POP accounts, when searching for incoming mails, a StackOverflowException can occur. As a consequence, the incoming emails of that account cannot be read.

This issue was introduced with S/Notify 3.2. Sorry for that!

Resolution 

A fix has been released with S/Notify 3.2.2 for Jira.

Issues Resolved with S/Notify 3.2.1

Upgrade issue in S/Notify 3.2.0

Preconditions

• S/Notify was upgraded to 3.2.0 from an earlier version

• and per-project encryption in Jira or per-space encryption in Confluence was active

Descriptions

When upgrading to S/Notify 3.2.0 from an earlier version, the per-project / per-space encryption settings were lost.

Resolution

A fix has been released with S/Notify 3.2.1 for Jira and Confluence.

Issues Resolved with S/Notify 3.1.0

Encryption of ambiguous emails 

Preconditions

• you have configured Jira for per-project encryption or Confluence for per-space encryption

• and you have set encryption for ambiguous emails to off

Description

If a notification is sent for a project or space with activated encryption, and if the notification contains a link to another project or space with deactivated encryption, the email will not be encrypted. This is because, in this case, the email is considered to refer to more than one project or space, and then the configuration setting for ambiguous emails is used.

Resolution

From S/Notify 3.1, the encryption handling for emails with multiple project or space references is configured separately from emails with no project or space reference at all, the latter now being under Encryption Settings >Per Project/Per Space Encryption > Encrypt other.

In addition to that, emails referring to multiple projects or spaces are no longer considered ambiguous if the encryption settings for all of these projects or spaces are the same. Or in other words, only if the encryption settings of the referred projects or spaces differ, then the email is considered ambiguous.

Work-around

Prior to release 3.1, you should activate encryption for all ambiguous emails.

Password reset emails

Preconditions

• you have configured that unencrypted emails are not allowed

• and for some users, there may be no PGP key or S/MIME certificate available

Description

If S/Notify is configured to not allow unencrypted notifications, then no unencrypted emails are sent at all. While this is undoubtedly the designed and expected behavior, it may have the possibly unwanted side effect that users can request password reset emails, but they will never receive them because they cannot be encrypted.

Resolution

From S/Notify 3.1, emails not referring to any Jira project or Confluence space can be handled separately using the configuration setting under Encryption Settings >Per Project/Per Space Encryption > Encrypt other. 

Opaque signatures (Jira only)

Preconditions

• inbound email processing is active

• and users send emails with a so-called opaque signature (application/pkcs7-mime with SignedData)

• and you have configured S/Notify not to remove signatures of inbound signed emails

Description

Opaque signatures are signatures that are not a separate part of the clear text email, but the email contents has become part of the signature. This type of signature has a disadvantage of not allowing clients that are not S/MIME capable to see the message contents while at the same time, it does not provide any additional safety because the data are just encoded, not encrypted. Therefore, it has become uncommon to use opaque signatures. However, in some situations it may be in use because it prevents mail servers (like Exchange servers sometimes) from reformatting the mail contents. When S/Notify removes an opaque signature from an inbound email, its encoded email contents gets decoded and passed on to Jira inbound processing, but when it is configured not to remove signatures from inbound emails, the signature is left untouched and therefore the encoded email contents will not get extracted.

Resolution

From S/Notify 3.1, 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 under Encryption Settings > Outgoing Signatures > Remove signature.

Overlapping server S/MIME certificates (Jira only)

Preconditions

• there is more than one valid S/MIME certificate in the server key store for the server's email address

Description

If more than one S/MIME certificate is available in the server key store, then S/Notify could fail to select the correct one, i.e. the one that the incoming email has been encrypted with.

Resolution

From S/Notify 3.1, if multiple S/MIME certificates are stored in the server key store, the appropriate S/MIME certificate will be searched and selected for decryption.