Jediblog

Dieses ist mal wieder so eine Woche. Man hätte Montag gründlich auflisten können, was alles schief gehen kann und Sonntag würde man sehen, dass die Liste doch nur ein Ausschnitt aus der Realität ist.

Wenigstens bleibt so etwas aber nicht ohne Lerneffekt:

• Deaktiviere keine Dienste von Windows, ohne genau zu wissen, wofür sie zuständig sind und welche Dienste von Ihnen abhängig sind, wofür diese wiederum zuständig sind, welche Dienste von diesen wiederum abhängen…
  Denn: Es kann passieren, dass die Performance des Rechners sich durch diese Maßnahme verbessert und dass die Soundausgabe nebenbei nicht mehr funktioniert. Der Windows-Audio-Dienst hängt nämlich von der Windows-Audio-Endpunkterstellung ab und diese hängt wiederum von einem anderen Dienst ab, der aber nicht näher benannt wird. Schlecht ist jedenfalls, wenn der RPC-Server nicht gestartet werden kann. Einen Dienst, der so heißt, gibt es selbstverständlich nicht, doch mehr erfährt man aus der Fehlermeldung auch nicht.
• Wenn man doch Dienste von Windows deaktiviert, ohne genau zu wissen, wofür sie zuständig sind [... wir hatten das schon], dann sollte man vorher die Liste der Dienste exportieren. Zumindest Windows 7 bietet eine entsprechende Funktion an. So kann man später im Zweifel alle Dienste, die vorher aktiviert waren, wieder aktivieren.
• Wenn man nicht vorher die Liste der Dienste exportiert hat, war das ein Fehler. Aber wozu hat man Mitbewohner mit dem gleichen Betriebssystem auf ihrem Rechner.

• Eine .exe-Datei, die gar nicht allzu kompliziert ist, die ohne Installation auskommt und eigentlich nur eine Netzwerkverbindung aufbaut, kann auf einem Rechner mit Windows XP SP 3 funktionieren, auf einem anderen nicht. Natürlich erscheint auch hier die passende Fehlermeldung:

Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren.

• Noch einmal: Das Programm kommt ohne Installation aus, es besteht nicht einmal die Möglichkeit einer Installation. Die Konfiguration wird nach dem Programmstart zum ersten Mal vorgenommen.

• Wenn Mailinglisten über Mailman E-Mails mit dem Absender bla@sub.einedomain.tld verschicken, so sollte bla auch einen A-Record im Zonefile des zuständigen DNS-Servers besitzen. Sonst könnten verschiedene Mailserver auf böse Ideen kommen.

Mailman vs. Mailserver

Gegeben:
eine Domain www.einedomain.tld, eine Subdomain sub.einedomain.tld, eine Mailingliste liste@sub.einedomain.tld, konfiguriert mit Mailman, sowie eine Weiterleitung liste@einedomain.tld -> liste@sub.einedomain.tld.

Gewünschtes Verhalten:
Benutzer x mit E-Mail-Adresse x@eineanderedomain.tld schickt eine E-Mail an liste@einedomain.tld oder liste@sub.einedomain.tld. In beiden Fällen soll diese E-Mail an alle Abonnenten der Liste ausgeliefert werden. Als Absender (also im FROM-Header) soll x@eineanderedomain.tld erscheinen, die Antwortadresse (REPLY-TO-Header) soll die Adresse der Liste, also liste@sub.einedomain.tld sein.

Tatsächliches Verhalten:
Benutzer x, der eine Kopie seiner Nachrichten wünscht, empfängt die E-Mail und als Antwortadresse ist liste@sub.einedomain.tld eingetragen. So weit, so gut.
Benutzer y, ein anderer Abonnent der Liste, empfängt die E-Mail, die an seine Adresse y@einedrittedomain.tld geschickt wurde und sieht als Antwortadresse liste@www.einedomain.tld.

Was hat Benutzer y falsch gemacht? Nichts.

Was hat Benutzer x falsch gemacht? Auch nichts.

Was hat wurde bei der Einrichtung von Mailman falsch gemacht? Wieder nichts.

Wer ist dann Schuld?

Zum einen ist der DNS-Server, der für die Domain einedomain.tld (und alle ihre Subdomains) zuständig ist, so konfiguriert, dass für die Subdomain sub lediglich ein CNAME-Eintrag vorhanden war, der auf www gezeigt hat. Ein Fehler, denn:

Canonicalization: RFC-821 Section 3.1

The domain names that a Sender-SMTP sends in MAIL and RCPT commands MUST have been “canonicalized,” i.e., they must be fully-qualified principal names or domain literals, not nicknames or domain abbreviations. A canonicalized name either identifies a host directly or is an MX name; it cannot be a CNAME.

Zum anderen ist der Mailserver, der für einedrittedomain.tld zuständig ist, so konfiguriert, dass die Domains ankommender E-Mails nachgeschlagen werden und durch die Domain ersetzt werden, auf die sie verweisen (wenn sie nur einen CNAME-Eintrag haben). Der Mailserver verändert also den FROM-Header und den REPLY-TO-Header. Ob das sein muss, ist fraglich, da zumindest Mailserver existieren, die das nicht tun und diese nicht unbedingt als unbedeutend einzustufen sind (z.B. der Mailserver von Google).