This was a pleasingly simple problem to solve.

Background

Earlier this year, I moved away from the SOGo groupware tool for calDAV and cardDAV (i.e. calendar and contacts server).

SOGo was - for whatever reason - just insufficiently reliable, with sync regularly ceasing to work in ways that required me to poke the SOGo database.

(I’d like to move away from SOGo completely, but it provides a pretty friendly way of managing out of office / automatic vacation email, so, for now, I’m keeping SOGo around for that.)

I considered two options for a replacement calDAV/cardDAV server: radicale, and using the functionality within our existing Nextcloud installation.

Since this is an internal-only service, with no need for external access, I went with the Nextcloud approach. I was already using Nextcloud, so it was a relatively small change to enable this functionality.

Client-wise, setting it up in Thunderbird was more of a pain than I had expected, for reasons that I’ve not dug into, but the impact was that I had to set up the accounts within Thunderbird with the wrong credentials, and then change them for the right credentials, before they would work. Annoying, but once I had worked out what to do, I did it, and it worked (and still works).

Testing was fine: I could send and receive calendar invitations, and my calendar and contacts were kept in sync across multiple devices.

But there was a problem I had not spotted.

The problem

Someone mentioned to me the other day that, while I had successfully sent them a calendar invitation, and they were able to accept it, there was a button within the invitation text itself that they could click to confirm attendance, and that that did not work.

There were three issues:

• why was there an html email at all;
• why was there a button/link to confirm attendance; and
• why did it not work

I narrowed it down quite quickly.

There was indeed that button (which I don’t want at all), but the more significant issue is that required that the recipient could communicate with the Nextcloud server via https.

And they could not, because our Nextcloud server is not accessible to the world.

Why was this happening?

In short, this is a Nextcloud thing, and not a thing that I wanted.

It was compounded by Thunderbird’s default for calendars, to prefer server-side calendar scheduling.

In other words, when I created an appointment in Thunderbird and added an attendee to it, it was my calDAV server - Nextcloud - that was sending the meeting request / calendar invitation, not my client.

Nextcloud uses an html email for this, with a button to confirm acceptance.

I should have picked up on this sooner, but, for whatever reason, did not.

I didn’t want to make my Nextcloud instance publicly available for the purpose of making the button work.

From some basic searches online, it appears that there is no way to ready way to change the template used by Nextcloud to generate the email, to enable me to set plain-text only and to remove the link “confirm acceptance” link.

So I needed to stop that email from being sent.

The fix

The fix was to use Thunderbird for sending the invitation, not Nextcloud.

To do this, I went into the “Properties” of the particular calendar, and set “Prefer client-side email scheduling” to true (i.e. put a tick in the box).

That sorted it.

Now, when I create a calendar invitation and send it, it is sent via Thunderbird, as a plain text email, which does not have a link to confirm acceptance, and it does not require exposing my Nextcloud instance to the world.