Server

CalDav Invitations trotz Baikal

Im Internet sind immer wieder Beschwerden darüber zu finden, dass mit einer Baikal-Instanz als Kalender-Server keine Einladungen an Personen geschickt werden kann, was Google-Mail, Outlook und Konsorten allerdings von Haus aus mitbringen. Auch der kostenlose Mail-Client Thunderbird kann, zusammen mit dem kostenfreien Lightning-Kalender-Plugin, solche Mails verschicken, aber eben nur so lange, bis Termine zu einem mit Baikal sychronisierten Kalender hinzugefügt werden sollen.

Studiert man die Bugtracker des Baikal-Repositories genauer, so schlagen immer wieder Nutzer einen Trick vor, der allerdings in der aktuell von Baikal verwendeten Version von Sabre/dav (das Backend hinter Baikal) überhaupt nicht mehr funktioniert:

$caldavPlugin = new \Sabre\CalDAV\Plugin();
$caldavPlugin->setIMipHandler(
new \Sabre\CalDAV\Schedule\IMip('no-reply@example.org')
);
$server->addPlugin($caldavPlugin);

Diese Erweiterung funktioniert in den aktuelleren Versionen nicht mehr!

Um nun doch erfolgreich Mails mit Einladungen senden zu können, bedarf es eines Tricks, damit Baikal den verwendeten Clients nicht mehr vorgaukelt, Einladungen verschicken zu können. Genau das ist nämlich das Problem: Die Clients (in meinem Fall Thunderbird) denken, die Einladung wird von Baikal versendet, was aber gar nicht passiert. Um die Mails lokal von der verwendeten Software senden zu lassen reicht es aus, das Scheduling-Paket von Baikal zu deaktivieren.

Dazu einfach in der Datei Server.php unter <baikal-root>/Core/Frameworks/Baikal/Core/ die Zeile 171 auszukommentieren:

# $this->server->addPlugin(new \Sabre\CalDAV\Schedule\Plugin());

Nach dieser kleinen Änderung werden die Mails zur Einladung einfach lokal durch die verwendeten Clients abgesendet und verarbeitet. Klar sollte an dieser Stelle allerdings sein, dass das Ganze nicht so komfortable wie eine durch den Server verwaltete Variante ist, da so die Antworten auch durch eben jene Clients verarbeitet werden müssen.

Interessant an der ganzen Geschichte ist allerdings, dass laut diesem Kommentar das ganze Scheduling-Plugin erst für Baikal 2 geplant war.

Read More

Postfix reject/Relay access denied

Postfix NOQUEUE: reject: RCPT 450 4.1.1 Recipient address rejected unverified address Connection refused

oder auch:

The mail system <mail>: host mail.xyz.de[xxx.xxx.xxx.xxx] said: 554 5.7.1 <mail>: Relay access denied (in reply to RCPT TO command)

Beim Aufsetzen eines Mail-Servers mit Postfix bekam ich es immer wieder mit dem Problem zu tun, dass Postfix Mails “rejectet“, die eigentlich völlig korrekt zugestellt werden sollten. Ausgangslage war ein System auf einem vServer, das zwei Domains mit einem Mail-Service ausstatten sollte. In meinem Fall war die Haupt-Domain eine xyz.org und die Zweit-Domain xyz.de. Alle Postfächer der org-Domain sollten auf der de-Domain als Aliase vorhanden sein und einfach nur die Mails an die Haupt-Domain weiterleiten. Merkwürdigerweise bekam ich immer den o.g. Fehler, wenn ich versuchte eine Mail mit der de-Domain zu verarbeiten.

Die Lösung zu dem Problem fand ich nach einschlägiger Recherche auf der Seite von  Usman Majid, der unter https://usman.dk/ einen IT-Blog betreibt:
Fügt man in die Config von Postfix eine neue Domain hinzu und konfiguriert diese, so muss der Cache danach geleert werden. Hier reicht ein einfaches Neustarten des Dienstes nicht aus! Standardmäßig passiert das alle 12h, möchte man es von Hand starten reichen folgende Befehle:

/etc/init.d/postfix stop # stoppt den postfix-dienst
 rm -fr /var/lib/postfix/verify_cache.db # loescht die cache-Datei
 /etc/init.d/postfix start # startet den postfix-dienst wieder
Read More