Server side meeting invitations

[konmax]

Hi,

I would like to see the following new feature in Radicale:

Ability to handle server side meeting invitations (mail with ics attachment).

Some clients like Thunderbird/Lightning or most web clients can handle meeting invitations by themselves. But other clients like smart phones (e. g. Windows Phone or Android devices) are not able to send such invitations. It is possible to add persons to an event and the client (phone) does show a message that an invitation has been send but in reality no such mail was send out. This is very critical as the users thinks that all persons have been notified but this is not the case.

That is why I would like to see this feature in Radicale. It should be configurable in a way that it can be turned on/off in general, maybe even better per user and/or per client (e. g. do not send such invitations if the user is Jeff or if the client is Thunderbird but do send it out if the client is an Android device).

Konrad

[liZe]

There's a thread in the mailing about server-side invitations: http://librelist.com/browser//radicale/2014/4/8/meeting-invitations/.

[konmax]

What does milestone 2.0 mean? Does it mean that this might be part of Radicale v2.0? If so, this sounds like it will not be implemented in the next 10 years or so?!

Please do not get me wrong, but we are at 0.10 at the moment.

Thanks
Konrad

[untitaker]

I am not sure any "normal" CardDAV/CalDAV server implements this, so asking it from a supposed-to-be-lightweight server like Radicale is a bit much.

[konmax]

In the end it should not be more than sending out a mail using an and available external mail server with the meeting ics as an attachment, right? Guillaume himself said that this could be easily implemented in the attached mail thread.

Konrad

[mrgrain]

Setting a milestone for a certain features reflects its priority for the core developer team, in this case for the main developer. So, if you're waiting to get this implemented by Guillaume, you're probably right with your 10 years estimation. But, if YOU or someone else really needs this feature, why not start coding it by yourself NOW? This is how open source works. I'm quite sure a clean, tested and working solution will make its way into the main branch much earlier than 10 years. :)

[konmax]

Hmm, I'm in fact a developer, but I have never touched python so far and also not the caldav protocol. So it would better if someone with a bit more experience would implement this ;-)

Konrad

[srepmub]

sorry to post this link in two issues, but I think example code from a project which already implements most of this is much easier to understand than a collection of RFC's:

https://github.com/fruux/sabre-dav/tree/master/lib/CalDAV/Schedule

[nlincke]

Hey everyone? Are there any news regarding this topic? I really would love to send invites when i add some attendees to an appointment. Android does not send them... Clients like outlook or thunderbird do...

[srepmub]

some more comments here (after which I kind of lost interest in using radicale for my project, since it would need to support the apple stuff):

#34

[nlincke]

Thanks @srepmub . May I ask you what you have used insted? I realy like radicale but this is quite a drawback...

[srepmub]

we are looking into sabredav atm, but I'm not sure what the status there is, as I was only investigating radicale as an alternative.

[nlincke]

Thanks for the INFO. I would realy appreciate that at least invites are send...
Can some one give me a hint where inside the code is a good way to implement it? Just to speed up this... If i find time i would have a look...

[aimass]

Is there any update on this? I believe the simple solution is for each user to be able to add their SMTP server credentials and email account from which they want the invitations to be sent from and Radicale could do the sending through that configured SMTP. Of course technically, to be non-blocking Radicalle would have to send to a local MTA that then relays to the user's specific SMTP. I think the solution is pretty simple so not sure why it hasn't been addressed so far. I mean if you are using your own CalDAV server, chances are you are running your own SMTP or at least well-versed enough to configure it. From Radicale's perspective the change to support this is really simple so not sure why this hasn't been done to date (may it has?).

[Tntdruid]

sabre-io/Baikal#787

They updated Baikal whit Enable invitation plugin.

[aimass]

@Tntdruid I have tried Fruux and they seem to only be able to send email from their server directly, so the email is not from the user's domain but rather from fruux cloud or whatever. What I'm proposing is that it would be so simple for each user to provide their "from" email and corresponding SMTP so that if configured, Radicale could send out the invitations, updates and cancellations. Fruux (sabre.io) does this but only from a single SMTP account. Anyway, there is no well-though CalDAV product out there to integrate seamlessly with Apple iCal, and Apple's iCloud implementation does not send email outside of the iCloud ecosystem. Having researched this for my own company, I haven't been able to find a CalDAV service that can send email using the user's domain. I think it's valuable feature and for some reason it's still under the Really bad Idea category in this project.

[WiredWonder]

