Arbeitskreis "sendmail hacking"
Leitung: Bernard Steiner vom Fachbereich Informatik der Uni Dortmund Bevor ich auf die Ergebnisse des Arbeitskreises komme, moechte ich auf ein paar ganz grundlegende Fragen eingehen, und damit etwas in die nicht unkomplexe Materie der Mailuebertragung auf heterogenen Netzwerken einfuehren. "Sendmail" - kann man das essen ??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Im allgemeinen nicht. Sendmail ist ein Programm, dessen Aufgaben klar werden, wenn man einen Ueberblick hat, wie die Mail auf UNIX-Systemen von Editor ins Netzwerk gelangt. Grundsaetzlich gibt es drei Stationen: Einen UA (User Agent), einen MTA (Message Transfer Agent) und einen Mailer. Der UA kann global galaktisch als Benutzerschnittstelle zum Mail-System bezeichnet werden. Er ermoeglicht das einfache Lesen und Verschicken der Mail, ohne dasz man die Syntax des MTA kennt (auf den ich gleich kommen werde) und ohne dasz man andere Unix-Befehle kennen musz. Es gibt mittlerweile sehr komfortable UA, die z.B. unter X-Windows laufen und das Mail-Handling fuer den Anwender sehr einfach gestalten. Ein weiterer, recht komfortabler UA waere z.B. "elm". Der MTA ist so eine Art Postamt, das die Adressen interpretiert und auf ein bestimmtes internes Format bringt. "sendmail" ist z.B. ein MTA. Wie ein richtiges Postamt hat "sendmail" noch einige andere Aufgaben, wie z.B. das Mail rerouting und die Message delivery und noch ein paar andere nette Kleinigkeiten. Zu guter Letzt bleibt noch der (oder die) Mailer uebrig, die den eigentlichen Transport der Mail ueber das Netzwerk uebernehmen. Es kann verschiedene Mailer auf einem System geben, da je nach Adressat eine bestimmte Uebertragungsart gewaehlt werden musz (z.B. TCP oder NCP). Fuer jede Uebertragungsmethode existiert ein eigener Mailer. Als User interessiert einen der Mailer relativ wenig, da dessen Auswahl unser elektronisches Postamt "sendmail" erledigt. Ist "sendmail" Lebensnotwendig oder nur ganz angenehm ??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "sendmail" ist eingentlich beides. In der Einleitung sprach ich von heterogenen Netzwerken, d.h. es sind viele verschiedenartige Netzwerke koexistent, man denke z.B. an ARPAnet und UUCP. So lange man sich Mail nur in einem Netzwerk bewegt, ist alles noch relativ einfach: Das Mailsystem kann einfache HOST/USER- NAME Adressen verwenden, um die Mail zu verschicken. Da die Verwaltungsformen unterschiedlich sein koennen, lassen wir sie der Einfachheit halber weg. Die Adressen haben eine bestimmte Syntax und die Semantik bleibt auch gleich. Schoen. Die Probleme fangen dann an, wenn die Mail zwischen zwei voellig ver- schiedenen Netwerken ausgetauscht werden soll. Dann kann es vorkommen, dasz so gut wie gar nichts mehr passt. Wenn man sich dieses Problems als Otto-Normal- Mailschreiber widmen muesste, wuerde man hoechstwarscheinlich mehr Zeit damit verbringen, das richtige Adressformat zu finden, als die Mail zu schreiben. An dieser Stelle setzt "sendmail" an und setzt die verschiedenen Adressformate der einzelnen Netzwerke in ein allgemeinverstaendliches um. Keine leichte Auf- gabe, wie man sich vorstellen kann, da es recht unterschiedliche gibt. In soweit ist "sendmail" lebensnotwendig. Aber "sendmail" macht dem Anwender auch das Leben etwas leichter. An dieser Stelle waere das bereits oben erwaehnte Mail-rerouting zu nennen. "sendmail" vereint drei verschiedne Arten des Reroutings in sich: Aliasing, Forwarding und Inclusion. Unter Aliasing ver- steht man das Umsetzen von Namen nach Adressen nach einer Liste. Forwarding ist das internetzwerkweite Umleiten von Mail. Ein Beispiel soll den praktischen Nutzen kurz erlaeutern: Angenommen ein Stuttgarter User ist auf einem Kon- gress in Berlin und ihm steht dort ein lokaler Host zur Verfuegung. Jetzt kann er seine Mail automatisch von Stuttgart nach Berlin umleiten lassen, auch wenn der Berliner Host nicht im selben Netzwerk eingebunden ist, wie sein Stutt- garter Host. Inclusion ist das weiterleiten von Mail an Adressen, die in einem bestimmten File stehen. Man kann so relativ einfach eingehende Mail an mehrere Leute (z.B. an ein ganzes Projekt-Team) verteilen. "sendmail" hat zudem auch noch andere, im parktischen Gebrauch recht nuetzliche Features, wie z.B. die Rueckleitung von Mail an den Absender im Falle eines Fehlers. "sendmail" hilft auch, die Kosten des Mailverkehrs drastisch zu senken. Man stelle sich vor, es wird wegen jeder Mail, die von irgendeinem User auf einem Host geschrieben wird, extra eine Telefonverbindung aufgebaut. "sendmail" unterstuetzt sogenanntes "Batching", worunter man sich ein "ansammeln" der Mail vorstellen kann, welche dann auf einen Rutsch versendet wird. Toll, und wie funktioniert "sendmail" eigentlich ??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nun, die Sache ist nicht trivial. Nach den Design-Zielsetzungen von "sendmail" soll das Programm nur in wenigen Faellen (z.B. wenn der Prozessortyp oder das Betriebssystem gewechselt werden soll) neu kompilliert werden muessen. Um dennoch ein hohes Masz an Flexibilitaet zu erreichen, greift "sendmail" beim Start auf ein Konfigurationsfile zu, das im Klartext auf der Platte steht. Wenn sich eine Aenderung (z.B. im Mail-Routing) ergeben sollte, kann die entsprechende Information dort geaendert werden. In diesem File (im Folgenden CF-File genannt) sind auch die Informationen abgelegt, die "sendmail" zur Adressumsetzung braucht. Dazu sind in diesem File um die 30 Regelsaetzte (sog. rulesets) untergebracht, mit denen das Routing festgelegt wird, welcher Mailer verwendet werden musz, und wie die Adressumsetzung nach de Breukelen Konvention geschieht und vieles andere mehr. Hier beginnen die Probleme fuer viele Mail-Administratoren. Die Rulesets sind recht kryptisch und nicht einfach zu verstehen. Wenn nun etwas geaendert werden soll, steht man vor recht groszen Problemen, da man kaum auf Anhieb weisz, was geaendert werden musz, um etwas bestimmtes zu erreichen. Ich moechte kurz mal so ein Ruleset als Beispiel anfuehren, wie es in real existierenden CF-File vorkommt, wobei ich aber an- merken will, dasz es sich um ein relativ kleines Exemplar handelt: ##################################################################### # Ruleset 21 -- recipient re-writing for smartuucp and etherm # ##################################################################### S21 # compress and Breukelen rule R$+ $:$>22$>29$1 Breukelen rule R$+@$- $@$1@$2.$U add .uucp R$+ $@$1 Uebrigens kann so ein Ruleset auch andere Rulesets aufrufen (gibt manchmal schoene Schleifen :-) ) und Makros koennen auch definiert werden. Auszer den rulesets sind im CF-File auch noch das Mail-Header-Format de- finiert und noch so ein paar Kleinigkeiten. Ich hoffe, ich konnte die Problematik der "sendmail"-Konfiguration etwas rueberbringen. Und was war jetzt in diesem Arbeitskreis los ??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nun, wie schon gesagt, es sollte hauptsaechlich um "sendmail" gehen. Leider war ich nicht von Anfang an dabei, da meine persoenliche Zeitplanung aufgrund einer ungeplanten Verlaengerung der Ruhephase zum Timing der Workshop-Leute divergent war, kurz: Ich hatte verpennt. Aber ich glaube trotzdem einen Ueberblick geben zu koennen, in was fuer einem Rahmen sich das ganze bewegt hat. Viele Arbeitskreisteilnehmer hatten weniger mit "sendmail", als vielmehr mit der Adressierung selber groeszere Probleme. Die Vielfalt der Adressierungs- moeglichkeiten in den verschiedenen Netzen hat trotz einer kurzen Einfuehrung am Vortag groeszere Verwirrung gestiftet. Vor allem mit der relativ neuen Domain-Adressierung [siehe Artikel ueber IP-Dienste von PI in dieser Ausgabe] standen nicht wenige auf Kriegsfusz, so dasz erst auf diesem Gebiet die Klar- heiten ausgeraeumt werden muszten. Die zweite groeszere Gruppe hoffte, in diesem Arbeitskreis die Erleuchtung in punkto CF-File und dessen Rulesets zu erlangen. Allerdings war es in der kurzen Zeit nicht moeglich, alle Moeglichkeiten und Meriten des CF-Files voll auszukosten. Aber dennoch wurde von Bernard Steiner ein recht guter Einblick in den Sinn der Rulesets gegeben und deren Wirkung an einem UNIX-Rechner, der zu Verfuegung stand, in der Praxis gezeigt. Richtige "Hacks" mit "sendmail" wurden nicht gezeigt, wohl aus mangel an Zeit. Aber das ist wohl das uebliche Problem bei solchen Arbeitskreisen: Der unter- schiedliche Level der Teilnehmer. Da dauert es einfach viel zu lange, bis alle auf etwa dem gleichen Niveau sind. Zwar wurden durchaus auch Hints fuer solche Leute gegeben, die schon etwas naeher mit der Materie "sendmail" vertraut waren, aber allgemein bewegte sich der Arbeitskreis mehr auf Einsteigerlevel. Wer mehr ueber "sendmail" und Mailsysteme unter UNIX wissen will, dem sei die einschlaegige Dokumentation empfohlen. term%complx@nadia.UUCP ------------------------------------------------------------------------------