Neues aus der Server-Ecke

von Peter Marksteiner (Ausgabe 00/2, Juni 2000)

 

Wo ist die Mail vom vergangenen Jahr?

Automatische Archivierung bei zu großer Inbox

Im Artikel Pop Art (Comment 99/1, Seite 25) wurde beschrieben, welche Folgen es haben kann, wenn in Mailprogrammen die Einstellung Mail auf dem Server lassen aktiviert ist: Diese Einstellung sorgt dafür, daß auch bereits gelesene Nachrichten in der Inbox verbleiben; auf dem Mailserver ist aber jede Inbox als eine Datei in einem dafür vorgesehenen Plattenbereich, dem Mail Spool, gespeichert. Wenn alte Nachrichten nie gelöscht werden und ständig neue eintreffen, so wird diese Datei im Laufe der Zeit immer größer und größer. Auch wenn Sie nur eine einzige neu eingelangte Nachricht lesen wollen, muß die gesamte Inbox, die vielleicht hunderte alte Nachrichten enthält, vom Mailserver geholt werden. Das Übertragen solcher Riesendateien dauert sehr lange, belastet den Server und gelingt manchmal überhaupt nicht (POP timeout). In den öffentlichen PC-Räumen der Universität Wien gibt es noch ein zusätzliches Problem: Beim Öffnen der Mail mittels MS-Outlook wird die Inbox auf die H:-Platte kopiert; wenn dabei die Plattenplatzbeschränkung (Disk Quota) auf der H:-Platte überschritten wird, so können beim Schließen des Programms die Nachrichten nicht ordnungsgemäß abgespeichert werden.

Im Comment 00/1 wurde das schrankenlose Anwachsenlassen von Dateien im Mail Spool als eine der Sechs Methoden, sich unbeliebt zu machen bezeichnet, und es wurde angekündigt: Beschränkungen des Mail Spool in Form von Disk Quotas wird es auch in Zukunft nicht geben; es ist aber geplant, ältere Nachrichten, die eine bestimmte Größe überschreiten, automatisch zu archivieren. Diese automatische Archivierung ist nunmehr auf den zentralen Mailservern der Universität Wien (MAILBOX.UNIVIE.AC.AT und UNET.UNIVIE.AC.AT) in Betrieb und funktioniert folgendermaßen: Wenn eine Inbox eine gewisse Größe1) übersteigt, so verbleibt nur ein Teil der Nachrichten in der Inbox; der Rest wird archiviert, d.h. in mehrere handliche Teile zerlegt und in einem Verzeichnis namens /mailarch abgespeichert. Nachrichten, die kleiner als 10 Kilobyte sind (das sind die meisten Nachrichten ohne Attachment), bleiben auf jeden Fall in der Inbox, die übrigen werden so lange in chronologischer Reihenfolge - die ältesten zuerst - archiviert, bis die Inbox kleiner als das Limit ist.

Für Ihr Mailprogramm sind die archivierten Nachrichten nicht sichtbar, sie können aber direkt auf dem Mailserver in einer Unix-Shell gelesen oder bearbeitet werden. Beim Archivieren wird Ihnen per eMail eine vollständige Liste aller archivierten Nachrichten mit Absender, Datum und Subject geschickt, der auch zu entnehmen ist, in welcher Datei die jeweiligen Nachrichten zu finden sind. Wenn Sie nun beispielsweise aufgrund der Liste feststellen, daß die Datei Nr. 17 (der vollständige Name dieser Datei lautet dann für Mailbox-Benutzer z.B. /mailarch/horvatk7/17 und für Unet-Benutzer z.B. /mailarch/67/a1234567/17) eine Nachricht enthält, die Sie gern wieder hätten, so können Sie - nach dem Login auf dem für Sie zuständigen Mailserver und Aufruf der Unix-Shell - mit dem Befehl restore_mail 17 den Inhalt dieser Datei wieder in die Inbox zurückkopieren und nachher die darin enthaltenen Nachrichten wie gewohnt mit Ihrem eMail-Programm lesen.

Das Verzeichnis /mailarch befindet sich auf einem sogenannten HSM-Filesystem (Hierarchical Storage Management). Die Dateien scheinen zwar lokal auf dem Server zu liegen, sind aber in Wirklichkeit auf Band gespeichert. Deshalb gibt es beim Zugriff kurze Verzögerungen (üblicherweise weniger als fünf Minuten), bis der Bandroboter das entsprechende Band eingelegt hat. Es erscheint die Meldung ANS9238K Attempting to access remote file.

