The Horde Project released Horde 6 and IMP 7 a few months ago. It came with all the rough edges, latches for features already prototyped, unfinished work and notably it came without a lot of buzz. We barely updated the website. The former Horde LLC transitioned social media accounts to the new stewards of the project but we decided to keep volume low for now. Subscribers haven’t heard much from Horde over the last few years. It wouldn’t be appropriate to spam them with too much blurb now.

Also, it’s summer. I am looking at the mountains of Southern Tyrol (Italy), my feet relaxing from today’s long hike and a glas of wine at the ready. It’s time to zoom out a bit.

What is the next IMP?

Horde 6 had a coordinated initial release of all must-have apps and libraries. Many others are pending as I feel releasing them as “stable” without further work doesn’t make much sense. In practice, Horde Base 6, Imp 7, Kronolith 5 all came out around the same time. But IMP is now at 7.2 and Base is at 6.2 – we released new features liberally as they became ready. The team does however target a coordinate Framework 6.1 release for later this year. This means there are some types of features which need special attention and could irritate the unsuspecting admin. This is a learning experience – the only kind of BC break we allow for framework minor releases is raising the minimum PHP version to the lowest currently supported. If we released in Q4/2026 this would mean PHP 8.2 but if we released in Q1/2027 it would mean PHP 8.3. I cannot tell you if this is going to be IMP 7.2 or IMP 7.5 – but it will be the coordinated framework release.

There’s a brand new beat and a brand new song

The ecosystem has changed a lot since Horde 5. Security, Data Protection, email provider landscape – Horde wants to acknowledge this development. Running your own calendar and contacts infrastructure, file server etc doesn’t necessarily mean you run your own email service. You can and you should – though dovecot and postfix aren’t exactly friendly and their latest BC-breaking updates taught the team a lot about how we should better not do it.

But even if your organization email inbox pales besides your use of gmail or other providers, Horde wants to make things work for you. This means OAuth based mailbox authentication but it also means supporting the latest IMAP standard (IMAP4rev2 if you wonder). It also means changing the way our mail tool, imp, works at its core

Every generation has its way

A while ago our very active collaborators at Université de Picardie Jules Verne provided some patches which shoehorned XOAUTH support into Horde’s established identity and authentication system. Sadly I had to push back a little. While their approach worked very well, it only made sense in a very narrow type of Horde deployment. The team wanted to get federated identity right rather than cram it into a pre-existing framework. It took more time than we originally assumed as we wanted to finish some other work first.

horde/imap_client with IMAP4rev2

In the next few days we are going to release a new version of horde/imap_client which comes with IMAP4rev2 support and also supports the Unicode extension for IMAP4rev1. It is essentially a rewrite based on modern PHP 8 capabilities. We factored out horde/sasl as we had multiple incomplete SASL implementations attached to our IMAP, SMTP and MANAGESIEVE components. We also based the new library on a modernized version of horde/socket_client. With so much change stacked on top of each other, we expect some new bugs and problems. The new stack isn’t active by default. It’s hidden behind a feature switch in the upcoming generation of IMP.

When rules get in the way

We will not force this new concept on admins. They will get a switch – traditional mode, proven code vs the new model and the new features. At some point, let’s call it Horde 7, we will drop the old model and provide upgrading instructions. But this is not today.

What’s this same old song?

So what’s wrong with the old model? IMP tied a concept of “application authentication” to a user’s ability to log into his primary mailbox. This has all sorts of unwanted consequences, including way too many points in the code forcing an IMAP login (slow) just to prove we still can. It also means support for any additional mailboxes is tacked-on and not really native to IMP.

What’s the new beat?

With the new mode, IMP doesn’t do its own application-level authentication. It moves credential checks to the mailbox level. So you can have IMP but have no primary mailbox. You can use IMP to read and write your google mail or whatever your external mail provider is. That’s the plan, it’s still in the works.

Mailbox Providers – Most importantly your organization’s primary email provider. These are now separated from IMP’s core into their own entities in a similar way as the Federated Login providers we introduced in Horde 6.0 already.

If this works out well we will expand the concept to OAUTH based CalDAV (Calendar Events and Tasks) and CardDAV (Addressbook entries).

Conclusion

The coordinated Framework 6.1 release will bring a deluge of new code and hide it behind a set of feature switches. Administrators can opt in to the new experience or keep their tried and tested model until we cut off with Framework 7 at some yet to be decided point.

But first let’s have some vacation time.