It is June again – the season of spring cleanup and refurbishment: prefect timing to also enhance the Kolab Now frontpage to give it more structure & clarity to communicate in a clear manner what makes us different and special.
It is June again – the season of spring cleanup and refurbishment: prefect timing to also enhance the Kolab Now frontpage to give it more structure & clarity to communicate in a clear manner what makes us different and special.
On Sunday 2025-06-15 one of the Kolab now ActiveSync servers were getting overloaded and got stuck on failed jobs. In turn, about 50% of the ActiveSync jobs were failing – leading to some ActiveSync users loosing the connections to Outlook or to their mobile devices.
Yesterday we dealt with a spammer/phisher who specifically targeted the Microsoft outlook.com service (and it’s affiliates). One of the Kolab Now MX servers was listed on the Microsoft throttle list (S3150). This meant that some users saw, that mails sent to recipients at ‘@outlook.com’, ‘@live.com’, ‘@hotmail.com’, and other Microsoft online services was bounced back.
Today we announce a change to the Kolab Now account types that will improve the user experience for new users.
Since the start of Kolab Now, new users could choose between two different types of accounts upon sign-up:
* Individual accounts, which was bound to a Kolab Now owned domain name (such as kolabnow.com, mykolab.ch, libertymail.com, etc) or..
* Group accounts, with which the new users could make use of their own private domain names.
This worked well for a long time, but lately this division of account types has caused confusion for new users. Therefore it was decided to simplify the systems, and bring the two types together into one unified Kolab Now account type for all.
This change will be implemented today:
Monday, 24.03.2025
Kolabnow is currently experiencing a service interruption which affects receiving of email as well as changes in the administration panel and payments. We apologize for the inconvenience while we investigate the issue.
We will update this blogpost as soon as more information is available.
2025-03-23 @ 14:15 UTC: This issue was triggered by an internal container-image storage issue which prevented services from restarting. The affected storage is unrelated to the storage used for customer payload data. The service interruption caused external emails to be temporarily rejected (as well as the above mentioned symptoms for administration of services). External email systems will re-attempt delivery, so no data should be lost, but some delays are to be expected.
2025-03-23 @ 14:25 UTC: Receiving of email as well as administration functionality has been restored.
This afternoon earlier today one of the Kolab Now MX servers was listed on the Microsoft block list. This means that some users might have seen, that mails sent to recipients at ‘@outlook.com’, ‘@live.com’, ‘@hotmail.com’, and other Microsoft online services was bounced back with the message that looks something like this:
This is the mail system at host mx.kolabnow.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<some-email@outlook.com>: host
outlook-com.olc.protection.outlook.com[x.x.x.x] said: 550 5.7.1
Unfortunately, messages from [y.y.y.y] weren't sent. Please contact
your Internet service provider since part of their network is on our block
list (S3150). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. [Name=Protocol
Filter Agent][AGT=PFA][MxId=<some long number>]
[SG2PEPF03345FBECA.apcprd05.prod.outlook.com 2025-02-13T<timestamp>Z
<another long number>] (in reply to MAIL FROM command)
Although the listing was fast discovered, Microsoft was contacted and the listing is reversed as soon as it is possible, it took a while. At this time emails should be delivered to the Microsoft online services.
A few users has misinterpreted the symptoms with error messages from missing the DKIM changes made on Monday (please read this blog post from December 2024 and the follow ups). If you are a group manager, then please make sure that you have the new DKIM related CNAMES added to your DNS zone.
If you have any questions or concerns in this context, then please contact support.
On December 20’th 2024 we announced a change to the DKIM configuration on Kolab Now. The announcement described actions needed for users with private domains. We recommended that group managers (the owners of private domains) set the following CNAMEs (both of them) in the DNS of their private domain:
dkim1._domainkey CNAME dkim1._domainkey.kolabnow.com.
dkim2._domainkey CNAME dkim2._domainkey.kolabnow.com.
We also said in the announcement, that we would provide the actual update top the system in the end of January. Unfortunately the snow in the Swiss alps was so wonderful in the end of January, that our techies got a bit delayed.
However, it has now come so far that we announce a service window on:
Monday February 10’th, 2025 @ 08:00 UTC.
The Service window will last for an hour, within which users might see a small bump in the performance.
If you are the owner of a private domain and you have not yet added the CNAME records to your domain, then your outgoing emails might be refused by the recipient servers after the change.
We will keep you up to date with the progress of the work via updates to this post.
– 2025-02-10 @ 07:59 UTC: The service window is now open and the work is in progress. As written, you should not see any big impact.
– 2025-02-10 @ 08:45 UTC: The change has been implemented, and the service window is done. The new domain alignment is tested and seems to be working as expected. If you have any problems with your private domain, then please contact support.
The Kolab Now development team has been working on updating Roundcube to version 1.6 on the platform for a while, and we are finally ready to push it. Therefore we hereby announce a service window for:
Wednesday 2025-01-22 @ 08:00 UTC (09:00 CEST)
The service window will last for an hour. Users can keep working, but there may be brief webmail interruptions during the period.
Users using the old ‘Larry’ skin might experience some short-comings and problems with that skin. Users with such issues can switch to use one of the two Kolab Now skins (Settings -> Preferences -> User interface -> Interface skin).
If you are one such user and you really want to make use of the old ‘Larry’ skin, then please contact support.
In fact, Please contact support with any questions or concerns in this context.
Due to the perils of simultaneous wordpress editing a crucial error snuck into the previous blogpost:
The newly required DNS entries are:
dkim1._domainkey CNAME dkim1._domainkey.kolabnow.com.
dkim2._domainkey CNAME dkim2._domainkey.kolabnow.com.
and NOT as the previous blogpost claimed
dkim1 CNAME dkim1.kolabnow.com.
dkim2 CNAME dkim2.kolabnow.com.
The previous blogpost has been corrected meanwhile.
Apologies, and merry Christmas!
Lately we have seen a few emails not being delivered to third parties and bounced emails with messages about failing DKIM signatures.
DKIM is a mechanism that allows a receiving party of emails to determine whether an email has indeed been sent by the party that is claimed to be the sender, thus protecting against forged sender email addresses. Kolab Now implemented DKIM signatures a long time ago, but so far we have always used the kolabnow.com domain as the sender domain, when sending an email from a custom domain. An example signature header would look like this (please note the ‘d= tag’):
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h=
content-type:content-type:content-transfer-encoding:message-id
:subject:subject:from:from:date:date:mime-version:received
:received:received; s=dkim20240523; t=1734354313; x=1736168714;
bh=mBUfOmuiUe6nDmAiAsHAHqpD0F+Gd9nJUF5Z5spFd8I=; b=bVuQog18XlAx
+YG8FhYOSvrHhdAyr2PUb/24fINK1zlqDGQS56ULJp87ogvG0NBK7G4dNG94Nhnc
GIOtTwZX5+NDpOFcQ6hldkxU7thO1734fWHA6kL8CXKWZ35IWnyyf7/DAp1rPIhe
wUM9td8SwP+/SOibhOOLPKf4Zz9I3qygVvnzMBMFXb0bTQbpV45ASLk0RsG8Q+jP
RBFlRboeqE5mCEgrg3q0i3ip2bGkhqAGzUTmqi0ckTvXltm+nCFpVSKlRy+lgrXY
PQyaK97xt3pUHX9sdcJFHyIDldU/cSWCcTsrQobk5J0UPj8Dlh2RIma/06K9EEcl
Bx27XRIK4Q==
This used to be fine paired with our DMARC policy recommendation, but recently some parties in the email ecosystem have become more stringent, often ignoring the DMARC policy, and rejecting email that is not domain aligned.
Going forward, we are planning to adjust our DKIM-Signature so that it will use your sender domain for alignment. This means, that for a user ‘doe@kolab.org’ the signature would look something like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolab.org; h=
content-type:content-type:content-transfer-encoding:message-id
:subject:subject:from:from:date:date:mime-version:received
:received:received; s=dkim20240523; t=1734354313; x=1736168714;
bh=mBUfOmuiUe6nDmAiAsHAHqpD0F+Gd9nJUF5Z5spFd8I=; b=bVuQog18XlAx
+YG8FhYOSvrHhdAyr2PUb/24fINK1zlqDGQS56ULJp87ogvG0NBK7G4dNG94Nhnc
GIOtTwZX5+NDpOFcQ6hldkxU7thO1734fWHA6kL8CXKWZ35IWnyyf7/DAp1rPIhe
wUM9td8SwP+/SOibhOOLPKf4Zz9I3qygVvnzMBMFXb0bTQbpV45ASLk0RsG8Q+jP
RBFlRboeqE5mCEgrg3q0i3ip2bGkhqAGzUTmqi0ckTvXltm+nCFpVSKlRy+lgrXY
PQyaK97xt3pUHX9sdcJFHyIDldU/cSWCcTsrQobk5J0UPj8Dlh2RIma/06K9EEcl
Bx27XRIK4Q==
and so ensuring that all outgoing emails from this sender are domain aligned. However, this will require that the DKIM key is available on your domain in DNS. We recommend that group managers (the owners of private
domains) set the following CNAMEs (both of them) in the DNS of their private domain:
dkim1._domainkey CNAME dkim1._domainkey.kolabnow.com.
dkim2._domainkey CNAME dkim2._domainkey.kolabnow.com.
This will delegate the actual DKIM public key to be managed by the kolabnow.com domain, who in turn will align the key with the sending domain as mentioned above.
We will enable domain-aligned signatures in the end of January 2025, at which point DKIM validation will fail if these above (CNAME) records are not set.
Please keep an eye on this blog for news and updates. We hope this will improve email deliverability.
PS: Thank you to the users who reported the issue, and delivered content for our investigations. You know who you are.