1587736 - Invitation mails are created/sent using the email address of the CALDAV online calendar as organizer instead of organizer's email address as specified in TB's calendar properties

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Christian Wolf]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I configured a CalDAV Server to be synchronized. I enabled "Prefer client-side email scheduling". There is a valid mail address account specified ([e-mail]) in the calendar's settings.
I create a new appointment and click on "Invite Attandees".

Actual results:

The list of attendees (empty except for me) opens. The problem here is that the mail address prefilled (and unchangeable) of myself is an internal address ([e-mail]) used on the CalDAV server. I did not put it anywhere in my Thunderbird/Lightning configuration. When sending the invitation, this internal mail address is used. This causes friction and problems with external attendees.

Expected results:

The mail address of the mail account is used that is configured in the calendar's settings.

Comment 1

[Christian Wolf]

I think this is related: When accepting/rejecting invitations of others, the internal address is used as well. This causes the organisator of the appointment to get confused at best.

Comment 3

[Thomas D. (:thomas8)]

Bug 1617558 reports exactly the same.

In some way, these two are similar enough in symptoms to be a duplicate of bug 1562896, but bug 1562896 may not necessarily involve the Caldav component where the unwanted address is coming from the online calendar. I'd guess the solution for both issues is that the attendee for whom the event is accepted must be the attendee originally invited, and not some random other email address. Probably fixing bug 1562896 will fix this too.

Comment 4

[Thomas D. (:thomas8)]

In any case, this is happening, so confirming.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Christian Wolf from comment #1)

I think this is related: When accepting/rejecting invitations of others, the internal address is used as well. This causes the organisator of the appointment to get confused at best.

Looks like an ux-implementation-level thing. Using the internal address is logically wrong for both creating (as organizer) and accepting (as attendee) an event. However, the expected outcome for accepting would be different from creating:

• When creating an event, use email associated with TB's calendar as organizer
• When accepting an event, use invited attendee's email address for the accepting attendee (not necessarily same as TB's calendar address).
• I'm wondering if the actual From: address for the outgoing emails might be different from organizer or accepting attendee?

Comment 6

[luca]

I am on Windows 10, TB 91.8.1 (64-bit).
I just added a bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1766796 that seems related to this one.
As already commented by others, TB seems to confuse the email username of a calendar with the email that should be associated with that calendar.

Comment 7

[geez]

Unfortunately I have to agree with those just above me. I would dive into Thunderbird's source and have go myself, but I have nowhere near enough time for this. I have donated to Thunderbird many times in the past, and I really hope this gets addressed as it is quite a critical bug which also has important privacy impact.

I have personal and work calendars (synced from my Nextcloud), associated with different email accounts. Whenever I organise a work meeting, it ends up with my personal email as organiser, and my work email as participant. This results in leaking my personal email address to whomever I am organising a meeting with. Unprofessional, confusing, uncomfortable.

