Please note that we've decided to move our support portal to help.savignano.net to to further improve the services for our customers. The updated version of this page can be found at https://help.savignano.net/snotify-email-encryption/resolved-issues |
This page lists earlier issues that have been resolved. For a list of current limitations, please see Known Limitations.
Issues within Jira and/or JiraService Desk, affecting S/Notify in general
you use Jira Service Management 4.22 for Server
you want to add an email request channel for a JSM project
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.
Atlassian has fixed this bug in version 4.22.2 of Jira Service Management.
Introduced in Jira 8.10 and Jira Service Desk 4.10
You use Jira in version 8.10–8.11, or Jira Service Desk in version 4.10–4.11
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.
Because two version of the Java mail library have been delivered, it is unpredictable if S/Notify works or not, depending on which library is loaded first. |
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.
Atlassian has resolved the issue with Jira 8.12 and Jira Service Desk 4.12.
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:
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
stop your Jira instance
go to the WEB-INF/lib directory of your Jira installation
remove javax.mail-1.6.2.jar and javax.mail-api-1.6.2.jar
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.
Issues within Confluence, affecting S/Notify in general
Introduced in Confluence 7.0
You use Confluence in version 7.0–7.4
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.
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.
If, for some reason, you have to use Confluence 7.0–7.4, one the following work-arounds can be applied.
The cleanest way to fix is to update javax.mail-1.6.2.jar to jakarta.mail-1.6.4.jar.
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.4.jar
copy it into the WEB-INF/lib directory of your Confluence installation
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.
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.
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
Under the above circumstances, emails are not properly received by the JSM email handler.
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.
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.
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.
The app Jira Email This Issue (also known as: JETI) significantly extends Jira’s mail functionality.
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
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.
With S/Notify 3.4.2, we have provided a solution for this issue
Jira Service Management was formerly known as JiraService Desk
Also affects Jira 8.10+ with Jira Service Management added
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
Note that the standard email handler as configured under Jira Administration > System > Outgoing Mail is not affected by this issue! |
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.
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.
You use Jira Service Desk
You have configured a POP mail server account for incoming mail
You use S/Notify 3.2.1
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!
A fix has been released with S/Notify 3.2.2 for Jira.
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
When upgrading to S/Notify 3.2.0 from an earlier version, the per-project / per-space encryption settings were lost.
A fix has been released with S/Notify 3.2.1 for Jira and Confluence.
you have configured Jira for per-project encryption or Confluence for per-space encryption
and you have set encryption for ambiguous emails to off
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.
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.
Prior to release 3.1, you should activate encryption for all ambiguous emails.
you have configured that unencrypted emails are not allowed
and for some users, there may be no PGP key or S/MIME certificate available
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.
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.
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
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.
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.
there is more than one valid S/MIME certificate in the server key store for the server's email address
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.
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.