Open Bug 475886 Opened 11 years ago Updated 5 months ago

When accepting/declining an invitation, generated mail should use the account the invite was received on

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Lightning 0.9
defect
Not set

Tracking

(Not tracked)

People

(Reporter: kkauper, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: 2008091719

In Thunderbird, I have a single Lightning calendar, but three email accounts, say A, B & C. The calendar is configured with its "email" set to A, in the calendars properties dialog. 

Whenever I receive an event invitation in Lightning, and attempt to accept/decline the invitation, the accept/decline messages are always sent via email A, *even when the invitation is received via email B or C* -- this is not the behaviour I'd expect, nor what the event organiser would expect, since the reply is coming from a different account.

Accept/decline messages should be sent via the email account via which the invitation was received.

Reproducible: Always

Steps to Reproduce:
1. Setup two email accounts in Thunderbird (A & B) and one calendar with its email set to A.
2. From a different account, send a meeting invite to the B account.
3. Accept the invitation.
4. Observe from which account the reply email was sent.
Actual Results:  
Accept email sent via account A

Expected Results:  
Accept email sent via account B
Version: unspecified → Lightning 0.9
(In reply to comment #0)
> Whenever I receive an event invitation in Lightning, and attempt to
> accept/decline the invitation, the accept/decline messages are always sent via
> email A, *even when the invitation is received via email B or C* -- this is not
> the behaviour I'd expect, nor what the event organiser would expect, since the
> reply is coming from a different account.
IMO this is rather an enhancement than a bug: The transport protocol (iMIP) is independent of the iTIP protocol used for scheduling, i.e. the iTIP messages' ORGANIZER and ATTENDEE properties are relevant.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Component: General → E-mail based Scheduling (iTIP/iMIP)
QA Contact: general → email-scheduling
Duplicate of this bug: 570461
Severity: enhancement → normal
Duplicate of this bug: 882630
Duplicate of this bug: 1297874
Duplicate of this bug: 609357
Duplicate of this bug: 876463
Duplicate of this bug: 589081
Wouldn't implementing this on the attendee side be as simple as looking at the invitation recipient address and using that in the response? No new UI needed.

If we're also talking about organizing new events, then that's obviously a bit more involved, since there would have to be a UI element for choosing the desired email identity to use as the organizer's email.

But fixing this even just for attendees would be a big step forward. And strictly speaking that's how the bug is currently defined.
> since there would have to be a UI element for choosing the desired email identity to use as the organizer's email.
There should not be any UI to select the email responding the invitation. This should be automatic. If I'm sending an invitation, why would another person RSPV it? it doesn't make sense.
(In reply to Alejandro from comment #25)
> There should not be any UI to select the email responding the invitation.

Read my comment more closely. That's exactly what I'm saying.

> If I'm sending an invitation, why would another
> person RSPV it?

I'm not sure what you mean. If I'm the one organizing the event, i.e., sending out invitations, then I should be able to choose which one of my email addresses appears as the sender of the invitation. My calendar is primarily associated with my personal email address, but if I'm setting up a work-related meeting, I would like attendees to see my corporate identity as the organizer.
Duplicate of this bug: 1395614
Duplicate of this bug: 1393012

Just figured out that even if one sets the mail identity of the calendar to the address to which the invite was sent, the message text in the message response will still contain the default mail address while the FROM address will be the one configured in the calendar settings. This means that setting the calendar identity to the correct address is not a complete workaround as the default identity will still be revealed.

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

I can't believe this bug is 10 years old already.

(In reply to [:MakeMyDay] from comment #30)

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

Is there a separate Bug for this? I have a similare Problem...

(In reply to edlly from comment #32)

(In reply to [:MakeMyDay] from comment #30)

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

Is there a separate Bug for this? I have a similare Problem...

Yes, created bug 1524055 as suggested in comment 30.

Still running into this bug in 2019. This is a privacy issue for me, as accepting requests sent to one identity is leaking information about the calendar's identity.

(In reply to Bram from comment #34)

Still running into this bug in 2019. This is a privacy issue for me, as accepting requests sent to one identity is leaking information about the calendar's identity.

Not just for you, this is a privacy issue, plain and simple. And having a bug like this for 11 years doesn't look good. I know this is an open source project and some people do this on their free time, but such issues should have priority over others.

I simply stopped responding to calendar invites from TB on my business email because it replies with my personal email and it makes me look ridiculous. I always reply from gmail directly. Maybe now that TB team has grown bugs like this will be solved? One can hope.

It's not even solely a privacy issue. It's a functional one as well. On a lot of these invitation systems, if you reply from a different address that wasn't invited, your confirmation won't be accepted.

(In reply to Phil Stracchino from comment #37)

It's not even solely a privacy issue. It's a functional one as well. On a lot of these invitation systems, if you reply from a different address that wasn't invited, your confirmation won't be accepted.

which makes total sense! So let's hope they take this one for the next release, 11 years i way to long for an issue to be open

I've that bug using caldav calendars setup not related to any of my currents emails account.
Using Thunderbird 60.7.0 / Ligtning version 6.2.7

  • Calendar calendar1 properties

  • Thunderbird email account1

Received event invitation in mailbox account1 accepted and registered in calendar1. The outgoing email contains mismatches between the calendar account username (user@server1.tld) and the account email adress (user@server2.tld). See the following email source :

MIME-version: 1.0
From: Username <user@server2.tld>
Message-ID: <xxxxx-xxxx-xxx@server2.tld>
To: other.user@server2.tld
Date: Tue, 04 Jun 2019 14:37:14 +0200
Subject: =?UTF-8?Q?Event_Invitation_Reply_?=
 =?UTF-8?Q?=28Accepted
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

user@server1.tld has accepted your event invitation.


--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

[...]

ATTENDEE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT;SENT-BY="mailto:user@server2.tld":mailto:user@server1.tld

[...]
You need to log in before you can comment on or make changes to this bug.