Neben der Option Mail auf dem Server lassen ist die häufigste Ursache für eine übergroße Inbox ein Nachsendeauftrag (Forward) mit der Option Kopien der weitergeleiteten eMails behalten. Vereinzelt sind diese Optionen sinnvoll und notwendig, in den meisten Fällen aber überflüssig. Bitte verwenden Sie solche Einstellungen nur dann, wenn Sie sie unbedingt brauchen. Auf dem Mailbox-Rechner bietet sich IMAP (siehe http://mailbox.univie.ac.at/imap.html) als Alternative an: Bereits gelesene Nachrichten können dann problemlos auf dem Server belassen werden, weil sie bei Verwendung von IMAP in wesentlich effizienterer Form abgespeichert werden.

Zentraler Mail-Exchanger

Im Artikel Mailserver? Nein, danke! (siehe Comment 99/3, Seite 15) wurde beschrieben, welche Schwierigkeiten beim Betrieb von Mailservern auftreten. Vor allem erfordern Mailserver ständige Wartung und Pflege, da immer neue Sicherheitslücken bekannt werden, über die Hacker in Mailserver eindringen oder Spammer ihre unerwünschten Werbesendungen in alle Welt verschicken können.

Leider scheint es fast unmöglich zu sein, alle Mailserver an der Uni Wien ständig "dicht" zu halten: Kaum ist eine Sicherheitslücke geschlossen, wird ein neues offenes Spam-Relay bekannt. Um dieses Problem endgültig zu lösen, wurde nun der zentrale Mail-Exchanger MX.UNIVIE.AC.AT installiert, der alle eMail-Nachrichten entgegennimmt und an die einzelnen Mailserver verteilt. (In Wirklichkeit verbergen sich aus Gründen der Lastverteilung und Ausfallssicherheit hinter dem Hostnamen MX.UNIVIE.AC.AT zwei Rechner; bei Bedarf können noch weitere dazukommen.)

Die Funktionsweise von Mailservern wurde im eingangs erwähnten Comment-Artikel beschrieben. Bisher gab es Nameserver-Einträge (MX-Records), die z.B. die Information enthielten, daß für Mail an die Domain IHW.UNIVIE.AC.AT der Mailserver ASTERIX.IHW.UNIVIE.AC.AT zuständig ist. Diese MX-Records wurden nun durch Einträge ersetzt, die auf MX.UNIVIE.AC.AT zeigen. Dadurch nimmt zuerst der zentrale Mail-Exchanger die Nachrichten entgegen und leitet sie dann mit Hilfe seiner Mailertable an den zuständigen Mailserver weiter - in unserem Beispiel an ASTERIX.IHW.UNIVIE.AC.AT.

Für die Anwender von Mailservern hat sich dadurch nichts geändert: Alle eMail-Adressen funktionieren unverändert weiter, da bestehende MX-Records automatisch übernommen wurden. Für die Betreiber von Mailservern wird die Last der Verantwortung etwas leichter: Demnächst wird im zentralen Router ein Filter definiert werden, sodaß der SMTP-Port von außerhalb der Uni Wien nicht mehr zugänglich ist. Dadurch werden die Server vor Attacken auf diesem Port geschützt. Trotzdem sollten Sie die Wartung Ihrer Mailserver nicht vernachlässigen!

Einige Rechner im Datennetz der Uni Wien - vor allem Unix-Workstations - dienen als Mailserver, obwohl bis jetzt kein entsprechender MX-Record existiert. Die Postmaster aller dieser Rechner werden per eMail verständigt; die erforderlichen MX-Records und Mailertable-Einträge werden erstellt, sobald eine Antwort eintrifft. Falls ein Postmaster nicht in angemessener Zeit reagiert (sei es, weil er seine Mail nicht liest oder weil es die eMail-Adresse POSTMASTER@HOST, obwohl sie laut RFC 822 existieren muß, gar nicht gibt), kann aufgrund der oben erwähnten Router-Filter an diesen Server keine Mail von außerhalb der Uni Wien zugestellt werden.

Weitere aktuelle Informationen finden Sie unter http://data.univie.ac.at/mx/; Anfragen und Wünsche betreffend MX-Records richten Sie bitte an die eMail-Adresse MX@UNIVIE.AC.AT.

DATA.UNIVIE.AC.AT

Ein Secure Server für die Uni Wien

Wenn Sie vor kurzem Ihr Unet- oder Mailbox-Paßwort geändert haben,2) hat Ihnen Ihr Browser vermutlich eine Meldung wie Sichere Verbindung oder You have requested a secure document geschickt - eines der wenigen sichtbaren Anzeichen dafür, daß vor einiger Zeit an der Uni Wien ein neuer, "sicherer" Webserver in Betrieb genommen wurde: Der Server DATA.UNIVIE.AC.AT dient vor allem der Webanbindung von Datenbanken und unterstützt das Übertragungsprotokoll Secure HTTP, bei dem der gesamte Datenaustausch zwischen Server und Client (dem Browser) verschlüsselt wird. Ein mit Secure HTTP übertragenes Dokument erkennt man daran, daß sein URL mit https beginnt (z.B. https://data.univie.ac.at/unet/passwd.html).

Wichtig ist diese Verschlüsselung vor allem zum Schutz von Paßwörtern - sollte jemand versuchen, an irgendeinem Punkt zwischen Server und Client den Netzverkehr abzuhören, kann er mit den erlauschten Informationen nicht viel anfangen, sofern er nicht über die Ressourcen von besseren Geheimdiensten verfügt. Alle WWW-Formulare, die Paßwort-Abfragen enthalten, werden daher nach und nach von den anderen Webservern der Uni Wien (WWW.UNIVIE.AC.AT, WWW.UNET.UNIVIE.AC.AT, MAILBOX.UNIVIE.AC.AT) abgesiedelt und auf Secure HTTP umgestellt. Dennoch kann der neue Webserver auch über das "gewöhnliche", unverschlüsselte HTTP-Protokoll angesprochen werden. Das wird bei Paßwort-Eingaben zwar nicht empfohlen (es erscheint eine Warnung und die Aufforderung, Secure HTTP zu verwenden), aber manchmal geht es nicht anders - einige Browser, z.B. Lynx, unterstützen kein Secure HTTP.

Kryptisierung ist aber nicht der einzige Vorteil des Secure Server: Er hat auch ein sogenanntes Zertifikat vorzuweisen, eine Art von digitaler Unterschrift, die sicherstellt, daß der Eigentümer des Servers wirklich der ist, der er zu sein behauptet. Anerkannte Zertifikate3) werden von Organisationen vergeben, die zuvor eine Reihe von Nachweisen verlangen. (So hätte beispielsweise die Universität Wien unter anderem ihre Gründungsurkunde vorlegen sollen; auf unser Angebot, eine Abschrift der Urkunde Herzog Rudolfs IV. vom 12. März 1365 - siehe http://www.univie.ac.at/archiv/rg/2.html - anfertigen zu lassen, wurde dann aber doch verzichtet.) Details über das Zertifikat werden vom Browser unter dem Menüpunkt Sicherheit bzw. bei Klick auf das Schlüssel-Symbol angezeigt.

Die bisher unter http://www.univie.ac.at/UNI-Daten/ verfügbaren Datenbanken wie das Online-Personal-, -Instituts- und -Vorlesungsverzeichnis werden ebenfalls auf den Server DATA.UNIVIE.AC.AT übersiedelt - allerdings ohne Secure HTTP (eine Suche im Personalverzeichnis ist wohl kaum besonders schützenswert). Damit ist dann auch das Problem gelöst, daß von manchen Providern und Firmennetzen aus die Datenbanken nicht abgefragt werden können: Auf WWW.UNIVIE.AC.AT wird dafür ein Non-Standard Port verwendet, der des öfteren von Proxies und Firewalls nicht zugelassen wird. Auf dem neuen Webserver wird ausschließlich der Standard-Port 80 verwendet, sodaß die Datenbanken dann überall zugänglich sind.

 

1) Das Limit liegt bei 40 MB für Mailbox-Benutzer bzw. 20 MB für Unet-Benutzer, wobei letzteres eine Zeitlang überschritten werden kann: Erst wenn nach zweimaliger Verständigung und Ablauf von sieben Tagen die Inbox noch immer zu groß ist, wird archiviert.

2) Wenn nicht, tun Sie es bitte bei Gelegenheit: Von Zeit zu Zeit das Paßwort zu ändern ist eine gute Vorsichtsmaßnahme!

3) Es gibt nicht allzu viele Firmen auf der Welt, deren Zertifikate von den großen Browser-Herstellern anerkannt werden. Die bekannteste ist Verisign; wir haben uns für die südafrikanische Firma Thawte entschieden.