With Thunderbird Daily on Linux or Windows, an event created by converting a plain text email with more than one line in the body can not be saved on some CalDAV servers (e.g. Radicale) due to CR characters in the DESCRIPTION property of the iCal object.

Steps to reproduce:

1. Configure a mail account. (Any type.)
2. Subscribe to a network calendar. (Type can be iCalendar or CalDAV. Offline Support on or off.)
3. Create a draft email message in plain text format (e.g. by holding Shift when clicking the Write button), with a subject, where the body contains at least 2 lines. For example:
   Subject: Solstice Party
   Body:
   Solstice party at my house, 2021-12-21 8:00pm.
   Refreshments will be provided.
4. Save and close the draft.
5. Right-click on the draft in the Drafts folder, then click Convert To->Event...
6. Click the "Save and Close" button to save and close the event.

At this point, Thunderbird will send a request to create an iCalendar event with a DESCRIPTION property that contains CR characters in its value (before \n escape sequences). This causes some CalDAV servers (e.g. Radicale) to reject the update because CR is not permitted in TEXT values, except as part of line folding. (See Section 3.3.11 of RFC 5545.) Thunderbird displays

An error occurred when writing to the calendar {calName}! Please see below for more information.
Error code: NOTIFICATION_FAILED
Description:
Status Code: 2147500037, The request cannot be processed.
Server Replied with 400

Mozregression Pushlog: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=e7026840b04d83bc692eca4dac9cc9cd69f84bff&tochange=87d34cfcf232608bc8046c8b1cfbfd78d13066eb

Suggesting this was probably regressed by Bug 1607834.

Kevin, do you find this is fixed in version 102?

Wayne, nope. I'm able to reproduce this bug using the current Daily (build 20220927045520) and a fresh profile. Thanks for following up on this issue!

I can confirm as well issue still happening in 105 beta...

@Kevin,
What errors do you see in the DevTools Console? Make sure to clear/trah the console before trying to convert to event...
Then report back here the errors that you see as per your test in daily.

@Richard, with build 20220927045520 I see 4 messages in DevTools Console after attempting to save the converted event:

Calendar: CalDAV: Unexpected status adding item to TestCal: 400
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20220927T165650Z
LAST-MODIFIED:20220927T165656Z
DTSTAMP:20220927T165656Z
UID:cf9b94ce-ed2c-412a-aa8f-99e071bd311e
SUMMARY:Party
DTSTART;TZID=America/Denver:20221001T200000
DTEND;TZID=America/Denver:20221001T210000
DESCRIPTION:Party at my house\, 2022-10-01 8:00pm.
\nRefreshments will be p
 rovided.
URL:mid:c9fc9beb-7102-9715-e4a2-2dc73d872ea0@example.com
END:VEVENT
END:VCALENDAR

CalDavCalendar.jsm:635
Calendar: There has been an error reading data for calendar: TestCal.  However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_PUT_ERROR. Description: There was an error storing the item on the server. CalCalendarManager.jsm:827

An error occurred when writing to the calendar TestCal! Please see below for more information. Error code: MODIFICATION_FAILED. Description: Status Code: 2147500037, The request cannot be processed.

Server Replied with 400
If you're seeing this message after snoozing or dismissing a reminder and this is for a calendar you do not want to add or edit events for, you can mark this calendar as read-only to avoid such experience in future. To do so, get to the calendar properties by right-clicking on this calendar in the list in the calendar or task view. CalCalendarManager.jsm:824
Uncaught (in promise) Server Replied with 400

For reference, on the server Radicale logs

[WARNING] Bad PUT request on '/me@example.com/78144f98-4b6e-9a8c-2f28-3118a0927ef8/cf9b94ce-ed2c-412a-aa8f-99e071bd311e.ics': At line 59: Failed to parse line: \nRefreshments will be provided.

Obviously the PUT request is not formatted correctly by TB to allow converted event to be saved.

@Kevin,

In the console tbere is a Network tab, are you able to identify the PUT request in it?

If you select it, in the right column Window you should be able to access the request header and content, can you post them here?

