From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Duret-Lutz Newsgroups: gmane.emacs.bugs Subject: bug#50749: 28.0.50; three gnus-icalendar issues w.r.t. RFC5546 and party crashers Date: Thu, 23 Sep 2021 09:47:59 +0200 Message-ID: <87czozag28.fsf@lrde.epita.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7288"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Jan Tatarik To: 50749@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 23 09:50:55 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mTJVP-0001iS-CR for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 09:50:55 +0200 Original-Received: from localhost ([::1]:53846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTJVO-0007Xe-9k for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 03:50:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTJTa-0005uP-6u for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTJTZ-0001a4-Th for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:49:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTJTZ-0001Fp-S4 for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alexandre Duret-Lutz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Sep 2021 07:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 50749 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.16323832894751 (code B ref -1); Thu, 23 Sep 2021 07:49:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 23 Sep 2021 07:48:09 +0000 Original-Received: from localhost ([127.0.0.1]:52591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTJSj-0001EZ-8d for submit@debbugs.gnu.org; Thu, 23 Sep 2021 03:48:09 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:53032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTJSh-0001EQ-2e for submit@debbugs.gnu.org; Thu, 23 Sep 2021 03:48:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTJSf-0004gw-Q5 for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:48:06 -0400 Original-Received: from smtp.lrde.epita.fr ([91.243.117.225]:36590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTJSc-0000Zi-Cy for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:48:05 -0400 Original-Received: from goulash (goulash.lrde.epita.fr [192.168.101.25]) by smtp.lrde.epita.fr (Postfix) with ESMTPSA id 95A4342FF3; Thu, 23 Sep 2021 09:47:59 +0200 (CEST) Received-SPF: pass client-ip=91.243.117.225; envelope-from=adl@lrde.epita.fr; helo=smtp.lrde.epita.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:215170 Archived-At: --=-=-= Content-Type: text/plain Hi, At my job, some colleagues regularly send iCal invitations to mailing lists, and expect the recipients of these mailing lists to accept the invitation individually to indicate whether they are coming or not. The iCal invitations only lists the mailing list has an "attendee", not the all final recipients. When I receive such an invitation in Gnus, gnus-icalendar-event->gnus-calendar will tell me that "You are not listed as an attendee", and rightly so. However the code in gnus-icalendar-event:inline-reply-buttons prevents me from replying to the invitation by hiding the buttons. This is not desired: I still want to reply. RFC5546 specifically allows users not listed as attendee to reply to an invitation. Section 3.2.3 refers to those as a party crashers. Patch 0002 fixes this issue, which is the most important to me. In that patch, I was hesitant to remove the (lwarn...) message. I have tested that party crashing work with invitations sent to me (indirectly) by Outlook users. It does not work with Google Calendar, but I think the issue is on their side (someone else reported this on stackoverflow at https://stackoverflow.com/questions/66519665/ ) While working on that and discovering RFC5546 (which is completely new to me), I found two other issues in the gnus-icalendar code. One is that when replying to an iCal invitation, the mail should be sent to the "organizer" of that event, not to the sender of the email. This matters for forwarded invitations, for instance (and forwarded invitations in turn are related to supporting party crashers). Also some calendar systems can use dedicated email addresses to handle those events: Google Calendar, for instance, uses mail addresses in "...@group.calendar.google.com" for secondary calendars, and lists those as organizers of events in these calendars (but so far, mail replies to those event seems simply ignored, I'll try to find a place where to report that). Patch 0001 fixes the recipient of the invitation response. Finally, while displaying the mail sent for party-crasher responses (after patch 0002), I noticed that gnus-icalendar-event->gnus-calendar was still telling me that "You are not listed as an attendee", despite actually being the only attendee listed. This is because the code assumes that a missing ROLE parameter on the ATTENDEE line signifies NON-PARTICIPANT. That's not what RFC5546 specifies in section 4.2.1: the default value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not be enumerated. Patch 0003 fixes that. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-reply-to-the-organizer-of-an-ical-event.patch >From 04ed215bfa211620b6bd157fa745cd59f6a891ed Mon Sep 17 00:00:00 2001 From: Alexandre Duret-Lutz Date: Wed, 22 Sep 2021 16:30:21 +0200 Subject: [PATCH 1/3] reply to the organizer of an ical event RFC5546 specifies that participant status (accepted, tentative, declined) should be sent to the organizer of the event. That organizer is not necessarily the sender of the invitation; for instance Google Calendar uses custom email addresses to receive these notifications. * lisp/gnus/gnus-icalendar.el (gnus-icalendar-send-buffer-by-mail): Replace the default recipient of the reply by the organizer of the event. (gnus-icalendar-reply) Pass that organizer to the previous function. --- lisp/gnus/gnus-icalendar.el | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lisp/gnus/gnus-icalendar.el b/lisp/gnus/gnus-icalendar.el index b6e5e7f786..514feff284 100644 --- a/lisp/gnus/gnus-icalendar.el +++ b/lisp/gnus/gnus-icalendar.el @@ -847,10 +847,14 @@ gnus-icalendar-insert-button button t gnus-data ,data)))) -(defun gnus-icalendar-send-buffer-by-mail (buffer-name subject) +(defun gnus-icalendar-send-buffer-by-mail (buffer-name subject organizer) (let ((message-signature nil)) (with-current-buffer gnus-summary-buffer (gnus-summary-reply) + ;; Reply to the organizer, not to whoever sent the invitation. person + ;; Some calendar systems use specific email address as organizer to + ;; receive these responses. + (message-replace-header "To" organizer) (message-goto-body) (mml-insert-multipart "alternative") (mml-insert-empty-tag 'part 'type "text/plain") @@ -866,7 +870,8 @@ gnus-icalendar-reply (event (caddr data)) (reply (gnus-icalendar-with-decoded-handle handle (gnus-icalendar-event-reply-from-buffer - (current-buffer) status (gnus-icalendar-identities))))) + (current-buffer) status (gnus-icalendar-identities)))) + (organizer (gnus-icalendar-event:organizer event))) (when reply (cl-labels @@ -883,7 +888,7 @@ gnus-icalendar-reply (delete-region (point-min) (point-max)) (insert reply) (fold-icalendar-buffer) - (gnus-icalendar-send-buffer-by-mail (buffer-name) subject)) + (gnus-icalendar-send-buffer-by-mail (buffer-name) subject organizer)) ;; Back in article buffer (setq-local gnus-icalendar-reply-status status) -- 2.33.0 --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0002-allow-party-crashers-to-respond-to-ical-events.patch >From bd4dcf7273107d5855240ee6c9fad4eb9607bd33 Mon Sep 17 00:00:00 2001 From: Alexandre Duret-Lutz Date: Wed, 22 Sep 2021 16:38:42 +0200 Subject: [PATCH 2/3] allow party crashers to respond to ical events If an ical invitation is sent to a mailing list, the recipients are probably not listed as attendees. However there are legitimate situations where these unlisted (or indirectly listed) recipients are still expected to respond. RFC5546 allows that, calling those respondents "party crashers". * lisp/gnus/gnus-icalendar.el (gnus-icalendar-event:inline-reply-buttons): Display the response buttons even if the user was not found in the list of attendees, but change the labels of those buttons to make clear they are not explicitly invited. (gnus-icalendar-event--build-reply-event-body): Add an attendee line for the user in case one was not found. --- lisp/gnus/gnus-icalendar.el | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/lisp/gnus/gnus-icalendar.el b/lisp/gnus/gnus-icalendar.el index 514feff284..348da12db1 100644 --- a/lisp/gnus/gnus-icalendar.el +++ b/lisp/gnus/gnus-icalendar.el @@ -345,10 +345,16 @@ gnus-icalendar-event--build-reply-event-body (mapc #'process-event-line (split-string ical-request "\n")) + ;; RFC5546 refers to uninvited attendees as "party crashers". + ;; This situation is common if the invitation is sent to a group + ;; of people via a mailing list. (unless (gnus-icalendar-find-if (lambda (x) (string-match "^ATTENDEE" x)) reply-event-lines) (lwarn 'gnus-icalendar :warning - "Could not find an event attendee matching given identity")) + "Could not find an event attendee matching given identity") + (push (format "ATTENDEE;RSVP=TRUE;PARTSTAT=%s;CN=%s:MAILTO:%s" + attendee-status user-full-name user-mail-address) + reply-event-lines)) (mapconcat #'identity `("BEGIN:VEVENT" ,@(nreverse reply-event-lines) @@ -902,10 +908,16 @@ gnus-icalendar-sync-event-to-org (gnus-icalendar-event:sync-to-org event gnus-icalendar-reply-status)) (cl-defmethod gnus-icalendar-event:inline-reply-buttons ((event gnus-icalendar-event) handle) - (when (gnus-icalendar-event:rsvp event) - `(("Accept" gnus-icalendar-reply (,handle accepted ,event)) - ("Tentative" gnus-icalendar-reply (,handle tentative ,event)) - ("Decline" gnus-icalendar-reply (,handle declined ,event))))) + (let ((accept-btn "Accept") + (tentative-btn "Tentative") + (decline-btn "Decline")) + (unless (gnus-icalendar-event:rsvp event) + (setq accept-btn "Uninvited Accept" + tentative-btn "Uninvited Tentative" + decline-btn "Uninvited Decline")) + `((,accept-btn gnus-icalendar-reply (,handle accepted ,event)) + (,tentative-btn gnus-icalendar-reply (,handle tentative ,event)) + (,decline-btn gnus-icalendar-reply (,handle declined ,event))))) (cl-defmethod gnus-icalendar-event:inline-reply-buttons ((_event gnus-icalendar-event-reply) _handle) "No buttons for REPLY events." -- 2.33.0 --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0003-default-role-for-attendees-is-REQ-PARTICIPANT.patch >From 04e042d3ea9ba8760071e6fee4a648a54027138f Mon Sep 17 00:00:00 2001 From: Alexandre Duret-Lutz Date: Wed, 22 Sep 2021 22:28:28 +0200 Subject: [PATCH 3/3] default role for attendees is REQ-PARTICIPANT * lisp/gnus/gnus-icalendar.el (gnus-icalendar-event--get-attendee-names, gnus-icalendar-event-from-ical): When the ROLE property is missing from an ATTENDEE line, follow RFC5546 and default to REQ-PARTICIPANT. --- lisp/gnus/gnus-icalendar.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/gnus/gnus-icalendar.el b/lisp/gnus/gnus-icalendar.el index 348da12db1..a2ae2a9668 100644 --- a/lisp/gnus/gnus-icalendar.el +++ b/lisp/gnus/gnus-icalendar.el @@ -194,7 +194,9 @@ gnus-icalendar-event--get-attendee-names (caddr event)))) (cl-labels - ((attendee-role (prop) (plist-get (cadr prop) 'ROLE)) + ((attendee-role (prop) + ;; RFC5546: default ROLE is REQ-PARTICIPANT + (or (plist-get (cadr prop) 'ROLE) "REQ-PARTICIPANT")) (attendee-name (prop) (or (plist-get (cadr prop) 'CN) @@ -225,7 +227,8 @@ gnus-icalendar-event-from-ical (gnus-icalendar-event--find-attendee ical attendee-name-or-email))) (attendee-names (gnus-icalendar-event--get-attendee-names ical)) - (role (plist-get (cadr attendee) 'ROLE)) + ;; RFC5546: default ROLE is REQ-PARTICIPANT + (role (or (plist-get (cadr attendee) 'ROLE) "REQ-PARTICIPANT")) (participation-type (pcase role ("REQ-PARTICIPANT" 'required) ("OPT-PARTICIPANT" 'optional) -- 2.33.0 --=-=-=--