Message text and calendar event of accepted invite does not match identity used for reply
Categories
(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)
Tracking
(Not tracked)
People
(Reporter: Lorenz.F, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0
Steps to reproduce:
Whas asked to file a separate bug for this in comment 30 of bug 475886.
- Send a calendar invite from EMAIL_A to EMAIL_B.
- E-Mails to EMAIL_B are forwarded to EMAIL_C.
- Have a single writeable calendar configured to use the identity of EMAIL_B and configured to prefer sending e-mails via client
- Accept the invite which ads the calendar item to the only writable calendar and triggers the automatic sending of a response
Actual results:
Response is sent with "From: EMAIL_B", but the message text contains "EMAIL_C hat Ihre Termineinladung akzeptiert.", meaning "EMAIL_C has accepted your invite". Moreover, EMAIL_C is used in the calendar event of the response.
Expected results:
The sender using EMAIL_A should not be aware of EMAIL_C at all.
Response should contain the text "EMAIL_B hat Ihre Termineinladung akzeptiert."
EMAIL_C is also used in the calendar entry for the response, which should not be the case.
Furhter details on invite and response below:
Invite (anonymized using EMAIL_A, EMAIL_B, and EMAIL_C):
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Lastname Firstname:MAILTO:EMAIL_A
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=EMAIL_B:MAILTO:EMAIL_B
DESCRIPTION;LANGUAGE=de-AT:Wann: 30.01.2019 22:00:00\n--\n
UID:1fc45674-6d92-44ad-89b5-93f3165c7b98
SUMMARY;LANGUAGE=de-AT:Test
DTSTART;TZID=W. Europe Standard Time:20190130T220000
DTEND;TZID=W. Europe Standard Time:20190130T230000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190130T203700Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
Response (anonymized):
Content-type: multipart/mixed; boundary="Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)"
--Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)
Content-type: multipart/alternative;
boundary="Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)"
--Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8BIT
EMAIL_C hat Ihre Termineinladung akzeptiert.
--Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)
Content-type: text/calendar; method=REPLY; charset=UTF-8
Content-transfer-encoding: 8BIT
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REPLY
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20190130T203717Z
DTSTAMP:20190130T203717Z
UID:1fc45674-6d92-44ad-89b5-93f3165c7b98
SUMMARY:Test
PRIORITY:5
STATUS:CONFIRMED
ORGANIZER;CN=Lastname Firstname:mailto:EMAIL_A
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT;SENT-BY="mailto:EMAIL_B":m
ailto:EMAIL_C
DTSTART;TZID=Europe/Berlin:20190130T220000
DTEND;TZID=Europe/Berlin:20190130T230000
DESCRIPTION;LANGUAGE=de-AT:Wann: 30.01.2019 22:00:00\n--\n
CLASS:PUBLIC
TRANSP:OPAQUE
SEQUENCE:0
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
--Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)--
--Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)
Content-type: application/ics; name=invite.ics
Content-transfer-encoding: 8BIT
Content-disposition: attachment; filename=invite.ics
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REPLY
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20190130T203717Z
DTSTAMP:20190130T203717Z
UID:1fc45674-6d92-44ad-89b5-93f3165c7b98
SUMMARY:Test
PRIORITY:5
STATUS:CONFIRMED
ORGANIZER;CN=Lastname Firstname:mailto:EMAIL_A
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT;SENT-BY="mailto:EMAIL_B":m
ailto:EMAIL_C
DTSTART;TZID=Europe/Berlin:20190130T220000
DTEND;TZID=Europe/Berlin:20190130T230000
DESCRIPTION;LANGUAGE=de-AT:Wann: 30.01.2019 22:00:00\n--\n
CLASS:PUBLIC
TRANSP:OPAQUE
SEQUENCE:0
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
--Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)--
|
||
Comment 1•6 years ago
|
||
Thanks for filing this.
Out of interest: what is the use case to reply from inbox C instead of B if you have both of them configured?
(In reply to [:MakeMyDay] from comment #1)
Thanks for filing this.
Out of interest: what is the use case to reply from inbox C instead of B if you have both of them configured?
Hello
I have a similar problem. In my case it's the problem that the calendar of A expects an answer of B. So C will be added to the appointment and B never accepts.
That has to consequence then that if C now afterwards cancels also B is never removed from the calendar.
|
Reporter | |
Comment 3•6 years ago
|
||
(In reply to [:MakeMyDay] from comment #1)
Thanks for filing this.
Out of interest: what is the use case to reply from inbox C instead of B if you have both of them configured?
Actually, I do not want to reply with identity C, but with identity B - that's the bug. The use case why identity C gets involved is because I forward the mails of several e-mail addresses to inbox C in order to have a single inbox and not several. The mail addresses are from different organisations so that I do not have the option to reduce them.
Moreover, I can fully support comment 2, which is an even more serious consequence of the identity C showing up in the calendar event of the response than the issue with the message text of the response.
|
|
Reporter | |
Updated•6 years ago
|
|
||
Updated•4 years ago
|
| Comment hidden (me-too) |
|
||
Comment 5•3 years ago
|
||
I'm closing this as if I understand this bug correctly, bug 1702782 should have made it possible to send the reply with the correct identity. If I'm wrong or the issue still persist, please feel free to indicate.
Description
•