Encapsulate them into four backticks ` (start and end) so text would not be parsed in comment... or add them as .txt attachments to this bug report... if you can...

@Richard Failing PUT request.

Geof,

Are you able to look at the PUT request attached, to identify why TB would genetate a "Bad Request"?

As per Comment 0 and mozregression likely linked to changed applied in Bug 1607834.

Maybe something not escaped/encoded correctly in the Request causing server not to parse it correctly...

myr house\\, 2022-10-01 8:00pm.\r\\nRefreshments will be p\r\n

It seems some \r\n are not encoded correctly in text DESCRIPTION... replaced by \\ or \r\\

Regards,

Fyi, I also just noticed in 105.0b4 (64-bit) on Windows that the issue does not affect all emails... but with the one affected (ms365 exchange msg), the following error appears in the console at my end... without showing any error in the TB UI/UX... the event edit window appears fine...

CalIcsParser.jsm:157
Calendar: ParserError: invalid line (no token ";" or ":") "\n"'ParserError: invalid line (no token ";" or ":") "\n"' when calling method: [calIICSService::parseICS]

...when parsing the attached event converted from email... not sure the \r\n are properly converted during parsing/conversation to an event...

...additional error after that...

uncaught exception: ParserError: invalid line (no token ";" or ":") "\n" CalIcsParser.jsm:154:39
    parseString resource:///modules/CalIcsParser.jsm:154
    addTargetCalendarItem resource:///modules/CalDavCalendar.jsm:919
    endElement resource:///modules/caldav/CalDavRequestHandlers.jsm:983
    _walk resource:///modules/caldav/CalDavRequestHandlers.jsm:112
    AsyncFunctionNext self-hosted:807

The above appears after clicking on Convert To > Event, before Save event which generate the PUT request to the server...

Hope that help.

Convert Mail to Event (Termin) tested wwith Thunderbird

• Release 102.3.0 (64-Bit) ,
• Beta 106.0b2 (64-Bit),
• Daily 107.0a1 (2022-09-28) (64-bit)

could not convert any plain text mail or html mail to event.

(In reply to Robert Hartmann from comment #9)

Convert Mail to Event (Termin) tested wwith Thunderbird

• Release 102.3.0 (64-Bit) ,
• Beta 106.0b2 (64-Bit),
• Daily 107.0a1 (2022-09-28) (64-bit)

could not convert any plain text mail or html mail to event.

Just test with older version: Tb 91.13.1 32bit
conversion mail to event worked.

Debugging the issue in TB 105.0b4 (64-bits), it seems all \r disappear from the DESCRIPTION at some point after you hit the Save & Close button in the Event edit window which triggering network requests/responses... at the following line of code possibly...

resource:///modules/caldav/CalDavRequestHandlers.jsm

51  doc = parser.parseFromString(this._xmlString, "application/xml");

The DOMParser.parseFromString strip the \r from the xmlString, so some correction may need to be applied afterwards to keep the \r in the xmlString... to get properly keep \r\n (CRLR) return...

... indeed it seems indicated somewhere in...

resource:///modules/CardDAVDirectory.jsm

    /**
    * Ensure that `string` always has Windows line-endings. Some functions,
    * notably DOMParser.parseFromString, strip \r, but we want it because \r\n
    * is a part of the vCard specification.
    */
844 function normalizeLineEndings(string) {
      if (string.includes("\r\n")) {
        return string;
      }
      return string.replace(/\n/g, "\r\n");
    }

But I don't see where after that in the code the correction may be applied at a later point, as some \r do re-appear in the PUT request but stripped for some of them of the \n ending up with just \ or \r\ or \n in the DESCRIPTION part... instead of proper \r\n everywhere...

I noticed the following peace of code that may apply some correction... but haven't been able to identify content of data due to debugger error at this point (data: "Javascript error: resource://devtools/client/debugger/src/utils/context.js, line 36: Error: Current tread has paused or resumed")

resource://devtools/client/framework/browser-toolbox/Launcher.jsm

403   const lines = data.split(/\r\n|\r|\n/);

The code at line 51 does not seems affected by changes applied in Bug 1607834... so either the bug is not related to this bug... or I may be mistaking in my investigation somewhere... missing something perhaps...

Just my two cents input...

Alternatively issue could be coming from the below code when the Convert To > Event is triggered to open the converted Event in the Edit window before pressing the Save & Close...

resource:///components/calItemBase.js

482  this.mProperties.set(aName, aValue);

When setting the aName = DESCRIPTION the code/function above somehow also generate and set automatically the icalString value on the event item (as in this.icalString ; visible via <prototype> expand in Debugger) which is likely the value used in the PUT request later on...

The problem is that the icalString value end up contains strings like the below, which does not look right...

(...)
rd\\,\r\\n\r\\nRe***REDACTED***an\r\n y to***REDACTED***m.\r\\n\r\\nCa***REDACTED***rks\\, Mic\r\n ros***REDACTED***s\\, Zo***REDACTED***ay.\r\\n\r\\nPlea***REDACTED***em\r\n ail***REDACTED***pnir.\r\n co.***REDACTED***pt \r\n be***REDACTED***y.\r\\n\r\\nPa***REDACTED***ly\r\\n\r\\n\r\\n\r\\nTh***REDACTED***u f\r\n or y***REDACTED***ny.\r\\n\r\\n\r\\n\r\\nYo***REDACTED***n \r\n for***REDACTED***ge.\r\\n\r\\n\r\\n\r\\nIf you\r\n r em***REDACTED***e eve\r\n nt\\, plea
(...)

I have not found the function that generate that code... it does not appear triggered when using the Debugger... Though I can clearly see the value being modified at the step above. Might be auto-set via an event perhaps, upon setting the DESCRIPTION property value.

Regards,

I found a workaround that fixed the problem for me. At least on the case I could reproduce. Which may be different from Kevin (indeed no PUT request error at my end).

It turns out in my case that the issue is with multiple colon ':' present in the description of the event.

Basically after Convert to > Event, in the Event edit Windows, in the Description if I replace all the : (colon) by another character let say the letter 'd', when I press Save and Close it works, the item is properly saved to the server... and in my calendar.

So in my case, the problem is the presence of colon ':' in DESCRIPTION that are not properly escaped when items DESCRIPTION is converted to icalString... or not parsed correctly afterwards...

: colon is indeed a separator for the iCal key:value pair... so maybe it interfere somehow...

The escape mechanism may need review as it may depends on the iCal format version in use... not one-fit-all case...
https://evertpot.com/escaping-in-vcards-and-icalendar/

(In reply to Richard Leger from comment #8)

Fyi, I also just noticed in 105.0b4 (64-bit) on Windows that the issue does not affect all emails... but with the one affected (ms365 exchange msg), the following error appears in the console at my end... without showing any error in the TB UI/UX... the event edit window appears fine...

CalIcsParser.jsm:157
Calendar: ParserError: invalid line (no token ";" or ":") "\n"'ParserError: invalid line (no token ";" or ":") "\n"' when calling method: [calIICSService::parseICS]

In my case, with : (colon) in description, when I click Save & Close, the item seems added to the calendar to the server (as I said no PUT request invalid in my case) but with just the first line of description ("Hi Richard,"), but none of the instance are appearing in my TB calendar... no error shown in the UI/UX to end-user. Silently fails. So if you do not check the item is not in your calendar you would not realise that something went wrong when saving the item and you would miss the event because it is not showing up. Not good for use in organisations :-)

The full error exception in console appears as:

uncaught exception: ParserError: invalid line (no token ";" or ":") "\n" CalIcsParser.jsm:154:39
    parseString resource:///modules/CalIcsParser.jsm:154
    addTargetCalendarItem resource:///modules/CalDavCalendar.jsm:919
    endElement resource:///modules/caldav/CalDavRequestHandlers.jsm:983
    _walk resource:///modules/caldav/CalDavRequestHandlers.jsm:112
    AsyncFunctionNext self-hosted:807
    (Async: async)
    _walk resource:///modules/caldav/CalDavRequestHandlers.jsm:94
    handleResponse resource:///modules/caldav/CalDavRequestHandlers.jsm:59
    onStopRequest resource:///modules/caldav/CalDavRequestHandlers.jsm:865
    onStopRequest resource:///modules/caldav/CalDavRequest.jsm:554

Calendar: ParserError: invalid line (no token ";" or ":") "\n"'ParserError: invalid line (no token ";" or ":") "\n"' when calling method: [calIICSService::parseICS] when parsing
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
(...)

Hope that make sense.

Hi Kevin,

(In reply to Kevin Locke from comment #0)

5. Right-click on the draft in the Drafts folder, then click Convert To->Event...
6. Click the "Save and Close" button to save and close the event.

What if you edit manually the Description of the event (eg Add a letter into it for example) after step 5 but before step 6, then "Save and Close", does your event then get saved correctly and appears in TB calendar?

Regards,

After further testing... with different emails that are affected...

(In reply to Richard Leger from comment #13)

Basically after Convert to > Event, in the Event edit Windows, in the Description if I replace all the : (colon) by another character let say the letter 'd', when I press Save and Close it works, the item is properly saved to the server... and in my calendar.

It appears that any kind of edit in the DESCRIPTION (eg adding one simple letter) within the Event edit Windows (that appear when clicking on Convert To > Event) cause the item to save properly in the calendar on the server and in TB.

Looking at the difference between the PUT request it seems the DESCRIPTION is not encoded the same way in both cases...

Item that fails (without editing manually the description) is encoded as below:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
(...)
DTSTART;TZID=Europe/London:20220929T170000
DTEND;TZID=Europe/London:20220929T210000
DESCRIPTION:Hi Richard\,
\n
\n 
(...)

The same item that succeed (with manual editing of the description before saving) is encoded as below:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
(...)
DESCRIPTION;ALTREP="data:text/html,%3Cbody%3EHi%20Richard%2Ca%3Cbr%3E%3Cbr%
 3E%20%3Cbr%3E%3Cbr%3EI%20need

(In reply to Kevin Locke from comment #0)

Steps to reproduce:

1. Configure a mail account. (Any type.)
2. Subscribe to a network calendar. (Type can be iCalendar or CalDAV. Offline Support on or off.)
3. Create a draft email message in plain text format (e.g. by holding Shift when clicking the Write button), with a subject, where the body contains at least 2 lines. For example:
   Subject: Solstice Party
   Body:
   Solstice party at my house, 2021-12-21 8:00pm.
   Refreshments will be provided.
4. Save and close the draft.
5. Right-click on the draft in the Drafts folder, then click Convert To->Event...
6. Click the "Save and Close" button to save and close the event.

I can reproduce in 105.0b4 (64-bit) following the steps provided by Kevin (in Comment 0) but I don't get the PUT request invalid, just the same parse error issue:

17:12:56.153
uncaught exception: ParserError: invalid line (no token ";" or ":") "\nRefreshments will be provided." CalIcsParser.jsm:154:39
    parseString resource:///modules/CalIcsParser.jsm:154
    addTargetCalendarItem resource:///modules/CalDavCalendar.jsm:919
    endElement resource:///modules/caldav/CalDavRequestHandlers.jsm:983
    _walk resource:///modules/caldav/CalDavRequestHandlers.jsm:112
    AsyncFunctionNext self-hosted:807
    (Async: async)
    _walk resource:///modules/caldav/CalDavRequestHandlers.jsm:94
    handleResponse resource:///modules/caldav/CalDavRequestHandlers.jsm:59
    onStopRequest resource:///modules/caldav/CalDavRequestHandlers.jsm:865
    onStopRequest resource:///modules/caldav/CalDavRequest.jsm:554
17:12:56.154 Calendar: ParserError: invalid line (no token ";" or ":") "\nRefreshments will be provided."'ParserError: invalid line (no token ";" or ":") "\nRefreshments will be provided."' when calling method: [calIICSService::parseICS] when parsing
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20220929T161212Z
LAST-MODIFIED:20220929T161221Z
DTSTAMP:20220929T161221Z
UID:b35eb840-015c-43da-acf6-d11140fdb78a
SUMMARY:TEST19 Solstice Party
DTSTART;TZID=Europe/London:20220929T180000
DTEND;TZID=Europe/London:20220929T220000
DESCRIPTION:Solstice party at my house\, 2021-12-21 8:00pm.
\nRefreshments 
 will be provided.
URL:mid:d68644d7-3c95-bd2f-3a2b-ee0a6bf144bc@supporting-role.co.uk
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-P1D
DESCRIPTION:Default Mozilla Description
END:VALARM
END:VEVENT
END:VCALENDAR

If I edit the manually the DESCRIPTION prior saving... it works ok... the PUT request shows the description was html encoded instead.

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20220929T161809Z
LAST-MODIFIED:20220929T161821Z
DTSTAMP:20220929T161821Z
UID:2ebaec19-fdb9-40da-96d9-ce8b3f99913d
SUMMARY:TEST20 Solstice Party
DTSTART;TZID=Europe/London:20220929T180000
DTEND;TZID=Europe/London:20220929T220000
DESCRIPTION;ALTREP="data:text/html,%3Cbody%3ESolstice%20party%20at%20my%20h
 ouse%2C%202021-12-21%208%3A00pm.%0A%3Cdiv%3ERefreshments%20will%20be%20prov
 ided.%3Cbr%3E%0AOk%3C%2Fdiv%3E%0A%3C%2Fbody%3E":Solstice party at my house\
 , 2021-12-21 8:00pm.\nRefreshments will be provided.\nOk\n
URL:mid:d68644d7-3c95-bd2f-3a2b-ee0a6bf144bc@supporting-role.co.uk
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-P1D
DESCRIPTION:Default Mozilla Description
END:VALARM
END:VEVENT
END:VCALENDAR

Both are valid iCal VCALENDAR objects according to https://icalendar.org/validator.html

Fyi, I still see parse error in TB 106.0b4 (64-bit) on Windows when my caldav calendar is loading at startup...
As per errors appearing in console, it seems the first past calendar item affected by this bug may have been created on 10th August 2022 in my case (from an email via the Convert To > Event).

CalIcsParser.jsm:155
Calendar: ParserError: invalid line (no token ";" or ":") "\n"'ParserError: invalid line (no token ";" or ":") "\n"' when calling method: [calIICSService::parseICS] when parsing
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
(...)
CREATED:20220810T144246Z
LAST-MODIFIED:20220810T144328Z
(...)
END:VCALENDAR

The same error appear also if I try again to convert email into an event.

Testing with Outlook CalDav Synchronizer, I just noticed sync is also chocking on the same event item with error upon loading the calendar:

line 30:1: expecting "END", found '\n'

As you would see in attachment, when creating the event on 10th August 2022, the DESCRIPTION was not properly encoded when Convert To > Event had been triggered on an email and item had been saved without further editing the pre-set DESCRIPTION (email body content) at the time.

LineFeed character (LF) seems not properly encoded in the .ical text file event and appear as "\n" text instead... causing not all line to end with the proper CRLF code at the end... as you would naturally expected in a Windows encoded text file.

Hope that make sense and help identify a fix for this issue.

That explains why TB is chocking on the item during parsing when loading the calendar.
So the issue is not linked to the parser itself but to the function that convert email to event which does not properly escape/encode characters in DESCRIPTION when creating the event or the save function afterwards... hard to tell...

WORKAROUND:
The workaround that works for me is to edit manually the description to force it to be properly encoded (onchange) before saving the item. May not work in all circumstances but works for me in TB Beta 105/106 branches.

In addition of fixing this bug, TB dev team would have a to find a way to fix existing "broken" event items that may have been created by TB on the server (no error showing upon saving) but no longer appearing in the TB calendar...because item cannot be read/parsed... like my sample item here attached. The mess generated may need some clean-up of bread crumbs :-)

Fyi, still happening in TB 107.0b4 (64-bit), Message > Convert To > Event still not appearing in TB Calendar unless you think about editing the Description manually which is rarely the case when converting from a message. Still fails silently :-(

(In reply to Kevin Locke from comment #0)

This causes some CalDAV servers (e.g. Radicale) to reject the update because CR is not permitted in TEXT values, except as part of line folding. (See Section 3.3.11 of RFC 5545.)

Here's the updated RFC link:
3.3.1 Property value data types: Text (wrt escaping)

3.1 Content lines (wrt line folding)

For ease of access, here's the description part of the malformed PUT request generated by Thunderbird, extracted from attachment 9296405 [details].

As pointed by others on this bug, the DESCRIPTION seems to have escaping problems, e.g. ...line1\r\\nline2... which iiuc should just be ...line1\nline2....

I think the problem may be that DESCRIPTION is not encoded/escaped the same way when you create a new event directly in Calendar compared to when you Convert to > Event from an email msg. I tried to look at the code, but I could not find the culperit that caused the difference of encoding of the DESCRIPTION value. Likely it does not go through the same encoding function in the two different cases... also the original value parsed is text (text field) in first case versus html (body content) in second case (containing both \n\r and <br />) but maybe considered wrongly as just text or further parsed incorrectly, resulting in difference of encoded value in CalDAV format? Hope that make sense what I am saying...

Thanks much Richard Leger and Kevin Locke for providing more information and analysis.

• Screenshot attachment 9298476 [details] of comment 20 does show the problem quite clearly: CR (without LF) for folding lines is clearly malformed according to RFC (see comment 22).
• Richard's comment 11 and comment 12 have started to track this in the code, looks plausible that something seems to go wrong with string parsing.

Let's confirm this (per comment 9, comment 21) and raise the severity.

Not being able to convert messages to an event in an RFC-conforming CalDAV calendar does constitute a high-impact issue without satisfactory workaround imo.

Fyi, in TB 110.0b3 (64-bit) when using Convert To > Event on an email, I end up with the following text in Description instead of the email body content:

--_006_DB8PR01MB5564E12D556EB0A0E99E8704AEEB9DB8PR01MB5564eurp_--

Trying on another email I get something like:

--------------3NPTq0WQsgK129TC1pRB80Bl--

--------------U6T0S7XDOaazYNha00yjWJlM--

So something remain wrong somewhere with the Convert To > Event feature...