Pre-FAQ: Mailtraq für Fortgeschrittene

Dieser Text befindet sich inhaltlich auf dem Stand des Jahres 1999 und wird nicht mehr gepflegt oder aktualisiert. Er ist in jeder Hinsicht veraltet und steht nur noch zu Dokumentationszwecken online.

Dieser Text wurde in der Newsgroup de.comm.software.mailtraq gepostet und wendet sich dementsprechend auch an die Leser dieser Newsgroup. Er wird hier unverändert veröffentlicht.

Vorbemerkung

Diese (Pre-)FAQ gibt den Stand vom 25.03.99 wieder und bezieht sich auf die Version 1.x von Mailtraq.

1. Generelles

1.1. Sicherheit, auch auf Dialup-Systemen

Mailtraq ist ein Mail- und Newsserver, auf den - natürlich - auch von außen zugegriffen werden kann. Insofern ist es unbedingt erforderlich, Sicherungen gegen Missbrauch einzurichten; auch dann, wenn ein Dialup-System nur dann und wann (oder zu festen Zeiten) online geht. Das gilt natürlich besonders, wenn man über keine dynamisch zugewiesene, bei jeder Einwahl wechselnde, sondern über eine statische IP-Nummer verfügt oder gar per Standleitung angebunden ist.

Soweit Mailtraq nur als lokaler Server genutzt werden soll und Mail per POP3 geholt wird, ist es dringend anzuraten, alle Services gegen Zugriff von außen zu sperren. Dies erfolgt über den Eintrag entsprechender (lokaler) IP-Nummern für jeden Service einzeln unter Options | Services.

Falls Zugriffsmöglichkeit von außen gewünscht oder erforderlich ist, müssen andere Sicherungsmöglichkeiten genutzt werden. Für den Newsserver lässt sich unter den User-Properties für jeden User (und für Gäste) einstellen, mit welchem Passwort er Zugriff auf den Newsserver erhält und welche Gruppen er lesen und beschreiben darf. Für den SMTP-Server ist eine wirklich relayfeste Konfiguration bisher nicht möglich. Zur Abhilfe können zwei SMTP-Server aufgesetzt werden. Der eine - zuständig für Empfang - lauscht auf dem Standard-Port 25, erlaubt Zugriffe von überall (Options | Services), nimmt aber Mail nur für lokale User an. Der andere - für ausgehende Mail - lauscht auf einem beliebigen freien Port, erlaubt Zugriffe nur von lokalen IP-Nummern und nimmt Mail für jedermann an. Der POP3-Server erlaubt für jedes Postfach die Angabe eines Passworts.

Über eventuelle Sicherheitslücken der HTTP- und FTP-Server ist mir bisher nichts bekannt; dennoch würde ich dazu tendieren, diese sicherheitshalber gegen externen Zugriff zu sperren, falls sie nicht wirklich benötigt werden.

Falls Mail2News-Gateways eingerichtet wurden, sollte man bedenken, dass jedermann auch von außen Mail an news.group.name@server.do.main schicken kann, die dann als Newsposting wieder herausgeht; das Muster, nach dem die Mailadressen der Gateways gebildet werden, ist ja bekannt. Das bedeutet eine nicht von der Hand zu weisende Missbrauchsgefahr. Abhilfe ist möglich, indem nur Mails mit einem bestimmten Keyword im Header an die Newsgroup durchgelassen werden; siehe dazu unten unter das entsprechene Skriptbeispiel.

1.2. "Automated Skripting"

Es empfiehlt sich, für jedes der vier Standard-Ereignisse

Inbound Mail Delivery
Outbound Mail Delivery
Inbound News Delivery
Outbound News Delivery

nur ein Skript zu definieren, das via "Automated Scripting" ausgeführt wird, und in dem alle Operationen mit ein-/ausgehender Mail/News zusammengefasst sind. Das erleichtert die Übersicht und Fehlersuche bei der Frage, was mit ein-/ausgehenden Mails und Postings alles passiert.

1.3. Einfache Headermanipulation

Mailtraq versieht auch Postings in Newsgroups mit den - eigentlich nur für Mail sinnvollen - Headern "To:" und "X-Hops:" (zur Loop-Erkennung). Da diese Header überflüssig sind, sollte man sie in ausgehenden Postings löschen. Das erledigt folgendes Skript, ausgeführt bei "Outbound News Delivery":

// Trigger: Outbound News Delivery
DeleteHeader("To");
DeleteHeader("X-Hops")

Auf diese Weise können auch zusätzliche Header eingefügt oder andere Header modifiziert werden. Denkbar wäre zum Beispiel "X-PGP-Key", eine Änderung oder das Löschen von "X-Newsreader", etc. - dem Spiel- und Experimentiertrieb sind hier keine Grenzen gesetzt. Man sollte allerdings ausreichende Kenntnisse über reservierte Header und deren Syntax besitzen und das Hinzufügen zusätzlicher Header nicht übertreiben; das kommt dem professionellen Auftreten und der Ernsthaftigkeit zugute.

