| Info |
|---|
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/known-limitations |
This page lists all known limitations that are currently unresolved. For a list of resolved limitations, please see Resolved Issues.
| Table of Contents | ||
|---|---|---|
|
General Limitations
Limitations that might affect normal usage of S/Notify in Jira or Confluence
...
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.
...
LDAP: Unprocessed Continuation Reference(s)
Preconditions
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/NotifyActive Directory
you have multiple catalogs connected in your Active Directory setup
Description
Under the above circumstances, the retrieval of S/Notify accepts the keystore file, but cannot read any keys from the keystore.
When you hit Verify Settings, it returns: IOException - invalid armor.
Resolution
S/Notify does not currently support the new keybox format.
Work-around
Either configure GPG to use the old keystore format, or export the keys in ASCII-armored or (old) GPG binary formatMIME certificates from the Active Directory may fail with an error message saying: Unprocessed Continuation Reference(s).
This means that Active Directory has returned additional directories to look at (a so-called referral), but the client did not follow it. With referral chasing enabled in Active Directory, the client could go from domain to domain in the Active Directory tree trying to satisfy the request if the query cannot be satisfied by the initial domain. This method can be extremely time-consuming, which is why S/Notify does not perform referral chasing, but Active Directory does not accept that and throws an error when the client does not follow the referral.
Resolution
S/Notify should ignore the referral error. However, this is being prepared for the next release.
If, however, it is required to follow referrals in order to search the whole Active Directory, it is recommended to use Active Directory's Global Catalog instead, which is much faster. To connect to the Global Catalog, in the LDAP connection setup, replace 389 by port 3268, or port 686 by 3269, respectively.
Work-around
Use Active Directory's Global Catalog. To connect to the Global Catalog, in the LDAP connection setup, replace 389 by port 3268, or port 686 by 3269, respectively.
Duplicate email addresses
...
As the only existing work-around, Microsoft always sends invites unencrypted. However,
You can configure S/Notify does not currently check outgoing emails for invites. Please let us know to send emails unencrypted when they include ics attachments. Refer to https://savignano.atlassian.net/wiki/spaces/SNOTIFY/pages/2624880659/Advanced+Settings#Key-skipEncryptionRegex for the relevant setting and reach out to our service desk if you run into this problem.
PGP: GnuPG keybox format
Preconditions
you use GnuPG 2.1 or newer which stores its PGP keyring in the new keybox format
you want to use the same GnuPG keystore file with S/Notify
Description
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.
Resolution
S/Notify does not currently support the new keybox format. However, it is being prepared for the next feature release.
Work-around
Either configure GnuPG to use the old keystore format, or export the keys in ASCII-armored or (old) GPG binary format.
PGP: AEAD encrypted emails cannot be decrypted
Preconditions
inbound email encrypted with PGP
the email is encrypted using the new AEAD method
Description
Decryptions fails. The log file shows an error unknown packet type 20.
GnuPG 2.3 generates keys with an AEAD algorithm, and GnuPG 2.3 by default uses this algorithm to encrypt. However, to date, while AEAD is proposed to become part of the OpenPGP standard, it has not been approved yet (see OpenPGP Message Format Draft rfc4880bis-10). To the best of our knowledge, it is not yet broadly supported. Applications based on GnuPG usually still use GnuPG 2.2 under the hood.
Resolution
We are planning working to include AEAD support in a future the next feature release of S/Notify.
Work-around
In GnuPG 2.3, the --rfc4880 or --openpgp flag must be used so it conforms to the PGP standard.
PGP: No indicators added for one-pass signatures
Preconditions
inbound email encrypted with PGP
the email is encrypted with a one-pass signature (packet tag 4 according to RFC 4880, the Flowcrypt GMail extension is known to use this)
S/Notify is configured to “add indicators” to issues from incoming mails
Description
The message is decrypted, but the signature symbol is not added.
Resolution
We are planning to improve one-pass signature support in a future release of S/Notify.
Work-around
Use conventional detached signatures.
Third-party App Limitations
...
The app Jira Email This Issue (also known as: JETI) significantly extends Jira’s mail functionality. To date, there is a known issues with
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)
| Note |
|---|
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. |
...
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
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 upvote the feature request for Email This Issue here and/or to contact META-INF, the vendor of Email This Issue to ask for their current progress status.
Work-around
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:
...
Install S/Notify if not done so already (minimum version 3.6.1). 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.
...
Send Email To Page app is installed in Confluence to process incoming emails
Users send encrypted emails
Description
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.
Resolution
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!
Work-around
There’s no way currently. Please contact our service desk for available options.
Other Third-party Limitations
Microsoft Outlook Issues
Invalid signatures
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 Outlook. 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.
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.
Microsoft Exchange Issues
Invalid signatures
Precondition
Signed-only emails sent through an Exchange server are recognized as invalid and possibly tampered with
Description
The signature of signed-only (not encrypted) emails sent through a Microsoft Exchange server are shown as invalid.
This is caused by Exchange 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
The use of opaque signatures prevents the 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.