User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

version 60.7.2 (32-bit)

I have 2 emails accounts - setup on my Thunderbird.
now i have received invitation email to account #2,
but when clicked on the ACCEPT
It sent the confirmation through account #1 !!!
very weird!

Actual results:

version 60.7.2 (32-bit)

I have 2 emails accounts - setup on my Thunderbird.
now i have received invitation email to account #2,
but when clicked on the ACCEPT
It sent the confirmation through account #1 !!!
very weird!

Expected results:

account #1 is not relevant.
and should not be related.

This isn't a report of a security incident, clearing flag.

Confirming.

STR

1. Setup:

• TB default account: default@foo.bar
• secondary (non-default) account: attendee@bar.baz
• no special calendar setups

2. receive invite.ics for an email address which is not the default account in Thunderbird (ATTENDEE;RSVP=TRUE;CN=John Doe;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:attendee@bar.baz)
3. click "Accept" in message reader preview of default@foo.bar account which received the invitation

Actual Result

• invite reply is sent using default@foo.bar as sender (default account's email)
• default@foo.bar is added as a confirmed attendee (but was not invited)
• attendee@bar.baz is not confirmed to attend, and no obvious workaround to change that
• this is a privacy issue with enterprise relevance

Expected Result

• sent reply using attendee's email if existing as an identity (or at least the receiving account, warn on mismatch or let user choose): attendee@foo.bar
• do not add unrelated attendees
• confirm only the invited attendee (attendee@foo.bar)

Maybe we should use [enterprise] in the whiteboard. There are a few bugs that have it set, only a few in TB though: https://mzl.la/2UpwBlb

Sorry, mid-air-collision

List of similar/duplicate bugs.

Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:
Open Calendar (left) sidebar, context-click Properties, Email. So the reply e-mail account will be chosen based on that. For example, if you accept into Klaus' calendar, the reply comes from Klaus, if you accept into Heinz' calendar, Heinz will reply. Wow, I didn't know that.

The "Would you like to send out notification E-Mail now" prompt was removed in bug 463402. Maybe we should reintroduce a prompt/warning with this wording or similar: Send confirmation using foo@bar.com associated with calendar XYZ while the invitation was received by baz@fred.com?

Paul, once you find the time, this and the bugs in "see also" would be useful to get resolved. Besides privacy it's also annoying for the recipient because they get wrong data into their event.

(In reply to Magnus Melin [:mkmelin] from comment #11)

Paul, once you find the time, this and the bugs in "see also" would be useful to get resolved. Besides privacy it's also annoying for the recipient because they get wrong data into their event.

Paul is gone (assigned to nobody)... This should be fixed as it remains a serious issue for everyone involved...

Nobody in line atm.

(In reply to Jorg K (CEST = GMT+2) from comment #9)

Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct, the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):

1. send with email address associated to receiving calendar (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2. if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using attendee address (foo@bar.com; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3. If 1) and 2) fail, fall back to using TB's default account address for sending (which may or may not be foo@bar.com - this bug).

To fix this bug, I think 1) and 2) need to be swapped.

• first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
• then use the address associated to receiving calendar
• if all else fails, use default address

Also, before sending with anything else but the attendee's email address, Thunderbird must ask for confirmation! (privacy)

Expecting users to create a calendar for each of their accounts/identities does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)

Is there an identity configured for the calendar, the event was stored into
when accepting the invitation? Was that different then A?

For sending replies the email identity configured in the respective calendar
properties (available from context menu in the calendar list in the
calendar/task view tab) is primarily used. If there's none, Lightning tries
to make a guess based on the email recipient and ultimately falls back as a
last resort to the system default email account. The latter is usually the
case if the invitation was sent bcc or to a serverside resolved email list,
so the email addresses configured in TB email identities cannot be resolved.

If you want to deal with email invitations and be safe to that regard, it is
recommended to configure exactly one writable calendar for each TB email
identity.

The above analysis does not seem to meet all cases. I receive the .ics file from client X on (say) the 3rd of 5 email addresses . I save the .ics file to my computer and import it to my Google calendar via Firefox. I then click on "Accept" but that respose returns to clinet X from the 1st email address in TB. That IS a privacy issue and very confusing to client X who knows nothing about the business I conduct on email address 1.