Overall there are around 3-5 critical and related bugs in how calendar invitations are set up or accepted/declined - I believe this should receive a much higher priority (in fact I'd much rather see those addressed than the whole GUI revamp, even if it is great!).

Comment 8

[geez]

(Double posting due to relevance to people in this thread, workaround below)
Thunderbird 115.3.1, this bug is still present. The selection of the email address associated with the calendar has zero influence here.

Steps to reproduce:

• Create two calDAV calendars (A and B), both on the same Nextcloud account.
• Import them into Thunderbird
• Set up two email accounts in Thunderbird, one personal and one work
• Select personal email address for calendar A
• Select work email address for the calendar B
• Confirm, save, double check.
• Create event in calendar A, try to invite people. Associated personal email address is ignored, organiser is ALWAYS the email address of the Nextcloud account.
• Create event in calendar B, try to invite people. Associated work email address is ignored, organiser is ALWAYS the email address of the Nextcloud account.

Tested this using a completly random (nonexistent) email address set up in my Nextcloud account. This address happily showed up as organiser for both calendars. This makes event invitations pretty much unusable for me and LEAKS my private information to work contacts.

A workaround for Nextcloud (or similar) users:

• Create a secondary account, e.g., myname_work, with the desired email address.
• Share the relevant calendar from your main account to that account.
• Use that user's calendar instead.

Comment 9

[Thibault Leclercq [:tibboddit]]

Disclaimer: what follows is a strong guess based on code inspection, I have NOT tested a build to validate it.

After also encountering this bug, I decided to dig into the source code.
It seems to me that the problem lies in how the result of cal.email.attendeeMatchesAddresses calls is used, e.g. at https://hg.mozilla.org/comm-central/file/b631fadaa2a5d472959888022f9ed80c44eae9a6/calendar/base/content/dialogs/calendar-summary-dialog.js#l113

/**
 * Updates the user's participation status (PARTSTAT from see RFC5545), and
 * send a notification if requested. Then close the dialog.
 *
 * @param {string} aResponseMode - a literal of one of the response modes defined
 *                                 in calIItipItem (like 'NONE')
 * @param {string} aPartStat - participation status; a PARTSTAT value
 */
function reply(aResponseMode, aPartStat) {
  // Set participation status.
  if (window.attendee) {
    const aclEntry = window.calendarItem.calendar.aclEntry;
    if (aclEntry) {
      const userAddresses = aclEntry.getUserAddresses();
      if (
        userAddresses.length > 0 &&
        !cal.email.attendeeMatchesAddresses(window.attendee, userAddresses)
      ) {
        window.attendee.setProperty("SENT-BY", "mailto:" + userAddresses[0]);
      }
    }
    window.attendee.participationStatus = aPartStat;
    updateToolbar();
  }

  // Send notification and close window.
  saveAndClose(aResponseMode);
}

Specifically, userAddresses[0] is used, but the attendeeMatchesAddresses function may have found a match at a different index in the userAddresses table.

On the four attendeeMatchesAddresses calls I found in the code base, the same logic is applied. A quick fix could be to return the matching index (or -1 if no match) and use it to get the right address instead of using 0.

Comment 10

[Thibault Leclercq [:tibboddit]]

(In reply to Thibault Leclercq [:tibboddit] from comment #9)

Disclaimer: what follows is a strong guess based on code inspection, I have NOT tested a build to validate it.

After also encountering this bug, I decided to dig into the source code.
It seems to me that the problem lies in how the result of cal.email.attendeeMatchesAddresses calls is used, e.g. at https://hg.mozilla.org/comm-central/file/b631fadaa2a5d472959888022f9ed80c44eae9a6/calendar/base/content/dialogs/calendar-summary-dialog.js#l113

/**
 * Updates the user's participation status (PARTSTAT from see RFC5545), and
 * send a notification if requested. Then close the dialog.
 *
 * @param {string} aResponseMode - a literal of one of the response modes defined
 *                                 in calIItipItem (like 'NONE')
 * @param {string} aPartStat - participation status; a PARTSTAT value
 */
function reply(aResponseMode, aPartStat) {
  // Set participation status.
  if (window.attendee) {
    const aclEntry = window.calendarItem.calendar.aclEntry;
    if (aclEntry) {
      const userAddresses = aclEntry.getUserAddresses();
      if (
        userAddresses.length > 0 &&
        !cal.email.attendeeMatchesAddresses(window.attendee, userAddresses)
      ) {
        window.attendee.setProperty("SENT-BY", "mailto:" + userAddresses[0]);
      }
    }
    window.attendee.participationStatus = aPartStat;
    updateToolbar();
  }

  // Send notification and close window.
  saveAndClose(aResponseMode);
}

Specifically, userAddresses[0] is used, but the attendeeMatchesAddresses function may have found a match at a different index in the userAddresses table.

On the four attendeeMatchesAddresses calls I found in the code base, the same logic is applied. A quick fix could be to return the matching index (or -1 if no match) and use it to get the right address instead of using 0.

Edit: the part about the attendeeMatchesAddresses function makes no sense, sorry about that. The problem seems to be that sometimes userAddresses includes a public alias instead of my main email. Not sure if this is a Thunderbird or a mail provider problem.

Comment 11

[Philippp]

Thanks for looking into this!
I want to add my findings (using caldav server of Synology NAS, but external email provider):

We are affected as well, even worse, because the user name that Thunderbird is using for the "organizer" (from: of the invites) is not even a valid email adress. Thus, any replies do net get delivered at all.

A lot of testing brought up this:
When operating on my private calendar ("My Calendar", URI on our NAS ending with /home), Thunderbird uses the correct email adress for sending the invites (the one I selected in properties of this calendar) as expected.
(However, we cannot use these private calendars, because they cannot be shared in the team, so we need to create other calendars.)
For all other calendars, Thunderbird uses a false email adress for the organizer, thus creating the defunct invitations.

The weird part is (hope this helps): I did not find any place in pref.js where the false adress is occurring. It only occurs as a part of the caldav URI which is something thing like: https://nas.xxx.local/caldav/[e-mail]/abcdef . (domain literally in there, this is what our Synology NAS wants, despite our local domain is named differently). The user login name for the caldav account is xx@YYY (without the .domain addition). So, Thunderbird seems to extract a substring from the URI string to be used as the users email adress here!

Comment 12

[Philippp]

Just found that #1864415 indeed seems to be very similar. Maybe the reasoning given there (interaction with caldav server) explains where the weird user email adress comes from?

Comment 13

[Sergey Korablin [:brs-brs]]

Attachment: WIP: Bug 1587736 - [caldav] Temporary solution: Choose the first email from calendar-user-address-set instead of last one

Comment 14

[Sergey Korablin [:brs-brs]]

Attachment: Bug 1587736 - [caldav] Choose the first email from calendar-user-address-set instead of the last one for mCalendarUserAddress;. r=mkmelin

Comment 15

[Magnus Melin [:mkmelin]]

Comment 10 also seems like a bug indeed. Do you want to take that one on as well? Seems to me attendeeMatchesAddresses should be fixed to return the matching address or null.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d4c9a58677f7
[caldav] Choose the first email from calendar-user-address-set instead of the last one for mCalendarUserAddress;. r=mkmelin