In the last few days, I’ve spent hours and hours configuring accounts on my private iPhone 6 running iOS 11 in order to attempt to nail down where its connection issues originate.
I’m happy to be able to tell you I seem to have nailed it down, and there’s a quick fix for it, that we can apply on the server-side.
Earlier this morning, at 04:38 UTC, one out of the twenty-two IMAP backends in production stopped serving its mail spool, showing Input/Output errors on its disk. Our Standard Operating Procedure is to examine log files, flush vm caches, stop the virtual machine, and start it back up again. This occurred at 05:48 UTC. The IMAP backend in question did not come back up cleanly.
We’re dropping our use of junkemailfilter.com “Spam DNS Lists”, because we have few positive experiences with it. Frankly, it is Junk.
We are preparing a transition from our current platform underpinning the support@kolabnow.com email address — based on OTRS — to a more up-to-date, feature-rich environment based on Phabricator.
For various reasons, we much anticipate this change. Not in the least we’ll have real-time notifications about new tickets, and user responses, and a few chat rooms — it’ll allow us to sort our workload better.
In a previous blog post, I have told you about our experimenting with TOTP-based two factor authentication. It proves functional in the Cockpit and in the Web Client, so we’re preparing the promotion to production.
Last month, we let you know a stricter DMARC policy was being applied to Kolab Now infrastructure. With a primary aim to increase our reputation and decrease phishing attempts from clearly false senders, we’ve since learned about some secondary effects;
If you’ve noticed our responses to support tickets or monitoring alerts is a little slower than usual, that’s because this is now the view from our office:
We’re currently experimenting with an implementation of TOTP-based 2 factor authentication, allowing our customers to use a second factor.
Until now, Kolab Now required its users to supply a username and a password. This is considered only a single factor, since the username is your email address and thus known to third parties.
Sometimes, we receive reports that either our general reputation has declined to the point that certain receiving parties will block some of the email sent through our infrastructure, and that bothers us — because it bothers our customers. This usually involves just a limited number of messages, but is annoying nonetheless.
Other times we receive reports of phishing. These usually do not include verbiage that is suitable for repeating in this here blog, as the reports reply to messages do not originate from us, usually refer to external, third party sites but are most importantly also not submitted through our infrastructure. We follow up these occurrences with abuse reports to web server hosting companies, email providers and through other associated channels, but responses are often not thorough and not quick.
While many of our customers have used collaborative editing, there’s certainly one aspect that could be improved; we’re seeing a lot of pending invitations to editing sessions, that apparently do not reach the intended recipient.
