Closed Bug 1880646 Opened 4 months ago Closed 2 months ago

Account setup triggers OAuth dialog when looking for calendars after successful creation


(Thunderbird :: Account Manager, defect, P1)

Thunderbird 115


(thunderbird_esr115 wontfix)

126 Branch
Tracking Status
thunderbird_esr115 --- wontfix


(Reporter: aleca, Assigned: mkmelin)



(1 file)

Steps to reproduce:

  • Add a new account to Thunderbird, one that doesn't use OAuth but a simple app password
    • If you have access to our shared 1Password account you can use the Test IMAP account from Fastmail.
  • Complete the setup.


  • The account is created but upon reaching the final screen an OAuth dialog is prompted when trying to fetch calendars via CalDav.

This shouldn't happen since the test account I'm using doesn't have OAuth enabled and only uses a regular password to connect.

Magnus, would you be able to take a look at this?

Flags: needinfo?(mkmelin+mozilla)

I'm not sure what the expectation is, but the result you got doesn't seem wrong - what auth method was used for the email account doesn't have an impact on what calendar/addressbook use for authentication. Actual creds, and servers, can also be different for each.

We always use OAuth2 for fastmail and google calendars.

Flags: needinfo?(mkmelin+mozilla)

Thanks for the explanation.
It could be just a case of "user confusion", because as I user if I set my account to only use a plan password and no OAuth, the expectation would be to be able to get calendars without OAuth and by simply authenticating with the same plane password.

I remember it used to be this way in the past, as setting up our old Fastmail accounts was automatically discovering calendars without popping up an OAuth dialog.

Yeah Fastmail OAuth2 for calendars is pretty new. (bug 1785240)

I see.
So is it correct to always and only pass through OAuth for CalDav even if the user specifically set plain password in their Fastmail settings?

I'll have to look at this in more detail.

Flags: needinfo?(mkmelin+mozilla)
Version: Trunk → Thunderbird 115

Increasing the priority of this as it should be fixed before next ESR.
Severity is 2 since this only fails during the first account setup flow, but it's possible to set up calendars via the "New Calendar" dialog independently.

Severity: -- → S2
Priority: -- → P1

For the thunderbird fastmail imap test account, the issue is that since it's a thunderbird subdomain,
and there are no SRV records for it. During detection we fall back to asking SRV records for the basedomain, which
is, which is known to be google hosted => we pop up OAuth2 to be able to detect calendars.

We don't fall back to base domain for CardDAV, and I would say we should not do it for CalDAV either.
This would potentially affect someone who is using a subdomain for hosting, but not setting
the SRV records for their subdomain - AND the base domain at the same time are setting the SRV records and
they are usable for the subdomain credentials.
Such cases probably exist, but it would not appear to be a very normal case. Where a subdomain is used
for the email address (which is where we get the subdomain from) likely it's often some kind of testing/staging
environment, like it is for

That OAuth2 is requested during account setup during CardDAV/CalDAV autodiscovery is in itself
not unexpected if we discover those services are hosted differently from mail, and thus might
not have the same credentials.

Assignee: nobody → mkmelin+mozilla
Flags: needinfo?(mkmelin+mozilla)
Target Milestone: --- → 127 Branch
Target Milestone: 127 Branch → 126 Branch

Pushed by
Don't fall back to base domain SRV lookup for CalDAV autodiscovery. r=darktrojan

Closed: 2 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.