865726 - Only last address of calendar-user-address-set / email is taken into account when determining if invited

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[Igor Vitorac]

It seems that latest Lightning (1.9.1) has again (?) problem with Invitee email address received from CalDAV.

- I am using Thunderbird ESR 17.0.5 and Lightning 1.9.1
I can remember (not 100% sure) that there was such problem in previous Lightning versions (between 1.2.3 and 1.9.1). But I am 100% sure that combination Thunderbird ESR 10 and Lightning 1.2.3 was working perfectly.

- I use SOGo (ver 2.0.4b) as calendar server and connecting from Lightning with CalDAV

- I have 2 emails defined in Thunderbird:
[e-mail] (this one is primary and defined as email in Lightning Calendar properties)
[e-mail]

- I have both email defined in SOGo SQL user source, so SOGo is aware of both.
- My SOGo is installed at sogo.example.com

- Email address defined in calendar properties in Lightning is [e-mail]

Problem:
- When I create event and I want to invite somebody, I can see that my address is displayed as wrongly as [e-mail] (last/second email) in invitee list.
- When I receive email invitation from somebody else, Lightning will respond again with wrong email [e-mail] (last one)

New test:
- Then I removed [e-mail] (last email) from my profile in SOGo user source, so only one has left [e-mail]. Cleared memcached on SOGo server; Started TB/Lightning and Lightning was showing correctly email address ([e-mail])! This time CalDAV server was sending only one email and that email was taken.

So, seems that SOGo (during CalDAV conversation) is sending both emails ([e-mail] and [e-mail] ) to Lightning and Lightning is using only the last one (for sending invitations and for responding to invitations).

These are very similar/related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=539916
https://bugzilla.mozilla.org/show_bug.cgi?id=540410
but seems that Lightning now displays always option to Accept/Decline invitation, however behavior with invitee email address is back again.

Just to mentioned that recently we used Thunderbird ESR 10 + Lightning 1.2.3 and we did not have problems as described above.

Comment 1

[Arnaud LE NORCY]

Hello,

I have exactly the same problem!

Thunderbird ESR 17.0.5 and Lightning 1.9.1
My calDAV server is sogo 2.0.5

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, this is what's causing bug 859383 for me.

Is there anyone in Lightning-land willing to fix this?  This is one of the main things stopping me from being able to use Lightning without going into our Zimbra web instance all the time, because I have essentially random control over my calendar via Lightning.  I would be willing to toss up a bounty, if a brib^H^H^H^Hbounty is needed!

Or, alternatively, if someone can point me at the relevant source, I can find some time to fix it myself as well.

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

The code is likely here: http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js#2021

There seems to be some very simple logic to pick an email address, but looks like it doesn't work in all cases.

The comment about using the ACL manager means we now have an ACL manager, which is not being used everywhere because it was originally targeted only as a hook for an extension.

The simple solution is to improve the logic to pick one of the email addresses. Optionally add a calendar property to allow the user to specify a fixed email address via prefs.

The more complete solution would involve some UI changes, allowing the user to pick an identity where appropriate.

I don't think I will have time to fix this myself. It would be cool to have you back in calendar land though :-)

Comment 5

[Igor Vitorac]

Vladimire, that would be great if you find some time to fix this.

I found many discussion how Lightning should use email when sending invitations and responding to invitations.

From my point of view, ideally, Lightning should use email address defined in Calendar properties. 
If user has many calendars and many email accounts, user will configure appropriate email for each calendar. So, it will be up to user to set the proper email and it will give the user the biggest flexibility to configure calendar behavior. Otherwise, what is the point of Email definition in Calendar properties, right?

Bottom line for ideal scenario:
- User configures email per calendar (already implemented). This should tell the Lightning what is the user email (user id) to be used for the organizer/participant value for the events in that particular calendar.
- During creation of event user needs to chose calendar where to create event (already implemented)
- When sending invitation and when choosing which email to use for the organizer (user itself), Lightning must use email configured in Calendar properties (TO BE IMPLEMENTED)
- When calendar event invitation arrives in Inbox, Lightning asks in which calendar to store the event (it worked few version before, I have not checked it now)
- When sending email notification for the Acceptance for the event, Lightning should use email (user id / participant) defined in calendar properties. (TO BE IMPLEMENTED)

Thanks,
Igor

Comment 6

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to Igor Vitorac from comment #5)

