Creating/editing events no longer works for Fastmail

[ben.boeckel]

I recently updated to 3.3.4-ose from F-Droid. Now I get 403 Forbidden when trying to sync with new or edited events.

The error is “Failed iTIP restrictions for X property. Expected zero or one instances of the property and got 2”. Looking through the event that is being posted, I don’t see 2 instances of anything not in separate BEGIN and END blocks. The only X entries are inside of a VTIMEZONE block:

X-LIC_LOCATION:America/New_York
X-PROLEPTIC-TZNAME:LMT

I’m using Etar to manage the calendar locally, but it hasn’t changed recently.

[rfc2822]

Hi,
Can you please post the whole exception + VEVENT.

[rfc2822]

I could verify that. Yes, those lines seem to cause the 403. Do you have an idea why?

[gugu]

I see a similar issue, although not with the FastMail backend. I think there may be a regression: davx at version 3.3.3-ose work correctly, and you confirmed that it fails at 3.3.4-ose. Thank you.

[rfc2822]

@gugu said in Creating/editing events no longer works for Fastmail:

I see a similar issue, although not with the FastMail backend.

But with which one?

I think there may be a regression: davx at version 3.3.3-ose work correctly, and you confirmed that it fails at 3.3.4-ose. Thank you.

I’d like to know why these two lines cause servers to return 403 instead of randomly patching them out of the new timezone definitions (DAVx4 3.3.4 includes ical4j 3.0.20 which comes with updated timezone definitions).

[Isak Alexander]

I too have this issue with the error code 403.

[Дилян Палаузов]

Cyrus Imap/Fastmail use libical to validate, whether the uploaded data is valid. libical says, rather unintentionally, that at most one X- property can be set in the VTIMEZONE component.

This is addressed at https://github.com/libical/libical/pull/446 .

[rfc2822]

Thanks for finding this out.

Recently I’m working on generating the sent VTIMEZONEs from the Android time zone definitions instead of the ical4j ones (for various reasons), but there’s no time for that now. So I guess patching those X- lines out will be the most efficient solution for the next release (and of course it’s always a client issue and users expect the client to be fixed).

(Luckily, this particular problem does not affect Google Play users, because Google has locked them to 3.3.3 for an unknown amount of time, and 3.3.3 still uses ical4j 3.0.19.)

[rfc2822]

Should be worked around with https://gitlab.com/bitfireAT/ical4android/-/commit/267765611efdeb610493851d72f60d629ba8dc01.

I’ll prepare a 3.3.5 soon.

[rfc2822]

(Discussion about RFC 7809 moved to another thread.)

[ben.boeckel]

I can confirm that 3.3.5 from F-Droid no longer has this issue. Thanks for the quick turnaround!