Insbesondere hilfreich ist es, Mängel des verwendeten Newsreaders auf diese Art und Weise ausgleichen zu können, zum Beispiel "X-No-Archive: yes"- oder "Supersedes:"-Header zu setzen. Dafür können vorhandene, aber meist nicht genutzte Header wie "Distribution", "Keywords", "Summary" verwendet werden. Ein Skript kann prüfen, ob etwas in diesen Headern steht, und wenn ja, die erforderlichen neuen Spezial-Header ("Supersedes:", …) setzen und den zweckentfremdeten Header löschen. Somit ist das Patchen des Newsreaders (Stichwort "Agent-Tweak") nicht mehr erforderlich.

2. Modifikation der Message-ID (für News)

2.1. Theorie

Die Message-ID dient der eindeutigen Kennzeichnung eines Postings und muss daher mind. für den Zeitraum von zwei Jahren, besser noch "ewig", eindeutig sein. Sie besteht aus einer von einem @ in zwei Teile getrennten Zeichenfolge, wobei rechts vom @ ein sog. FQDN ("fully qualified domain name") und links eine innerhalb dieser (Sub-)Domain eindeutige Zeichenfolge zu stehen hat.

Der FQDN muss dem Absender des Postings "gehören", d.h. dieser muss zur Nutzung dieses Domainnamens berechtigt sein. Berechtigt ist, wer als Inhaber einer Domain (für *.de bspw. beim DE-NIC) registriert ist oder vom Inhaber einer Domain eine Subdomain zugewiesen bekommen hat. Ein Eintrag im DNS ist nicht erforderlich.

Ein Beispiel

T-Online ist Inhaber der Domain "t-online.de" und darf unterhalb dieser Domain beliebige Subdomains ("news.t-online.de", "gugelhupf.t-online.de", …) einrichten. Außerdem gestattet T-Online seinen Nutzern, für die Generierung von Message-IDs als FQDN teilnehmernummer.dialup.t-online.de, also z.B. 06221168783-0001.dialup.t-online.de, zu verwenden.

Die linke Seite der Message-ID muss so generiert werden, das eine Doppelvergabe ausgeschlossen ist. Sinnvollerweise sollte man also Datum und Uhrzeit zur Erzeugung dieses Teils verwenden - eine fortlaufende Nummer ist zu fehleranfällig. Außerdem muss sichergestellt werden, dass nicht zufällig zwei Systeme unabhängig voneinander dieselbe Kennung erzeugen, weil bspw. auf jedem zur gleichen Zeit gepostet wird. Dies geht am einfachsten, indem für jeden FQDN nur ein System Message-IDs erzeugt.

"Doppelte" Message-IDs führen dazu, dass Postings nicht richtig weiterverteilt werden (weil die Server ein Posting mit dieser ID schon haben und das neue nicht mehr annehmen) oder in Archiven wie http://groups.google.com/ nicht richtig gespeichert oder gefunden werden können.

2.2. Praxis

Die Message-IDs, die Mailtraq standardmäßig erzeugt, sind etwas unschön und "nur" fortlaufende Nummern. Das folgende Skript erzeugt "hübschere" Message-IDs, die auf der linken Seite (nach Wahl) aus einem festen Text, einer Abkürzung für die Newsgroup, in die gepostet wurde, und/oder Datum/Uhrzeit bestehen. Voraussetzung für die Anwendung ist, dass man einen FQDN (für die rechte Seite) hat oder benutzen darf (logisch).

Das Skript muss per "Automated Scripting" bei "Outbound News Delivery" ausgeführt werden. Es spricht nichts dagegen, eine ähnliche Variante auch für "Outbound Mail Delivery" zu verwenden.

// Trigger: Outbound News Delivery
// rechte Seite der Message-ID wird definiert
fqdn := "ancalagon.rhein-neckar.de";
// Kürzel wird definiert
// sollte nur statt des Gruppenkürzels (s.u.) verwendet werden
tag := "news";
// Datum und Uhrzeit wird in festgelegte Form gebracht
// optional z. B. auch datum := FormatDateTime("ddmmyyhhnns")
datum := FormatDateTime("dd-mm-yy.hh-nn-ss");
// Anfangsbuchstaben der ersten Newsgruppe werden ermittelt,
// z.b. de.admin.news.groups = d.a.n.g.
// Geht auch für alle Gruppen, macht die MID aber evtl. sehr lang!
gruppe := ListItem(Header("Newsgroups"),0);
initial := "";
i := 1;
While(
   Length(Params(gruppe,".",i)) > 0,
   do(
      initial := initial + SubStr(Params(gruppe, ".", i), 0, 1) + ".",
      i := i + 1
   )
);
// Laufnummer wird von Disk gelesen, um 1 erhöht und geschrieben
nummer := DBRead("Msg-ID-Counter", "counter", "news");
nummer := nummer + 1;
DBWrite("Msg-ID-Counter", "counter", "news", nummer);
// Hinweis:
// DBWrite() cached zuerst im Speicher und schreibt die neuen Werte nur
// mit Verzögerung auf die Platte; bei Abstürzen oder dem ordnungsgemäßen
// Herunterfahren des Servers gehen die letzten Änderungen evtl. verloren.
// Sicherer, allerdings umständlicher, ist daher das Schreiben in eine
// simple Textdatei
// Message-ID wird zusammengesetzt; die genaue Reihenfolge ist variabel
mid := "<" ++ tag ++ "." ++ initial ++ datum ++ "." ++ nummer ++ "@" ++ fqdn ++ ">";
SetHeader("Message-ID", mid)