> From my point of view, ideally, Lightning should use email address defined
> in Calendar properties. 
> If user has many calendars and many email accounts, user will configure
> appropriate email for each calendar. So, it will be up to user to set the
> proper email and it will give the user the biggest flexibility to configure
> calendar behavior. Otherwise, what is the point of Email definition in
> Calendar properties, right?
Ah yes, the calendar properties email. This is something where the acl manager could be used nicely. If a non-default acl manager is created for caldav that provides the email addresses, then the properties dialog could not only show the email addresses from the identities, but also those of the acl manager. Possibly not show the addresses from the identities, but then again users could complain they can't set up their emails right.

Comment 7

[Klaus Stengel]

Attachment: Add CalDAV-Identities to ACL-Manager

In order to make this work in our SOGo installation, I created the attached patch. It will feed the identity list retrieved from the server back into the local ACL-Manager, so you can select which e-mail address should be used for each calendar. This also fixes the problem that people sometimes appear multiple times in the participant list with different addresses after changing the status on an invitation. In our setup, e-mail notifications are generated on the server, so I haven't tested what happens if Thunderbird is supposed to send notfications itself.

Comment 8

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 8427612 [details] [diff] [review]
Add CalDAV-Identities to ACL-Manager

Review of attachment 8427612 [details] [diff] [review]:
-----------------------------------------------------------------

r- for now, I think we should discuss the acl manager changes here. Also, given this doesn't fully fix the bug, I'd suggest filing a new bug instead and continuing discussion and patches there.

::: components/calDavCalendar.js
@@ +2139,5 @@
> +                            thisCalendar.mCalendarUserAddress = addr; // Use first one as default
> +                        }
> +                        if (thisCalendar.mCalendarUserAddressList.indexOf(addr) === -1) {
> +                            thisCalendar.mCalendarUserAddressList.push(addr); // Collect others in list
> +                        }

I'd suggest to instead save all addresses in an array and make sure the default entry is at the beginning of the array. Then you can drop the mCalendarUserAddress property and use the array instead.

::: components/calDefaultACLManager.js
@@ +84,5 @@
>          let addresses = [ id.email for each (id in identities) ];
> +        let server_addrs = this.mCalendar.calenderUserAddressList;
> +        if (server_addrs != null) {
> +            addresses = addresses.concat(server_addrs);
> +        }

The calendar is not necessarily a caldav calendar and is usually a wrapped instance (wrapped by the calICalendar interface). Therefore in many cases, this will just be ignored.

I believe SOGo (with the connector/integrator) is using a custom ACL manager anwyay, doesn't the code there provide a custom implementation of getUserAddresses that returns the caldav addresses?

Comment 9

[Philipp Kewisch [:Fallen][☁️📆]]

I don't quite recall why I wanted it to happen in a different bug. I'm duping 540410 against this bug since it has a patch, but I like the title of that one more.

Comment 13

[wreck]

Is there something preventing the inclusion of this patch? I'm running into this issue currently and this bug has been open for 7 years.

Comment 14

[Philipp Kewisch [:Fallen][☁️📆]]

The issues in comment 8 need to be resolved before we can include this patch.

Comment 15

[Olivier Mueller]

Hello and thanks Igor for the ticket!

Just a short comment to confirm the issue is still open, in my case with the caldav server from Zimbra 9.0.0_GA_3960, and the latest thunderbird client to date, 78.5.0 (under Mac OS and Linux). I just spent several hours trying to debug and understand the behaviour of thunderbird. With a single mail address, everything works as expected. But once an alias (or more) is defined in zimbra, the caldav client from thunderbird is unable to answer correctly to invitations from other people.

The header fields:
Originator: mailto:[e-mail]
Recipient: mailto:[e-mail]

And VCALENDAR entries:
ORGANIZER:mailto:[e-mail]

are wrong, and should be using "[e-mail]" instead. It is the case both ways, when trying to reply to an invitation, but also when trying to send an invitation to another account.

It seems the latest working version of thunderbird + lightning was version 52.2 (June 2017). Some clients here would like to be able to upgrade to a more recent version of Thunderbird, so a fix here (or even a temporary workaround) would be more than welcome.

Testing with other caldav clients were fine so far (for example with Mac OS 11 Big Sur Calendar.app).

Best regards, Olivier

Comment 16

[Rainer]

I just wanted to file this as a bug and saw that it has already been reported - 10 years ago! And that it is still unfixed.
I also saw a related (maybe identical) bug 1587736.

I have exactly this problem in Thunderbird 102.4.2.
My main email address is, let’s say, [e-mail]. I also have an alias [e-mail]. In Thunderbird, I associate all subscribed calendars with the address [e-mail] in the calendar properties.
When I create a calendar event and click the button “Invite attendees”, the first line of the calendar overview is prefilled with [e-mail] (most probably the last address in the “calendar-user-address-set”).

This is annoying/strange in a number of ways:

