1766796 - Calendar always changes organizer of event

Status: UNCONFIRMED

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

Description

[luca]

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

Steps to reproduce:

I have two caldav calendars. Both have a specific email "email-A" as username. However, the second calendar is associated to a different email "email-B" in its Properties settings.

I accepted a calendar invitation sent from another person to email-B, by clicking on the "Accept" button at the top of the invitation email.

Actual results:

Thunderbird sent two emails to each attendee of the event:

1. First email, from email-A, to notify changing the organizer of the event to email-A.
2. Second email, also from email-A, to notify acceptance of event.

Expected results:

The organizer should never have been changed. Only the acceptance email should have been sent, and from email-B (the original recipient of the invitation), not from email-A.

This bug could possibly be related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1587736

Comment 1

[luca]

Note: I think this is quite a severe bug. Changing the organizer of a calendar event is very impolite, and on top of that the change is spammed to all attendees of the event. I already had to send email apologies to organizer & attendees several times, explaining that it was a bug of my email client.

Comment 2

[d2_c2]

I have a similar issue in TB 102, been happening for quite some time. This is a critical bug for me.

I have calendars loaded as google calendars that cannot accept invitations outside the organization (another bug). I have local caldav calendars that can accept the invites correctly. When I copy from the local calendars to the google calendars, the organizer is changed, if I am not careful, I will spam the entire invite list.

The worse problem is because the organizer has changed, the links for TEAMS or GoToMeeting don't work, because the organizer is not authenticated on the other side.

Comment 3

[Sergey Korablin [:brs-brs]]

I have identified the origin of an issue where the organizer name is incorrect if the user has email aliases. This issue can be found in the source file mozilla-unified/comm/calendar/providers/caldav/CalDavCalendar.sys.mjs, around line 1870 (version 130.0, but it has been present for a long time).
Here is the relevant code that updates the mCalendarUserAddress property:

          for (const addr of response.firstProps["C:calendar-user-address-set"]) {
            if (addr.match(/^mailto:/i)) {
              cal.LOG("BRS: calendar-user-address-set := " + addr);
              this.mCalendarUserAddress = addr;
            }
          }

The mCalendarUserAddress property is updated in a cycle that overwrites previous email addresses, resulting in the last email alias being used as the organizer name. I do not understand the reasoning behind this cycle. If anyone has insights, please share them.

As a quick solution, I modified the code to use the first email returned in the calendar-user-address-set field of XML response from the server. This first email address, in my case, is the main email address, which I prefer to use:

          const addrSet = response.firstProps["C:calendar-user-address-set"];
          const firstAddr = addrSet.find(addr => addr.match(/^mailto:/i));
          if (firstAddr) {
            cal.LOG("Calendar-user-address-set as: " + firstAddr);
            this.mCalendarUserAddress = firstAddr;
          }

There is still, however, another issue where the explicit user setting of "email" for the calendar is overridden by this parameter. I plan to investigate this further.

Related topics:
https://bugzilla.mozilla.org/show_bug.cgi?id=1766796 (this topic)
https://bugzilla.mozilla.org/show_bug.cgi?id=865726
https://bugzilla.mozilla.org/show_bug.cgi?id=1587736
https://support.mozilla.org/en-US/questions/1428206
https://community.mailcow.email/d/2658-calendar-invitations-in-thunderbird-wrong-organizator/11

Comment 4

[max]

Encountered this issue aswell: https://userforum-en.mailbox.org/topic/2446-thunderbird-uses-account-alias-as-event-organizer

Comment 5

[Magnus Melin [:mkmelin]]

