Startseite : "Dachboden" : Alte FAQs : MTQ

Mailtraq für Fortgeschrittene.

Diese FAQ wird nicht mehr gepflegt.

Vorbemerkung

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


Inhalt:

1. Generelles
1.1. Sicherheit, auch auf Dialup-Systemen
1.2. "Automated Skripting"
1.3. Einfache Headermanipulation
2. Modifikation der Message-ID (für News)
2.1. Theorie
2.2. Praxis
3. Mailinglisten in lokale Newsgroups gaten
3.1. Lokale Newsgroup anlegen.
3.2. Eingehende Mailinglisten-Mails dort einsortieren.
3.3. Postings in die lokale Gruppe an die Mailingliste weiterschicken.
4. Credits

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 Mißbrauch 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äßt sich unter den User-Properties für jeden User (und für Gäste) einstellen, mit welchem Paßwort er Zugriff auf den Newsserver erhält und elche 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 Paßworts.

Ü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, daß 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 Mißbrauchsgefahr. 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

nur ein Skript zu definieren, das via "Automated Scripting" ausgeführt wird, und in dem alle Operationen mit ein-/ausgehender Mail/News zusammengefaßt 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 muß 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 muß dem Absender des Postings "gehören", d.h. dieser muß 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 muß 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 muß sichergestellt werden, daß 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, daß 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, daß man einen FQDN (für die rechte Seite) hat oder benutzen darf (logisch).

Das Skript muß 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.

Als Beispiel: local.mtq@ancalagon.rhein-neckar.de

Das folgende Beispiel geht davon aus, daß 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.

Als Beispiel: mtq@lists.rhein-neckar.de


4. Credits

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

Diese FAQ wird nicht mehr gepflegt.