1. This forces me, every time, to manually change the prefilled address into the correct one ([e-mail] in this case) to ensure it goes out from the correct sender.
2. I suspect that this is responsible for a large number of “Party crashing?” messages I get when trying to accept invites sent to me ([e-mail]).
3. I was not even aware that a “calendar-user-address-set” exists and that it reveals (potentially all) my aliases. I have never used my aliases in the configuration of any accounts/calendars in Thunderbird. So for the unsuspecting user this might even be a privacy leak.

I have had this problem for around three years. I always thought that it is a bug of my email provider (Kolab Now). But after changing to Mailbox.org, the problem continues.

Many business users have aliases. This bug, even though not catastrophic, makes the use of calendar invites a real pain. I would very appreciate if this was given a higher priority.

Comment 17

[Sergey Korablin [:brs-brs]]

I have investigated this bug and have some updates in the related thread: https://bugzilla.mozilla.org/show_bug.cgi?id=1766796#c3

Comment 18

[Rainer]

Hey, someone is looking into this! Thank you so much! I hope your code changes will be integrated asap.

Comment 19

[Lorenz Pressler]

the problem with receiving invitations should be solved with bug 1987654
i have linked the backported files for current stable 145.0 there in the comments if you want to test.

Comment 20

[Lorenz Pressler]

the part about creating events is tracked with this (even older) bug 603320

so I think this bug can be closed as duplicate? The part about the "last address" was also fixed long ago, it now takes the first address reported by the caldav server.

Comment 21

[Grepl Zbynek]

Confirmed reproduction in Thunderbird 148.0 with Nextcloud CalDAV

This bug is actively causing a real-world workflow failure in our environment. Here is a precise reproduction case.

Environment

• Thunderbird: 148.0 64-bit (Windows 10)
• CalDAV server: Nextcloud 32.0.6.1
• Authentication: LDAP (user_ldap)

Profile setup

A single Thunderbird profile is used by a secretary managing calendars for multiple officials. Each official has a fully configured IMAP account and a dedicated CalDAV calendar under their own Nextcloud user:

Account	Email	CalDAV URL
Official 1 (Mayor)	[e-mail]	/calendars/urad818/personal/
Official 2 (Deputy Mayor)	[e-mail]	/calendars/urad1417/personal/

Each calendar has the E-mail field in calendar properties set to the correct matching address ([e-mail] and [e-mail] respectively).

Reproduction steps

1. Organizer creates event, invites both officials.
2. Organizer sends separate individual emails to each attendee (unique Message-ID per email, single ATTENDEE per ICS).
3. Secretary opens Thunderbird (single profile).
4. Secretary accepts invitation for Official 1 ([e-mail]) → iMIP bar works correctly → CalDAV PUT performed to /calendars/urad818/personal/[uid].ics.
5. Secretary opens invitation email for Official 2 ([e-mail]).

Result

iMIP bar shows:

"This message contains an event that has already been processed."

No CalDAV PUT is performed for /calendars/urad1417/personal/. The event is never added to Official 2's calendar.

Server logs confirming the issue

# Official 1 accepted correctly:
PUT /remote.php/dav/calendars/urad818/personal/e99d5bb3-af75-4707-a489-7472985cf429.ics
user: urad818

# Official 2 – only REPORT sync, no PUT ever follows:
REPORT /remote.php/dav/calendars/urad1417/personal/
user: urad1417

ICS content of invitation for Official 2

UID:e99d5bb3-af75-4707-a489-7472985cf429
METHOD:REQUEST
ATTENDEE;RSVP=TRUE;CN=Name Surname;PARTSTAT=NEEDS-ACTION:mailto:[e-mail]
ORGANIZER:mailto:[e-mail]

Analysis

Thunderbird evaluates whether an invitation has been processed by checking the event UID globally across all calendars in the profile, without considering which specific calendar account/email identity the invitation is addressed to.

When calendar-user-address-set contains multiple addresses (one per account), Thunderbird apparently only considers the last one (as described in this bug) or uses a global UID lookup that ignores the target ATTENDEE identity entirely.

Tested about:config settings (none resolved the issue)

• calendar.itip.newInvitationDisplay = true
• calendar.itip.separateInvitationPerAttendee = true
• calendar.itip.separateInvitationButtons = true

Impact

This bug makes it impossible for a secretary to manage calendar invitations for multiple principals within a single Thunderbird profile — a very common real-world use case in organizations where one person manages schedules for several executives.

Expected behavior

Thunderbird should evaluate iMIP invitation status per calendar account identity by matching the invitation's ATTENDEE address against the email identity configured for each individual calendar. A UID processed for one account should not suppress the iMIP bar for a different account with a different email identity.