Sendmail and dual-stack IPv6

We’ve been using IPv6 for a few years, but for various reasons we hadn’t yet prepared our sendmail MTAs to use the new protocol. We run a dual-stack environment, so all servers need to use both IPv4 and IPv6. According to sendmail’s documentation it should be possible to use the host name for both daemons, so initially we tried it like that in our .mc file:

DAEMON_OPTIONS(`Name=MTA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Name=MTA-v6,Family=inet6,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
CLIENT_OPTIONS(`Name=MSA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=h')
CLIENT_OPTIONS(`Name=MSA-v6,Family=inet6,A=smtp-out.rrz.uni-koeln.de,M=h')

That worked fine on a test system, but for reasons unknown it failed on our actual production server. It resulted in these error messages:

Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon MTA-v6: cannot bind: Address already in use
Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: daemon MTA-v6: problem creating SMTP socket
Mar 23 10:35:39 smtp-out.rrz.uni-koeln.de sendmail[6662]: NOQUEUE: SYSERR(root): opendaemonsocket: daemon MTA-v6: server SMTP socket wedged: exiting

We have now implemented a workaround: instead of the hostname we use the actual IPv6 address for the IPv6 daemon and client:

DAEMON_OPTIONS(`Name=MTA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=fh')
DAEMON_OPTIONS(`Name=MTA-v6,Family=inet6,A=IPv6:2a00:a200:0:12::25,M=fh')
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
CLIENT_OPTIONS(`Name=MSA-v4,Family=inet,A=smtp-out.rrz.uni-koeln.de,M=h')
CLIENT_OPTIONS(`Name=MSA-v6,Family=inet6,A=IPv6:2a00:a200:0:12::25,M=h')

One more tip: with an IPv4-only setup we used the ‚b‘ flag (use the incoming interface for sending the message) as modifier for the DAEMON_OPTIONS, but with dual-stack that doesn’t work: if you receive a message via IPv4 but have to send it via IPv6 (or vice versa), it will fail.

Prüfung von Sicherheitszertifikaten

Die Prüfung der von Servern verwendeten Zertifikate hinsichtlich ihrer Gültigkeit  und Vertrauenswürdigkeit ist heutzutage ein elementarer Bestandteil der persönlichen Sicherheit im Internet. Viel zu oft werden solche Hinweise zwar einfach weggeklickt, spätestens bei Shops, die die Angabe der Konto- oder Kreditkartendaten erfordern, und erst recht beim Online-Banking sollten aber wirklich alle Internetnutzer misstrauisch werden, sobald der Browser eine entsprechende Warnung anzeigt.

Aus diesem Grund ist auch die Uni Köln seit Jahren einer Certificate Authority angeschlossen, die in allen gängigen Browsern und Mailclients als vertrauenswürdig bekannt ist, namentlich der Root-CA der Deutschen Telekom. Denn auch an der Uni müssen z.T. sehr vertrauliche Daten über das Netz geschickt werden, z.B. Prüfungsergebnisse, Accountdaten oder auch E-Mails.

Umso wichtiger ist es, dass die entsprechende Prüfung der gemeldeten Sicherheitszertifikate möglichst automatisiert und zuverlässig erfolgt. Hierfür gibt es ein eigenes Netzprotokoll, das „Online Certificate Status Protocol“ (OCSP). Es prüft automatisch die Gültigkeit des vom aufgerufenen Server gesendeten Zertifikates. Dies ist leider nicht bei allen Browsern und Mailclients korrekt voreingestellt. Zum Teil wird nur auf den Servernamen geprüft, zum Teil aber auch gar nicht. Wir möchten daher hier für die wichtigsten Programme kurz beschreiben, wo die korrekten Einstellungen vorzunehmen sind.

Mozilla Firefox / Mozilla Thunderbird
Bei den beiden Mozilla-Programmen finden sich die Einstellung in einem übersichtlichen Menü unter „Einstellungen“ → „Zertifikate“ → „Validierung“.

Google Chrome
In Chrome muss unter „Einstellungen“ → „Erweiterte Einstellungen anzeigen“ → „HTTPS/SSL“ ein Häkchen bei „Serverzertifikate auf Sperrung prüfen“ gesetzt werden.

Internet Explorer / Windows Mail / Outlook
Alle drei sind fest mit dem Windows-Zertikatspeicher verbunden, den man im Internet Explorer unter „Extras“ → „Internetoptionen“ → „Inhalte“ → „Zertifikate“ erreicht (die Menüfolge mag in den verschiedenen Versionen etwas anders sein). OCSP wird von Windows erst seit Vista – und damit auch in Windows 7 und 8 – unterstützt, für XP fehlt die Funktion leider. Die Aktivierung erfolgt in „Extras“ → „Internetoptionen“ → „Erweitert“ und umfasst die Einstellungen „Auf gesperrte Zertifikate überprüfen“ und „Auf gesperrte Zertifikate von Herausgebern überprüfen“.

Apple Safari
Safari nutzt den zentralen Schlüsselbund von MacOSX. Diesen erreicht man in der Regel über das Anwendungsmenü im Bereich „Utilities“ oder „Werkzeuge“. Innerhalb des Schlüsselbunds kann man im Menü „Einstellungen“, Karteireiter „Zertifikate“ die passenden Einstellungen wählen. In aller Regel ist dies bei OCSP und CRL jeweils „Bester Versuch“, die Priorität sollte auf OCSP liegen.

Opera
In Opera (ab Version 9) muss man den Umweg über die Seite „about:config“ im Browser gehen. In den „Security Prefs“ kann man den Eintrag bei „OCSP Validate Certificates“ ändern. Da dieser aber standardmäßig aktiviert ist, muss man in der Regel nichts ändern.

Perl-Modul SAVI-Perl mit aktueller Sophos-Version für Linux verwenden

Wir betreiben neben Ironport für die zentralen Mailserver noch eine weitere Anti-Spam- und Anti-Viren-Infrastruktur als „Altlast“ für Institute, die keinen LDAP-Server betreiben. Dort wird als Anti-Virus-Software seit vielen Jahren ClamAV und Sophos Antivirus eingesetzt. Für Letzteres musste jetzt ein Update installiert werden, weil die alte Version demnächst nicht mehr unterstützt wird. Sophos wird bei uns mit dem Perl-Modul SAVI-Perl in amavisd-new eingebunden. Das ging nach dem Update zunächst nicht mehr, obwohl ich das Modul gegen die neue Sophosversion gebaut hatte. Die Ursache ist, dass sich der Pfad der .vdl- und .ide-Dateien geändert hat. Zwar kann man SAVI-Perl beim Kommando load_data diesen Pfad übergeben, aber (unsere Version von) amavisd-new unterstützt das nicht. Die einfachste Lösung war deshalb ein symbolischer Link vom aktuellen Pfad /opt/sophos/lib/sav auf den bisherigen Pfad /opt/sophos/sav.

Viele Wege führen nach Rom – oder zur automatischen Konfiguration

Seit geraumer Zeit bietet das RRZK eine automatische Konfiguration des Mailkontos für Thunderbird und Outlook an. Damit entfällt für Smail- und UNI-Accounts im Regelfall das lästige Nachschlagen von zu verwendeten Servernamen und -einstellungen. Welche Schritte hinter den Kulissen notwendig sind, um diesen Service zu erbringen, und welche Fallen Microsoft den Implementieren ihres Verfahrens in den Weg gelegt hat, ist Gegenstand dieses Artikels.

Ein Mailprogramm für den Abruf eines bestimmten Mailkontos zu konfigurieren ist nicht immer leicht, besonders in Zeiten, in denen die Verwendung mehrerer unterschiedlicher Mailadressen für verschiedene Zwecke fast schon zum guten Ton gehört. Da ist es mitunter schwierig, den Überblick zu behalten über die an den verschiedenen Stellen erforderlichen oder möglichen Einstellungen und man ist schon sehr froh, dies typischerweise nur genau einmal machen zu müssen. Die auf den RRZK-Webseiten abrufbaren ausführlichen Anleitungen zur Konfiguration verschiedener Mailclients sind ein Zeugnis dieser vielfach als zu kompliziert empfundenen Prozedur.

Diesem Umstand haben verschiedene Anbieter von Mailclients in letzter Zeit Rechnung getragen, indem sie eine erleichterte Konfiguration ermöglichen – wenn auch leider jeder auf seine eigene Art. In jedem Fall wird damit die Einrichtung eines Mailkontos zum Kinderspiel: die gleichen Angaben, die man üblicherweise auch zur Anmeldung in einem Webmailer verwendet, also Mailadresse und Passwort, reichen aus, und schon funktioniert alles wie von Geisterhand. Doch damit das so einfach klappt, sind natürlich im Hintergrund einige dienstbare Geister erforderlich. Für die technisch Interessierten beschreibe ich daher im Folgenden, wie die seit einer Weile am RRZK verfügbare automatische Konfiguration für die weit verbreiteten Mailprogramme Thunderbird (ab Version 3.1) und Outlook (ab Version 2007) funktioniert. Wie nicht anders zu erwarten gibt es darüberhinaus natürlich noch weitere Ansätze zur automatischen Konfiguration von Mailkonten, z.B. auf dem iPod/iPad/iPhone, um die es hier aber nicht gehen soll.

Autoconfig für Thunderbird

Im Mozilla-Umfeld ist die automatische Konfiguration unter dem Begriff Autoconfiguration (oder kurz Autoconfig) bekannt. Ursprünglich mit Thunderbird 3.0 eingeführt, hat sich die Spezifikation mit Thunderbird 3.1 weiterentwickelt und dabei inzwischen ein nach meiner Ansicht recht brauchbares Stadium erreicht. Zwar wird weiterhin an Erweiterungen gearbeitet, die die Software in bestimmten Umfeldern noch besser einsetzbar machen, und der eine oder andere Fehler steckt auch noch im Konfigurationsassistenten, aber insgesamt macht diese nützliche Funktion schon einen sehr brauchbaren Eindruck.

Doch wie funktioniert die automatische Konfiguration bei Thunderbird überhaupt? Zunächst einmal wird aus der eingegebenen Mailadresse der Domainname, also der Teil rechts vom @-Zeichen, extrahiert. Dieser kann dann verwendet werden, um in einer vom Mozilla-Projekt betriebenen Datenbank nachzuschlagen, ob dort ein Eintrag mit Konfigurationsdaten für diesen Mailanbieter vorhanden ist. Das ist natürlich typischerweise nur bei sehr großen, weltweit tätigen Mailanbietern der Fall. Mit den so gewonnenen Informationen kann Thunderbird dann die Mailservereinstellungen von alleine vornehmen und versuchen sich mit dem eingegebenen Passwort beim Server anzumelden. Voraussetzung dafür ist jedoch, dass zum Login auf dem Server ebenfalls die Mailadresse (oder der sog. Localpart, der Teil links vom @ in der Mailadresse) verwendet wird. Das ist jedoch am RRZK nicht immer der Fall. Hier erfolgt die Anmeldung stets mit dem Benutzerkennzeichen und dieses kann – jedenfalls dann, wenn für den Account ein Alias angelegt wurde – nicht direkt aus der Mailadresse abgeleitet werden.

In diesem Fall ist es also etwas komplizierter. Um die automatische Konfiguration dennoch zu ermöglichen, betreibt das RRZK einen Server speziell für diesen Zweck, der von Thunderbird abgefragt werden kann. Über passende DNS-Einträge wird der Server von Thunderbird gefunden, und mittels der bei der Abfrage übermittelten Mailadresse ist der Konfigurationsserver seinerseits in der Lage, das hierzu passende Benutzerkennzeichen herauszufinden und dies – zusammen mit den zu verwendenden Servernamen und den Sicherheitseinstellungen – zurück an Thunderbird zu schicken. Auf diese Weise erhält also jeder Benutzer eine individuell für sein Benutzerkennzeichen angepasste XML-Datei vom Konfigurationsserver, wodurch diese komfortable Einrichtung des Mailkontos ermöglicht wird. (Neben den beiden zuvor genannten Möglichkeiten versucht Thunderbird im Notfall übrigens auch noch, die Servernamen zu erraten, indem bei einer Mailadresse foobar@example.com einfach häufig genutzte Namen wie mail.example.com ausprobiert werden, jedoch kann dieser Ansatz systembedingt beim RRZK-Mailservice nicht zuverlässig funktionieren.)

Autodiscover für Outlook

Auch Microsoft möchte es den Benutzern seiner Software besonders leicht machen und hat bereits seit der Version 2007 in Outlook eine automatische Konfiguration von Mailkonten vorgesehen, die den Namen Autodiscover trägt. Nicht nur Verbindungen zu den Microsoft-eigenen Exchange-Servern können damit automatisiert konfiguriert werden, sondern auch solche zu „normalen“ Mailservern nach den gängigen Internet-Standards (SMTP, POP, IMAP). Liest man die von Microsoft hierzu publizierte Spezifikation durch und vergleicht sie mit der des Mozilla-Projekts, so denkt man auf den ersten Blick „Hut ab!“, denn das Microsoft-Dokument erscheint wesentlich durchdachter. Beispielsweise wird auch das Thema Fehlerbehandlung darin genau abgehandelt, was bei dem Mozilla-Ansatz eher schlicht-pragmatisch nach dem Motto „wenn der Login nicht klappt merkt man ja, dass ein Fehler vorliegt“ gehandhabt wird.

Leider verflüchtigt sich dieser gute Eindruck schnell, wenn man sich intensiver mit dem Thema befasst. So ist es beispielsweise bei Outlook 2007 nicht mit Hilfe der Autodiscover-Funktion möglich, das Programm dazu zu bewegen, eine mittels StartTLS verschlüsselte Verbindung zum Postausgangsserver aufzubauen, obwohl das Programm diese Funktionalität sehr wohl beinhaltet (über die normale Benutzeroberfläche kann dies mit wenigen Mausklicks eingestellt werden). Während bei anderen Softwareherstellern ein solch offensichtlicher Fauxpas sicherlich bald mit einem Update auskuriert würde, hält man dies bei Microsoft offenbar nicht für nötig und behebt diesen Fehler erst in der kostenpflichtigen Nachfolgerversion Outlook 2010. Aus Programmierersicht lästig ist sicherlich auch der Ansatz, für die Übergabe eines einzelnen Parameters, nämlich der Mailadresse, gleich eine ganze XML-Datei mitzuschicken (darüber haben sich andere bereits ausgelassen), wenn auch letztlich nur konsequent, da Microsoft damals offenbar ganz und gar auf dem HTTPS-XML-Trip war – inzwischen bevorzugt man in Redmond offenbar SOAP.

Fast noch ärgerlicher als dieser Fehler ist jedoch die Art und Weise, wie die Verfügbarkeit von StartTLS bei der XML-Konfiguration von Microsoft kommuniziert wird. Liest man sich die Hinweise auf dieser Microsoft-Webseite durch, die von sich selbst behauptet, für die Version 2010 überarbeitet worden zu sein, so erfährt man nichts über die neu hinzugekommene Möglichkeit mittels des Encryption-Tags eben doch StartTLS angeben zu können. Erst an anderer Stelle sind die hoffentlich richtigen Informationen dann zu finden. Und weil zwei verschiedene Varianten noch nicht reichen, gibt es auch noch eine dritte Website bei Microsoft, die den Informationen auf den ersten beiden widerspricht, denn hier wird in diesem Beispiel das Error-Element als Kind des Account-Elements beschrieben, was es gemäß des veröffentlichten XML-Schemas (oder auch des Beispiels für eine XML-Antwort im Fehlerfall) hingegen nicht ist. Microsoft wäre jedoch nicht Microsoft, wenn man dort drei Dokumente bräuchte, um sich selbst zu widersprechen: Nein, schon innerhalb eines Einzelnen findet man zum Thema Autodiscover widersprüchliche Aussagen. So ist im Abschnitt 2.2.3.2.2 der zuvor genannten zweiten Spezifikation die Rede davon, Unterstützung für das RedirectUrl-Tag sei zwingend vorgeschrieben (MUST-Requirement), während wenige Zeilen später im Abschnitt 2.2.3.2.4 daraus ein SHOULD-Requirement wird.

Übertroffen wird diese Schlamperei nur noch durch die Implementierung der Spezifikation in Outlook selbst. Denn die zuvor lobend erwähnten Informationen im Fehlerfall, etwa wenn aufgrund eines Tippfehlers in der vom Benutzer angegebenen Mailadresse der Konfigurationsserver signalisiert, dass für diese Adresse keine automatische Konfiguration erfolgen kann, wertet Outlook nicht etwa aus oder zeigt die Fehlermeldung dem Benutzer an, nein, stattdessen wird einfach versucht die richtigen Einstellungen per Guessmart zu raten, was in diesem Fall natürlich zum Scheitern verurteilt ist und dem Benutzer stattdessen eine unklare Fehlermeldung beschert. Dass das Microsoft-Produkt im Gegensatz zu praktisch jeder anderen Mailsoftware auch nicht in der Lage ist, den Realm für eine DIGEST-MD5-Authentifizierung korrekt auszuhandeln (in Microsofts eigenem Jargon unter „SPA“ subsumiert) ist dann nur noch das Tüpfelchen auf dem i.

Während der grundsätzliche Ablauf der automatischen Ermittlung bei beiden Verfahren gleich ist (Ermitteln des Konfigurationsservers, Anfrage mit der zu konfigurierenden Mailadresse abschicken, XML-Datei empfangen), so besteht ein gewichtiger Unterschied zwischen der Autoconfig-Funktion von Thunderbird und dem Autodiscover von Outlook darin, dass beim Autodiscover standardmäßig eine per SSL verschlüsselte Verbindung zum Einsatz kommt. Dies macht es erforderlich, für jede Maildomain einen eigenen Webserver mit passendem Zertifikat zu betreiben, wenn nicht bei jedem Aufruf erst einmal eine Warnmeldung erscheinen soll. Aus diesem Grund ist die automatische Konfiguration für Outlook am RRZK auch nur für uni-koeln.de und smail.uni-koeln.de verfügbar, im Gegensatz zur automatischen Konfiguration von Thunderbird, die darüberhinaus auch für virtuelle Maildomänen verfügbar ist.

2.2.3.2.2

Thunderbird-Addons für “Profis”: Nostalgy

Teil 2 der Reihe Thunderbird Addons für Vielbenutzer

Mail, die man nicht archivieren möchte kann man einfach aus der Mailbox mit der Taste „D“ löschen und landet danach am Anfang der nächsten Email. Auf diese Art lässt sich eine volle Mailbox schnell duchlaufen und reduzieren. Leider geht das mit Mail, die man aufheben will nicht so leicht. Um Email zur Archivierung in Unterordner zu verschieben, muss man meist zur Maus greifen, was häufg lästig ist.

Mit dem Addon Nostalgy kann man auch diese Aufgabe bequem auf das Keyboard verlegen. Das lohnt sich insbesondere, wenn man viele Email bekommt, die man lediglich lesen und anschließend archivieren muss. (Die Möglichkeit, diese dann gleich per Filter in die passenden Ordner sortieren zu lassen, habe ich persönlich als nicht sinnvoll empfunden. Was bereits im Archivordner liegt liest man meistens gar nicht mehr…). „Thunderbird-Addons für “Profis”: Nostalgy“ weiterlesen

Thunderbird-Addons für „Profis“: Quicktext

Da es für Thunderbirds eine schier unübersichtliche Menge AddOns gibt, stelle ich mal die drei vor, die ich persönlich am wenigsten missen möchte:

Quicktext erlaubt es Antworten „aus der Dose“ direkt im Entwurfsfenster von Thunderbird einzufügen.

Wenn man konsequent immer wiederkehrende Antworten als Template abspeichert, spart man nach einer Weile eine ganze Menge Arbeit. Interessant ist hier auch das Feature, dass man in den Templates Variablen einfügen kann, an deren Stelle z.B. Namen des ursprünglichen Schreibers, Datum oder der Inhalt der Zwischenablage eingefügt werden kann.

Wie funktioniert das?

„Thunderbird-Addons für „Profis“: Quicktext“ weiterlesen

Phishers Fritz

… fängt frische Phishe.

Derzeit sind wieder Phishing-Mails im Umlauf, die gezielt Passwörter von Nutzern der Uni Köln abphishen wollen. Hintergrund ist, dass mit Hilfe der Passwörter Spamkampagnen geskriptet über das Webmail-System der Uni gefahren werden können. Das ist kürzlich bereits einmal gelungen. Wir haben das Problem recht schnell erkannt und den geknackten Account temporär gesperrt, aber die Gefahr ist damit nicht grundsätzlich gebannt. Und es beweist, dass es immer wieder leichtgläubige Opfer gibt. Ein einziges reicht ja schon, um potenziell viel Schaden anzurichten.

Das größte Problem bei solchen Spam-Wellen ist aus unserer Sicht, dass die Reputation der Uni sinkt – sowohl die reale als auch die virtuelle. Mit Letzterem meine ich, dass Mailserver der Provider nur noch gedrosselt von uns Mail annehmen, bzw. wir im schlimmsten Fall auf sog. Blacklists landen und gar keine Mail mehr von uns angenommen wird. Beides ist in der Vergangenheit schon vorgekommen.