Replies: 35 comments 6 replies
-
|
There's a thread in the mailing about server-side invitations: http://librelist.com/browser//radicale/2014/4/8/meeting-invitations/. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. :) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
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): |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @srepmub . May I ask you what you have used insted? I realy like radicale but this is quite a drawback... |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the INFO. I would realy appreciate that at least invites are send... |
Beta Was this translation helpful? Give feedback.
-
|
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?). |
Beta Was this translation helpful? Give feedback.
-
|
They updated Baikal whit Enable invitation plugin. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great @mkeen |
Beta Was this translation helpful? Give feedback.
-
|
@mkeen i think there is less of a need for shared calendar status and many email clients can handle meeting responses their own (the client updates the vcalendar entry and uploads to the caldav server) - maybe start with simple construction of a properly formatted invitation that is sent outbound to recipients though an smtp server? PS also happy to beta test |
Beta Was this translation helpful? Give feedback.
-
|
I also would love to help testing 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
According to the main page radicale has reached 3.0.0 :) Do we have ServerSide Invetations then? Has anyone tested this feature... |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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...
|
Beta Was this translation helpful? Give feedback.
-
|
this can be somehow tricky regarding SPF and DKIM/DMARC, especially related to bounce handling |
Beta Was this translation helpful? Give feedback.
-
|
Why? It should just use a normal mail account. It should not act as a Mailserver .. |
Beta Was this translation helpful? Give feedback.
-
|
Just need to configure the correct SMTP relay. |
Beta Was this translation helpful? Give feedback.
-
|
I want to implement this, assuming @tgy and @mkeen haven't already.
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
One could document, and let the user assume, the risks of giving Radicale such credentials. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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><Kozea/Radicale/repo-discussions/1394/comments/9943783</span><span>@</span><span>github</span><span>.</span><span>com></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--
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
But this is only a small piece...how should be handled all the error cases, at least coming into my mind:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 -> 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
-> 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><Kozea/Radicale/repo-discussions/1394/comments/9951104</span><span>@</span><span>github</span><span>.</span><span>com></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--
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
btw for the prototype:
|
Beta Was this translation helpful? Give feedback.
-
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
Beta Was this translation helpful? Give feedback.
All reactions