Optional kann über UniqueString(), evtl. zusammen mit SubStr(), noch eine zufällige Zeichenfolge miteingebaut werden; das dürfte endgültig die Einmaligkeit der Message-ID sicherstellen. :-)

3. Mailinglisten in lokale Newsgroups gaten

Mailinglisten lassen sich als Newsgroup meist viel bequemer lesen: man hat die Mails geordnet beisammen, kann die Möglichkeiten moderner Newsreader zu Threading, Expire, Archivierung und die z.T. sehr ausgefeilten Filter-und Score-Files verwenden und kann per Knopfdruck wahlweise an die Mailingliste oder den Autor antworten, ohne manuell Adressen ändern zu müssen (solange die Mailinglisten-Software nicht jeder Mail ein Reply-To: an die Liste aufzwingt).

Und so gehts:

3.1. Lokale Newsgroup anlegen.

Praktisch ist z.B. local.<listenname> oder <eigene_(Sub)domain>.<listenname>.

Als Beispiel: local.mtq

3.2. Eingehende Mailinglisten-Mails dort einsortieren.

Mail2News-Gateway für diese Newsgroup aktivieren; Mailadresse ist <newsgroupname>@<hostname>.

Als Beispiel: local.mtq@ancalagon.rhein-neckar.de
Mit dieser Adresse auf der Mailingliste subscriben (sieht etwas unschön aus und führt dazu, dass evtl. auch private Mailantworten an die Adresse der lokalen Newsgroup gehen) oder an die "Hauptadresse" eingehende Mail durch Mailtraq an die Mailingliste umleiten. Letzteres geht unter Inbound Mail | Sorting. Dort einen neuen Eintrag definieren, der Mail von der Liste an die lokale Newsgroup umadressiert. Als Filterausdruck empfiehlt sich eine eindeutige Headerzeile, die nur in Mails von der Liste vorkommt; meist ist dies der von der Mailinglistensoftware automatisch erzeugte Sender:-Header.
Eventuell kann man noch mittels eines Skripts dafür sorgen, dass In-Reply-To:-Header in References:-Header umgewandelt bzw. an bestehende References angefügt werden. Dieses Skript muss dann bei "Inbound Mail Delivery" ausgeführt werden - und zwar nur dann, wenn die Mail an ein Mail2News-Gateway gerichtet ist.

Das folgende Beispiel geht davon aus, dass alle Mail2News-Gateways (und nur diese!) Adressen der Form local.*@hostname haben.

// Trigger: Inbound Mail Delivery
if(
 WildcardMatch(MsgGetRcpts(),"*local.*@hostname*"),
 do(
   referenz := "*" ++ Header("In-Reply-To"),
   if(
   not(WildcardMatch(Header("References"),referenz)),
   SetHeader("References",Header("References") ++ " " ++ Header("In-Reply-To"))
   )
 )
)

3.3. Postings in die lokale Gruppe an die Mailingliste weiterschicken.

News2Mail-Gateway für diese Newsgroup aktivieren und als Mailadresse sowie "To:"-Feld die Adresse der Mailingliste angeben.

Als Beispiel: mtq@lists.rhein-neckar.de
Falls die Message-ID für ausgehende Mail geändert wird, erscheinen die Postings doppelt: einmal sofort nach dem Posten (mit der von Mailtraq erzeugten Message-ID), und einmal später, sobald sie über die Liste und das Mail2News-Gateway wieder hereinkommen (mit der geänderten Message-ID). Am einfachsten verhindert man diesen Effekt durch ein Skript bzw. einen Trick, der Postings mit der durch Mailtraq erzeugten Standard-Message-ID (für lokale Gruppen) verwirft. Diese ist gekennzeichnet durch eine bestimmte, offenbar aus dem Domainnamen abgeleitete Zeichenfolge, die jeweils am Anfang der ID steht. Also definiert man per "Automated Scripting" ein neues Ereignis, das bei "Inbound News Delivery" ausgeführt wird. Außerdem wird ein Filter definiert, der nur Postings erfasst, die in eine lokale Newsgroup gehen ("Newsgroups" und local.*) und eine mit <ZZZZ (eben den charakteristischen Zeichen) beginnende Message-ID haben ("Message-ID" und <ZZZZ*). Schließlich wird "Handoff to script" angekreuzt, mit der Folge, dass ein durch den Filter erfasstes Posting verworfen wird. Die Angabe eines Scripts, das ausgeführt werden soll, ist gar nicht mehr erforderlich. Alternativ kann man auch in dem Skript, das die Message-ID für ausgehende Mail ändert, per If() das Überschreiben der Message-ID für Mails an die Mailingliste(n) abschalten.

4. Credits

Für wertvolle Hinweise und Ergänzungen vielen Dank an

Marc Langer
Manfred Polak