Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Thunderbird cannot access a calandar stored on an iMAP server

  • 2 replies
  • 0 have this problem
  • 24 views
  • Last reply by det1059

more options

My user upgraded Thunderbird to v136 and no longer can sync his calendar on our IMAP server (Cyrus). When Thunderbird attempts to log into the calendar Cyrus logs an "Internal Server Error" with the detail

May 5 15:11:39 XXXXX cyrus/https[198300]: badlogin: [10.8.0.10] Basic SASL(-1): generic failure: All-whitespace username. May 5 15:11:39 XXXXX cyrus/https[198300]: [10.8.0.10] with "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Thunderbird/138.0" via SESSIONID=<cyrus-1746483098-198300-1-4996003587903488780>; "PUT /dav/calendars/user/XXXXX/Default/040000008200E00074C5B7101A82E00800000000E0076891A1BDDB0100000000000000001000000076BAF045101B7D4EA90CA085DF4D7B11.ics HTTP/2" (if-none-match=*) => "HTTP/2 500 Internal Server Error" (stream-id=3; error=The server encountered an internal error.) [timing: cmd=0.000448 net=0.000035 total=0.000483]

The user can access their email so their account username/password is stored correctly in Thunderbird, it's just not making it to the calendar subsystem.

Failure is 100%. The user can access their calendar from the previous version of Thunderbird and by using another app on their phone.

My user upgraded Thunderbird to v136 and no longer can sync his calendar on our IMAP server (Cyrus). When Thunderbird attempts to log into the calendar Cyrus logs an "Internal Server Error" with the detail May 5 15:11:39 XXXXX cyrus/https[198300]: badlogin: [10.8.0.10] Basic SASL(-1): generic failure: All-whitespace username. May 5 15:11:39 XXXXX cyrus/https[198300]: [10.8.0.10] with "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Thunderbird/138.0" via SESSIONID=<cyrus-1746483098-198300-1-4996003587903488780>; "PUT /dav/calendars/user/XXXXX/Default/040000008200E00074C5B7101A82E00800000000E0076891A1BDDB0100000000000000001000000076BAF045101B7D4EA90CA085DF4D7B11.ics HTTP/2" (if-none-match=*) => "HTTP/2 500 Internal Server Error" (stream-id=3; error=The server encountered an internal error.) [timing: cmd=0.000448 net=0.000035 total=0.000483] The user can access their email so their account username/password is stored correctly in Thunderbird, it's just not making it to the calendar subsystem. Failure is 100%. The user can access their calendar from the previous version of Thunderbird and by using another app on their phone.

Chosen solution

Thanks for the clarification between IMAP and Caldav.

We have resolved this problem. The problem was caused by a Provider account inside Thunderbird having a username that was blank. The steps to correct the problem are

In Thunderbird go to Account Settings, on bottom left click on Thunderbird Settings Click on "Privacy & Security" and Select "Saved Passwords..." Remove the line with the blank username.

I don't know how this entry was created but I see entries in other Thunderbird instances that are also blank so they are not uncommon. They also don't necessarily cause a problem but when it did the failure was silent on the user's end making this hard to identify. Seeing the log entries on the server was definitive.

Read this answer in context 👍 0

All Replies (2)

more options

several issues here.

1. Caldav is not part of IMAP and you are connecting to a caldav server not an IMAP one. Despite that being a Cyrus back end, the protocols, and ports, are nothing alike. Caldav is HTTP/HTTPS (webpage) where IMAP is IMAP (email).

2. Thunderbird stores all passwords for calendars separately to IMAP. The exception being oAuth where the token is stored in the password manager and shared between calendar and mail.

3. When a calendar is created, you have to tell Thunderbird that credentials are required.

What I find these days is users who have never been challenged for a password turn off authentication when it fails and they are asked for a password. That approach appears to be used if they do not have the password or the one they supply fails.

Helpful?

more options

Chosen Solution

Thanks for the clarification between IMAP and Caldav.

We have resolved this problem. The problem was caused by a Provider account inside Thunderbird having a username that was blank. The steps to correct the problem are

In Thunderbird go to Account Settings, on bottom left click on Thunderbird Settings Click on "Privacy & Security" and Select "Saved Passwords..." Remove the line with the blank username.

I don't know how this entry was created but I see entries in other Thunderbird instances that are also blank so they are not uncommon. They also don't necessarily cause a problem but when it did the failure was silent on the user's end making this hard to identify. Seeing the log entries on the server was definitive.

Helpful?

Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.