(In reply to Sergey Korablin [:brs-brs] from comment #3)

https://support.mozilla.org/en-US/questions/1428206
Sergey, did you find more things that needed fixing?

Comment 6

[Yogesh]

Just to add to this, the "workaround" of clicking on the default-set (wrong) email address and typing the correct organizer email/alias does not change the organizer. The issue persists for me.

My setup is a fastmail account with a primary login email - which is for login only. And a bunch of identities - one of which I have set as the "email" (whatever that means) for the CalDAV calendar. But whenever I create an event to share, the organizer email is always something else that was fetched from the server. There is no way to fix this currently.

I would suggest that Thunderbird provide a way to set the organizer in the UI as a dropdown rather than the user having to noodle in the invite list - which has poor UI

Comment 7

[Francesco]

The code in comment #3 was added in bug 1587736. Can this bug be closed as a duplicate?

Comment 8

[luca]

(In reply to Francesco from comment #7)

The code in comment #3 was added in bug 1587736. Can this bug be closed as a duplicate?

Not sure the present bug is still solved with that. That comment says 'explicit user setting of "email" for the calendar is still overridden', and the part of the problem of the present bug is in accepting an invitation, rather than creating and sending a new one.

Unfortunately I can't test this because I'm staying with Thunderbird 102.15 after the vertical-space-unfriendly change in user interface in the new versions...

Comment 9

[drhirn]

I can test.
And I can confirm, that the settings is still overridden when creating new invitations with attendees. Instead, always an alias is used. And if you have a lot of aliases, always the alphabetically last one is used.

For example:
Main address: [e-mail]
Aliases: [e-mail],[e-mail],[e-mail]

The organizer of the new event now would be [e-mail], no matter what I configured as calendar-address in Thunderbird.
If I delete the alias [e-mail] and create a new Thunderbird profile, the organizer is then [e-mail].

Comment 10

[Thomas Schafft]

As of today this bug also exists in Thunderbird 147.0 (64-bit) on Windows 11 - and is very confusing for the user.

In my case, it occurs with a custom domain name used at Mailbox.org:

Main address: [e-mail]
Aliases: [e-mail], [e-mail], [e-mail].

Despite never mentioning this address when setting up Thunderbird, it always uses [e-mail] as the event organizer.

Comment 11

[Jens B]

I can reproduce this issue with mailbox.org CalDAV and Thunderbird.
Setup:

• mailbox.org account with a custom domain address
• Thunderbird on Linux
• CalDAV calendar from mailbox.org
• Desired organizer address: custom domain address, e.g. [e-mail]
• Additional mailbox.org alias address exists, e.g. [e-mail]

The CalDAV server returns the following calendar-user-address-set for the principal:

<calendar-user-address-set xmlns="urn:ietf:params:xml:ns:caldav">
  <D:href preferred="1">mailto:[e-mail]</D:href>
  <D:href>mailto:[e-mail]</D:href>
  <D:href>/principals/users/...</D:href>
  <D:href>urn:uuid:...</D:href>
</calendar-user-address-set>

The custom domain address is correctly marked as preferred="1" by the server. However, Thunderbird ignores this preferred address and uses the last mailto: address from the calendar-user-address-set as the event organizer.

I verified this by adding another @mailbox.org alias. After adding it, the server returned:

<calendar-user-address-set xmlns="urn:ietf:params:xml:ns:caldav">
  <D:href preferred="1">mailto:[e-mail]</D:href>
  <D:href>mailto:[e-mail]</D:href>
  <D:href>mailto:[e-mail]</D:href>
  <D:href>/principals/users/...</D:href>
  <D:href>urn:uuid:...</D:href>
</calendar-user-address-set>

Thunderbird then used [e-mail] as the organizer. This strongly suggests that Thunderbird simply takes the last mailto: entry instead of respecting preferred="1".

If I remove/deactivate all additional @mailbox.org alias addresses so that the only remaining mailto: entry is the custom domain address:

<calendar-user-address-set xmlns="urn:ietf:params:xml:ns:caldav">
  <D:href preferred="1">mailto:[e-mail]</D:href>
  <D:href>/principals/users/...</D:href>
  <D:href>urn:uuid:...</D:href>
</calendar-user-address-set>

Thunderbird correctly uses [e-mail] as organizer.

The Thunderbird calendar properties already have the correct email identity selected, and forceEmailScheduling does not change this behavior. The selected identity in Thunderbird appears to be ignored for determining the CalDAV organizer address.

Expected behavior:

Thunderbird should use the address marked with preferred="1" from calendar-user-address-set, or alternatively the email identity explicitly selected in the calendar properties.

Actual behavior:

Thunderbird uses the last mailto: address from calendar-user-address-set, even if another address is marked as preferred="1".

This is especially problematic for users with custom domains, because the provider may expose both the custom domain address and provider-internal alias addresses via CalDAV. In this case Thunderbird sends calendar invitations with the wrong organizer address.

Comment 12

[Jens B]

Looking at calendar/providers/caldav/CalDavCalendar.sys.mjs, the relevant code appears to be the handling of C:calendar-user-address-set.

The previous logic effectively used the last mailto: entry, because this.mCalendarUserAddress was overwritten in a loop. The patch in D218507 changes this to use the first mailto: entry. This is an improvement, but I do not think it fully solves the issue.

The first address is still dependent on the order returned by the CalDAV server. The user has no direct control over this order.

In my opinion, Thunderbird should select the organizer address in this order:

1. If the calendar has an explicitly selected Thunderbird email identity and that address is present in calendar-user-address-set, use that address.
2. Otherwise, if the CalDAV server marks one mailto: entry as preferred="1", use that address.
3. Otherwise, fall back to the first mailto: entry.

This would avoid relying on arbitrary server order and would respect the user’s explicit calendar identity setting.

A possible approach could be:

const addrSet = response.firstProps["C:calendar-user-address-set"] || [];
const mailtoAddresses = addrSet.filter(addr => /^mailto:/i.test(addr));

let selectedAddress = null;

// 1. Prefer the Thunderbird calendar email identity, if it is one of the
// server-provided CalDAV user addresses.
// Pseudo-code: the exact property/API may differ.
const identity = this.getProperty("imip.identity");
const identityEmail = identity?.email;
if (identityEmail) {
  const identityMailto = `mailto:${identityEmail}`.toLowerCase();
  selectedAddress = mailtoAddresses.find(
    addr => addr.toLowerCase() == identityMailto
  );
}

// 2. Otherwise use the address marked preferred by the server.
// This requires that the XML parser preserves the `preferred="1"` attribute
// for entries in C:calendar-user-address-set.
if (!selectedAddress) {
  selectedAddress = findPreferredMailtoAddressFromCalendarUserAddressSet(response);
}

// 3. Otherwise fall back to the first mailto address.
if (!selectedAddress) {
  selectedAddress = mailtoAddresses[0];
}

if (selectedAddress) {
  this.mCalendarUserAddress = selectedAddress;
}

If the current representation of response.firstProps["C:calendar-user-address-set"] only contains strings and loses attributes such as preferred="1", then Thunderbird would also need to preserve those attributes when parsing this property.

The important part is the selection order:

calendar identity selected by the user > server preferred address > first mailto fallback.

This would solve cases where a provider exposes multiple valid addresses, such as a custom-domain address plus provider-internal aliases.