I just installed radicale and found this major shortcoming. I wish it was more widely documented.

Are there any solutions for Android/iOS clients? If not what other CalDAV servers are people using which support server side scheduling?

[nlincke]

Well I have a Nextcloud installation for this... But I would switch back in an instance... If they ever get this feature up and running...

[pbiering]

this can be somehow tricky regarding SPF and DKIM/DMARC, especially related to bounce handling

[nlincke]

Why? It should just use a normal mail account. It should not act as a Mailserver ..

[WiredWonder]

Just need to configure the correct SMTP relay.

[Goorzhel]

I want to implement this, assuming @tgy and @mkeen haven't already.

the simple solution is for each user to be able to add their SMTP server credentials and email account from which they want the invitations to be sent from and Radicale could do the sending through that configured SMTP

This is what I was thinking too, and @mkeen covered it in item 4 of his comment as well. Items 2 and 3 seem the hardest by my inexpert estimation. (FWIW I'm using Thunderbird and iOS Calendar and want this feature to be interoperable with both.)

RFC 6638 is the right tab to keep open in my browser, right?

[pbiering]

the simple solution is for each user to be able to add their SMTP server credentials and email account from which they want the invitations to be sent from and Radicale could do the sending through that configured SMTP

Are you sure that this is a good idea in modern IT world? Beside that such credentials need to be encrypted, one has to trust the "radicale" server installation 100%, otherwise credentials can be misused and overtake identity and also sniff all the e-mails as usually such credentials also allow access to mailbox.

Also "radicale" would need a mail spooling mechanism to deal with temporary failures on server side.

[Goorzhel]

One could document, and let the user assume, the risks of giving Radicale such credentials.

[pbiering]

It's not only about handover mailbox trust to a external system which is not designed for, it's also about mail handling (spooling, bounce handling and also handling of expired or no longer working credentials).

"radicale" is a lightweight card/caldav server and not a groupware. For such sophisticated solution look for a different product or create wrapping application around handling this complex requirement.

[konmax]

Hi All, Aren't you over-complicating things? Yes, Radicale would need valid SMTP credentials, but not for every user. It only needs ONE user+password combination to be able send out mail for all users and their invitations. Most other devices like my router, my Synology NAS, ... have a similar feature (and ask for SMTP credentials) to be able to send out admin notifications and mails for reasons. And Radicale would also not really need to care about mail failure handling. At least not in the first implementation of this feature. Since all that is provided by the SMTP server, Radicale would only need to worry about this in case the SMTP server is down (which is a very rare situation as mail servers are usually handled as "business critical" in a company).  Other mail clients (Radicale would be a mail client in this case) usually also not offer such features as well. And this could be always added later as a nice add-on feature... Lightweight or not, but these days almost all users (at least in our company) handle their calendars on mobile devices and what is a calendar good for, if you cannot invite, accept, decline, ... invitations?! All this is only possible with a full blown caldav client like Thunderbird. But that is not the future I would say. fwiw: I'm the original requestor of this feature 😉 Thank you very much! Konrad Am 03.07.2024 um 07:21 schrieb Peter Bieringer:

…

It's not only about handover mailbox trust to a external system which is not designed for, it's also about mail handling (spooling, bounce handling and also handling of expired or no longer working credentials). "radicale" is a lightweight card/caldav server and not a groupware. For such sophisticated solution look for a different product or create wrapping application around handling this complex requirement. — Reply to this email directly, view it on GitHub <#1394 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQMD4TFBKTDAN7JDFVLIVTZKOC4RAVCNFSM6AAAAABEEJHD6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNBTG44DG>. You are receiving this because you authored the thread.Message ID: ***@***.***>

--------------00fkgBQHhEDdAB9b3fuQFYZm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hi All,<br> <br> Aren't you over-complicating things? Yes, Radicale would need valid SMTP credentials, but not for every user. It only needs ONE user+password combination to be able send out mail for all users and their invitations. Most other devices like my router, my Synology NAS, ... have a similar feature (and ask for SMTP credentials) to be able to send out admin notifications and mails for reasons.<br> <br> And Radicale would also not really need to care about mail failure handling. At least not in the first implementation of this feature. Since all that is provided by the SMTP server, Radicale would only need to worry about this in case the SMTP server is down (which is a very rare situation as mail servers are usually handled as "business critical" in a company).  Other mail clients (Radicale would be a mail client in this case) usually also not offer such features as well. And this could be always added later as a nice add-on feature...<br> <br> Lightweight or not, but these days almost all users (at least in our company) handle their calendars on mobile devices and what is a calendar good for, if you cannot invite, accept, decline, ... invitations?! All this is only possible with a full blown caldav client like Thunderbird. But that is not the future I would say.<br> <br> fwiw: I'm the original requestor of this feature 😉<br> <br> Thank you very much!<br> <br> Konrad<br> <br> <div class="moz-cite-prefix">Am 03.07.2024 um 07:21 schrieb Peter Bieringer:<br> </div> <blockquote type="cite" ***@***.***"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <p dir="auto">It's not only about handover mailbox trust to a external system which is not designed for, it's also about mail handling (spooling, bounce handling and also handling of expired or no longer working credentials).</p> <p dir="auto">"radicale" is a lightweight card/caldav server and not a groupware. For such sophisticated solution look for a different product or create wrapping application around handling this complex requirement.</p> <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br> Reply to this email directly, <a href="#1394 (reply in thread)" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ACQMD4TFBKTDAN7JDFVLIVTZKOC4RAVCNFSM6AAAAABEEJHD6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNBTG44DG" moz-do-not-send="true">unsubscribe</a>.<br> You are receiving this because you authored the thread.<img src="https://github.com/notifications/beacon/ACQMD4R5CN43FCAT6CZKSEDZKOC4RA5CNFSM6AAAAABEEJHD6KWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAS65OO.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span>&lt;Kozea/Radicale/repo-discussions/1394/comments/9943783</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p> <script type="application/ld+json">[ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#1394 (reply in thread)", "url": "#1394 (reply in thread)", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script> </blockquote> <br> </body> </html>

--------------00fkgBQHhEDdAB9b3fuQFYZm--

[trentbuck]

FWIW, I run radicale, dovecot, and postfix on the same host. For me I think it would be sufficient to have radicale talk to standard interfaces (/usr/sbin/sendmail or smtp://localhost). Things like smartd and zfs-zed already submit emails unauthenticated to those paths.
Maybe invitations have more complicated requirements than just spoofing the body From? (e.g. spoofing the envelope FROM, which will run into SPF issues)? I know a fair bit about mail, but not much about caldav/carddav yet :-)

[pbiering]

For a "best case / fire+forget" solution one can think of using the local mail system on the server and let the server manage either direct send to Internet or feed to upstream relay with authentication or any other trust, envelope sender would be the system itself, body sender can be configured and is hopefully passing then and also a DKIM signature can be applied.

• envelope recipient will receive the e-mail and hopefully the body recipient will be recognized and accepted accordingly

But this is only a small piece...how should be handled all the error cases, at least coming into my mind:

• typo in e-mail address -> resulting in a bounce to envelope sender
  • what should pick up that bounce and deliver in user's mailbox?
  • "thick" client: mail is sent from user, bounce will be delivered to user
• rejected by anti spam / anti spoofing check on server side resulting in bounce to envelope sender
  • what should pick up that bounce and deliver in user's mailbox?
  • "thick" client: mail is sent from user, bounce will be delivered to user
• handling of actions on recipent side like accept/decline -> sent back to envelope or body sender (can depend on client)
  • what should pick up from where and automatic update the schedule with adjusted participant status - which security measurements are required here to avoid any misuse or flodding?
  • "thick" client: detect that e-mail is a response on an invitation and process accordingly after manual accept.

Can turn quickly complex and would turn "radicale" into some kind of groupware...

Would it be not better to put workforce into extension of "thin" clients by sending e-mail capability on behalf of the user itself either directly or via installed e-mail client.

[WiredWonder]

Nobody is talking about groupware except you. This thread is full of people who need Radicale to send invite emails to make it a more useful product. Can we focus on how to enable this?

There are many good examples of how applications use local mail or a configurable SMTP server to send email easily. Wordpress springs to mind. Email bounces are handled by the SMTP server, Radicale doesn't need to handle them.

I think the implementation method sounds great and am excited to be a tester when it's ready!

[pbiering]

Nobody is talking about groupware except you. This thread is full of people who need Radicale to send invite emails to make it a more useful product. Can we focus on how to enable this?

Even such "best case / fire+forget" option I would assume is not trivial to implement, not planned so far, anyhow this project is on maintenance level only at the moment.

New features need contribution, so one has to clone the repo and develop this optional extension and let test by everyone from this thread to check whether matching at least their expections. Once passed, a PR can be submitted.

[konmax]

Hi Peter, Administrating complex company networks (including locally hosted mail servers) for more than 20 years now, I still believe that this feature can be implemented and added to Radicale without all the complexity you are worried about. Almost all of the heavy lifting would be done by the already existing mail server (which could be hosted anywhere - no need to have a local one). The only thing Radicale needs to do is to hand over the invite mail to the mail server. Yes, for that it needs to be able to talk SMTP, but that's about it. To do that, id needs a mail FROM address (the organizer) and one or many mail TO address (the invited people). And addition Radicale needs a valid SMTP username/password combination which would be a hard coded part of the configuration (no need to have all credentials from all users). So everything should be available to send out such invites. Everything else you mentioned down below is then handled by the mail server. Typos (and any other kind of errors you mentioned) would be reported back to the organizers mail inbox, accept/decline messages would also be placed into the organizers mail inbox and can be handled later by any exiting mail client like Thunderbird or even mobile phones. Radicale wouldn't even be involved in all that (except dealing with CalDav requests like it does today). Everything else is taken care of by the mail server... Let me know your thoughts. Konrad Am 03.07.2024 um 19:51 schrieb Peter Bieringer:

…

For a "best case / fire+forget" solution one can think of using the local mail system on the server and let the server manage either direct send to Internet or feed to upstream relay with authentication or any other trust, envelope sender would be the system itself, body sender can be configured and is hopefully passing then and also a DKIM signature can be applied. * envelope recipient will receive the e-mail and hopefully the body recipient will be recognized and accepted accordingly But this is only a small piece...how should be handled all the error cases, at least coming into my mind: * typo in e-mail address -> resulting in a bounce to envelope sender o what should pick up that bounce and deliver in user's mailbox? o "thick" client: mail is sent from user, bounce will be delivered to user * rejected by anti spam / anti spoofing check on server side resulting in bounce to envelope sender o what should pick up that bounce and deliver in user's mailbox? o "thick" client: mail is sent from user, bounce will be delivered to user * handling of actions on recipent side like accept/decline -> sent back to envelope or body sender (can depend on client) o what should pick up from where and automatic update the schedule with adjusted participant status - which security measurements are required here to avoid any misuse or flodding? o "thick" client: detect that e-mail is a response on an invitation and process accordingly after manual accept. Can turn quickly complex and would turn "radicale" into some kind of groupware... Would it be not better to put workforce into extension of "thin" clients by sending e-mail capability on behalf of the user itself either directly or via installed e-mail client. — Reply to this email directly, view it on GitHub <#1394 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQMD4XUYZCAAQIHOAMPB73ZKQ2Z5AVCNFSM6AAAAABEEJHD6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNJRGEYDI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

--------------Bo3ix8SM1LfmtdIkWKplUzGd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hi Peter,<br> <br> Administrating complex company networks (including locally hosted mail servers) for more than 20 years now, I still believe that this feature can be implemented and added to Radicale without all the complexity you are worried about. Almost all of the heavy lifting would be done by the already existing mail server (which could be hosted anywhere - no need to have a local one). The only thing Radicale needs to do is to hand over the invite mail to the mail server. Yes, for that it needs to be able to talk SMTP, but that's about it. To do that, id needs a mail FROM address (the organizer) and one or many mail TO address (the invited people). And addition Radicale needs a valid SMTP username/password combination which would be a hard coded part of the configuration (no need to have all credentials from all users). So everything should be available to send out such invites. Everything else you mentioned down below is then handled by the mail server. Typos (and any other kind of errors you mentioned) would be reported back to the organizers mail inbox, accept/decline messages would also be placed into the organizers mail inbox and can be handled later by any exiting mail client like Thunderbird or even mobile phones. Radicale wouldn't even be involved in all that (except dealing with CalDav requests like it does today). Everything else is taken care of by the mail server...<br> <br> Let me know your thoughts.<br> <br> Konrad<br> <br> <div class="moz-cite-prefix">Am 03.07.2024 um 19:51 schrieb Peter Bieringer:<br> </div> <blockquote type="cite" ***@***.***"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <p dir="auto">For a "best case / fire+forget" solution one can think of using the local mail system on the server and let the server manage either direct send to Internet or feed to upstream relay with authentication or any other trust, envelope sender would be the system itself, body sender can be configured and is hopefully passing then and also a DKIM signature can be applied.</p> <ul dir="auto"> <li>envelope recipient will receive the e-mail and hopefully the body recipient will be recognized and accepted accordingly</li> </ul> <p dir="auto">But this is only a small piece...how should be handled all the error cases, at least coming into my mind:</p> <ul dir="auto"> <li>typo in e-mail address -&gt; resulting in a bounce to envelope sender <ul dir="auto"> <li>what should pick up that bounce and deliver in user's mailbox?</li> <li>"thick" client: mail is sent from user, bounce will be delivered to user</li> </ul> </li> <li>rejected by anti spam / anti spoofing check on server side resulting in bounce to envelope sender <ul dir="auto"> <li>what should pick up that bounce and deliver in user's mailbox?</li> <li>"thick" client: mail is sent from user, bounce will be delivered to user</li> </ul> </li> <li>handling of actions on recipent side like accept/decline -&gt; sent back to envelope or body sender (can depend on client) <ul dir="auto"> <li>what should pick up from where and automatic update the schedule with adjusted participant status - which security measurements are required here to avoid any misuse or flodding?</li> <li>"thick" client: detect that e-mail is a response on an invitation and process accordingly after manual accept.</li> </ul> </li> </ul> <p dir="auto">Can turn quickly complex and would turn "radicale" into some kind of groupware...</p> <p dir="auto">Would it be not better to put workforce into extension of "thin" clients by sending e-mail capability on behalf of the user itself either directly or via installed e-mail client.</p> <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br> Reply to this email directly, <a href="#1394 (comment)" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ACQMD4XUYZCAAQIHOAMPB73ZKQ2Z5AVCNFSM6AAAAABEEJHD6KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNJRGEYDI" moz-do-not-send="true">unsubscribe</a>.<br> You are receiving this because you authored the thread.<img src="https://github.com/notifications/beacon/ACQMD4U3VI5MH3WX3ZVUUZLZKQ2Z5A5CNFSM6AAAAABEEJHD6KWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAS7LYA.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span>&lt;Kozea/Radicale/repo-discussions/1394/comments/9951104</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p> <script type="application/ld+json">[ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#1394 (comment)", "url": "#1394 (comment)", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script> </blockquote> <br> </body> </html>

--------------Bo3ix8SM1LfmtdIkWKplUzGd--

[pbiering]

Like written above, a developer need to be found to check how this can be implanted and create a prototype. I still don't believe that this is that easy as some expect...."radicale" is potentially simply to lightweight for this as it is only a file based DAV storage with CAL/CARDdav "extension" on top....there is neither a database nor a state machine on server side. It's simply storing and serving the files in directories. Not even user related properties can be stored somewhere so far.

[pbiering]

btw for the prototype:

• there is already a hook suport on on every storage write -> one can try this
• or check whether the "rabbitmq" hook can be cloned+adjusted for such actions

[theeddie]

No-one has stepped up and done this yet?

[pbiering]

Not that I'm aware about.

[theeddie]

Dang, this is the only feature keeping me from moving over

[choucavalier]

i wish i had the time but i don't :/

[pbiering]

but it is not that easy imho as one thought of...beside handling all the e-mail send+catch-bounce issues also the tracking about to which invitee the invitation was already sent can be a challenge - imho for proper tracking either a database or manipulation of the ICS file is required for flagging.

[nlincke]

Can some one give me a hint how to react on the event of a Calendar entry create/Update/delete and how to inject some scripts? I am happy to look in to the mail sending part - at least on an prototype level. I just do not have time to dig in to everything at the moment.

[mkeen]

I'd go back and read a bunch of the ideas from early in this thread. I wish I would have gotten around to implementing this but things just got busy with life. Would be a game changer to have this IMO.

(I think I was onto something here: #1394 (comment))

[pbiering]

@nwithan8 contributed a hook for sending e-mail which is now merged to upstream

#1808

Please give a try whether this supports your requirement

[jfly]

Neat! @nwithan8, does this new feature handle attendance replies? (Yes/No/Maybe)

[nwithan8]

Neat! @nwithan8, does this new feature handle attendance replies? (Yes/No/Maybe)

No, this is just outbound emails, it does not handle incoming replies.

[abbbi]

hi,

Thanks for the e-mail hook. Im not sure which calendar apps people use, but using a shared family calendar with IOS based devices, the calendar app does not allow to add attendees to an event if not used with icloud. Not sure about andriod.

my take on this was to modify the mail hook to include a default atteendee list which gets notified no matter if the attendee is listed in the event or not. This way both me and my wife get proper notification.

I wonder if it would useful for others if the config file provided a "default_attendees=" setting where one could specify a list of mail addresses that is notified no matter whats set in the event options? (or even on a per-calendar setting in the .props file?)