Interner Serverfehler beim Synchronisieren des Kalenders (Axigen 8.2.0)

Hallo,

ich habe schon seit längerer Zeit immer wieder Probleme beim Synchronisieren von Terminen des Kalenders mit Hilfe der
Thunderbird-Erweiterung Lightning. Hierzu findet man auch schon seit Jahren unzählige Hinweise in verschiedenen Foren.

Heute konnte ich dann endlich ein Szenario finden, in dem der Server (Axigen 8.2.0 unter openSUSE 11.4 x86_64) den
entsprechenden Request von Lightning wie folgt beantwortet:

HTTP/1.1 500 Internal server error
Date: Sun, 25 Jan 2015 17:25:22 GMT
Server: Axigen-iCal
Pragma: no-cache
Allow: GET, PUT
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Connection: Close

In den Logfiles des Mailservers sind keinerlei Auffälligkeiten festzustellen. Die mit der TCP-Verbindung
korrespondierenden Zeilen in everything.txt lauten:

01-25 18:25:11 +0100 08 mailserver WEBMAIL:00000047: [192.168.16.41:80] connection accepted from [192.168.8.65:54929]
01-25 18:25:11 +0100 08 mailserver WEBMAIL:00000047: ICAL account 'andreas@schweigstill.de' has logged in
01-25 18:25:22 +0100 08 mailserver WEBMAIL:00000047: ICAL account 'andreas@schweigstill.de' has logged in
01-25 18:25:22 +0100 08 mailserver WEBMAIL:00000047: ICAL account 'andreas@schweigstill.de' has logged in
01-25 18:25:22 +0100 08 mailserver WEBMAIL:00000047: Account "andreas@schweigstill.de": iCal data uploaded, id: 0E636B
01-25 18:25:22 +0100 08 mailserver WEBMAIL:00000047: connection closed with [192.168.8.65:54929]

Dieses Verhaltens lässt sich reproduzieren, indem entweder ein neuer Termin in Lightning angelegt oder ein schon vorhandener
Termin modifiziert wird. Lighning meldet hierbei "MODIFICATION_FAILED".

Vor einigen Jahren (und entsprechend älteren Axigen- und Lightning-Versionen) hatte ich schon einmal festgestellt, dass diese
Blockade der Kalendersynchronisation durch ungültige UTF8-kodierten Zeichen verursacht werden konnte. Damals war es jedoch
wohl auf einen Fehler in Lightning zurückzuführen.

Da ich annehme, dass irgendein Datenmuster in meiner main.ics-Datei zu dem Fehler führt, wäre es sicherlich
hilfreich, diese Datei bereitzustellen. Ich möchte sie jedoch nicht hier öffentlich hochladen, da darin auch vertrauliche Termin
enthalten sind.

Mit freundlichen Grüßen,
Andreas Schweigstill

Ich habe mittlerweile doch recht viele Tests mit verschiedenen ICS-Dateien durchgeführt, welche ich dann mittels
"curl -u test1:test1 -T main.ics http://mailserver/ical/main.ics" auf einen Testaccount hochgeladen habe. Hierbei
habe ich die folgenden "Besonderheiten" des Axigen-Servers festgestellt:

1. Eine ICS-Datei muss mindestens eine Zeitzonendefinition enthalten, auch wenn keiner der VEVENT/VTODO-
Einträge eine Zeitzone benötigt.

2. Ein VEVENT/VTODO-Eintrag muss ein DTSTAMP-Feld enthalten. RFC 2445 ist hierbei in sich inkonsistent. In Kapitel 4.6.2
steht:

; the following are optional,
; but MUST NOT occur more than once




class / completed / created / description / dtstamp /
dtstart / geo / last-mod / location / organizer /
percent / priority / recurid / seq / status /
summary / uid / url /

Wohingegen in Kapitel 4.8.7.2 steht:

Property Name: DTSTAMP




Purpose: The property indicates the date/time that the instance of
the iCalendar object was created.




Value Type: DATE-TIME




Property Parameters: Non-standard property parameters can be
specified on this property.




Conformance: This property MUST be included in the "VEVENT", "VTODO",
"VJOURNAL" or "VFREEBUSY" calendar components.

Einige der in meiner nicht funktionsfähigen großen ICS-Datei aufgeführten Termine besitzen keinen DTSTAMP-Eintrag
und führen somit zu Fehlern. Sämtliche Termine wurden entweder per Axigen Webmailer oder per Thunderbird
Lightning angelegt. "Problematische" Einträge sind aber vorrangig durch Akzeptieren von per E-Mail zugesandten
Einladungen entstanden, insbesondere bei schlecht konfigurierten Exchange/Outlook-Umgebungen mit zum Teil
sehr kreativen Zeitzonendefinitionen.

Insgesamt ist die Situation äußerst unbefriedigend, dass sich solche von Axigen nicht akzeptierten Einträge im
Kalender befinden können. Insbesondere führt dies dazu, dass Axigen nicht mit seiner eigenen ICS-Datei umgehen
kann. Ich habe dies verifiziert durch Herunterladen mittels "curl" und sofortigem Hochladen, ebenfalls mittels "curl".
Dadurch ist auszuschließen, dass ein Kalender-Client irgendwelche Änderungen an der ICS-Datei vorgenommen hat.

Axigen sollte zumindest aussagekräftige Fehlermeldungen erzeugen können, falls eine ICS-Datei nicht konform sein
sollte. Sofern ein Eintrag sauber mittels "BEGIN:" und "END:" abgegrenzt ist, was eigentlich immer der Fall ist, sollte
Axigen solch einen einzelnen Eintrag ignorieren, aber nicht die gesamte ICS-Datei. Da Axigen ja per Definition auch
die E-Mail-Adresse des Benutzers kennt, könnte ein Fehlerbericht mit dem fehlerhaften Eintrag an den Benutzer
geschickt werden, so dass der Eintrag auch nicht unbemerkt verschwinden kann.

Als Workaround, um fehlerhafte Einträge schneller eingrenzen zu können, werde ich mir ein Shellskript bauen, welches
täglich die main.ics herunterlädt und per Subversion versioniert. Dadurch kann ich wesentlich schneller die entsprechenden
Einträge suchen als mit Hilfe des Vollbackups unseres Mailservers.