(In reply to jules romsey from comment #16)

The above analysis does not seem to meet all cases. I receive the .ics file from client X on (say) the 3rd of 5 email addresses.

Jules, is your own attendee address (your address in the invite from client X) the same as the address receiving the invite in Thunderbird?

I save the .ics file to my computer and import it to my Google calendar via Firefox.

You really mean Firefox (not Thunderbird), right?

I then click on "Accept"

That's on the invite message in Thunderbird now, right?

but that respose returns to client X from the 1st email address in TB.

Yes, your 1st address is TB's default account, and that's used as third/last fallback per comment 14.

That IS a privacy issue and very confusing to client X who knows nothing about the business I conduct on email address 1.

It has not been disputed that this is a privacy issue, and this bug has the privacy keyword set.
My comment 14 both describes the current algorithm (from someone's informed description) and explores an idea for rectifying that.

In reply to comment 17:
The email containing the attached .ics file comes to me as my email address 3. I receive it in Thunderbird.
I manage my Google Calendar via FireFox (83.0) when on my laptop - where I receive my Thinderbird emails.
So I save as / detach the .ics file and go to FFox Google Calendar tab and import the .ics file to my Google calendar.
If I then go back to TB and click Accept then the result goes back to the invite sender as coming from my email address 1.

Having read your comment 14 twice I think I agree with your suggested order of fixing the process in TB, except that in my case the fix can only use either the address on the invite email or a default address as I am not using TB's calendar (at least not conciously - the receiving calendar address is not germain).

Lasana, please have a look. It's probably worth reading through the see-also-bugs.

(In reply to Magnus Melin [:mkmelin] from comment #19)

Lasana, please have a look. It's probably worth reading through the see-also-bugs.

Hi Lasana, you may want to include my comment 14 into your reading, where I've tried to map a possible approach for fixing this starting from expert comments. I'm not a calendar expert, so it's very possible that there's more to it. See-also bugs are duplicate candidates, plus there's a couple of duplicates.

This looks less like something to fix and more like a limitation of the design. As mentioned in bug 1468959 comment 1, and by Thomas, the email address to send the response to is sourced form the calendar properties and falls back to the default identity if not configured.

https://searchfox.org/comm-central/source/calendar/base/modules/utils/calItipUtils.jsm#1253
https://searchfox.org/comm-central/source/calendar/base/modules/utils/calItipUtils.jsm#1987

I could probably change this to use the receiving account instead of the default one but it seems to me better UX would be to not decide this on the user's behalf. At least for users with multiple accounts set up. Maybe a button to specify "Accept As" that allows identity selection in the imip bar but that may be a bit more involved.

"the email address to send the response to is sourced form the calendar properties " WHY?
Surely the correct solution is to send the acceptance / rejection etc to the Reply Address of the incoming email containing the invitation from the email account where it arrived? The solution has nothing to do with use of TB's calendar - which I have chosen not to use and is "not set up" on my system. As pointed out before, I use Google Calendar via FFox. I still need to click on ACCEPT and have that return to the sender with the FROM address indicating my email address which received it - not the 1st alpabetically of the 5 addresses I use. The users don't want to mess around with additional clicking on buttons.

Lasana, do you know more about the relationship betweeen the technical sender of the acceptance email message (From:) and the attendee in the ics file who accepts the invitation (attendee)? Can they be different? Can other calendar systems handle that?

I feel that the accepting person in the ics must always be the attendee, but the technical sender of the message might be someone else.
Note that depending on scenario, I can receive an invitation for foo@bar.com (attendee & message recipient), which does NOT necesssarily mean that I have an identity with foo@bar.com set up in Thunderbird (because foo@bar.com can be redirected on some other server, catch-all etc. to end up in a completely different Thunderbird account bar@baz.com).

We need to consider two cases separately: A) bootstrapping all through emails, and B) server involvement (event added to calendar server side).

For case #A (the event is only in the email so far), it seems very reasonable to check the invitees and compare them to the identities set up.

• if exactly one match is found, use that.
• if there is ambiguity about which of the invitees was invited, then "ask (which one to accept from)"
• if no mach is found, "explain + ask" (you're party crashing)

For case #B - the event is on the server (in the calendar) already:

• if the calendar email matches one of the invitees, use that
• if not, "explain + ask" (you're party crashing)

Note: it's possible to also "accept/decline with note" (xref bug 1406868), and I think we should consider the implications of that here as well, with the "asking". What i mean is, it's clear that some base identity selections are wrong here, but there's a potential need to open some kind of reply window for other cases as well (probably in the accept dropdown add a "accept with note...")

I'm not sure but I suppose it's also possible there are no invitees at all (open invitation). Seems like the suggestion should work for that as well.

(In reply to Thomas D. (:thomas8) from comment #25)

Lasana, do you know more about the relationship betweeen the technical sender of the acceptance email message (From:) and the attendee in the ics file who accepts the invitation (attendee)? Can they be different?

If I understand what you are asking correctly then; Calendar is configured to have one email identity configured per calendar. When an invitation comes in, each calendar is checked to see if its identity matches the email address invited, if any match, the reply will use that. If none match then the calendar that is currently the default is used (and if that fails I think it just uses the currently selected mail account, not sure).

Can other calendar systems handle that?

No idea, I don't get invited to much events. :/

We need to consider two cases separately: A) bootstrapping all through emails, and B) server involvement (event added to calendar server side).
...

This seems about right. It then comes down to implementing this in a non-annoying way.

I think we can close this now, the changes made in bug 1702782 and related bugs more or less handle replying with the wrong identity by prompting the user. For the cases where the event is already processed by the server, it's likely the server will refuse the event, at least that's what I see with fastmail. The calconnect website says "the server is always correct" so we probably should not do more than synchronize with it. The UX could be better for refused events however. As for the decline with message part, that may be out of the scope of this bug.

Just to say Thanks to the designers and coders. I'm very happy with the final solution which allows me to direct the invite acceptance back to the correct sender.
Good job!