UUCP steht für Unix-to-Unix-Copy. Es ist ein relativ altes, aber flexibles Protokoll. UUCP bietet die Möglichkeit, Dateien von Rechner zu Rechner zu übertragen und Kommandos auf entfernten Rechnern auszuführen. In diesem Sinne ist der Remote-Shell oder der Secure-Shell vergleichbar, aber UUCP verlangt keine Internetverbindung zwischen den beteiligten Rechnern, sondern lagert die Aufträge zwischen und führt sie bei zustande kommen einer Verbindung gebündelt aus. Dabei können auch Aufträge für andere Rechner angenommen und weitergeleitet werden.
Ohne aufwändige Protokolle zu definieren, kann man UUCP
benutzen, um Email oder Netnews (alias Usenet oder News) zu
transportieren. Dazu wird einfach auf dem anderen Rechner das
Email-Einspeiseprogramm rmail aufgerufen, genauso geht das
mit rnews für Netnews. Auch andere Dienste sind
denkbar, wenn man sie mit seinem UUCP-Nachbarn abspricht, etwa die
Freigabe von lpr, um sich einen Drucker zu teilen.
UUCP ist furchtbar alt, schon in den 70ern wurde damit Mail transportiert. Inkompatible Änderungen gab es nicht, und man kann sich leicht vorstellen, was für ein riesiger Kluge von Code UUCP heute ist. Es funktioniert seltsamerweise trotzdem unglaublich zuverlässig.
Wer UUCP nutzen möchte, kann das jederzeit tun, es funktioniert
über Modem- oder ISDN-Verbindungen. Wer damit auch noch richtig
Mail oder News empfangen will, braucht jemanden, der bereits Mail
empfängt und bei UUCP mitspielen will. In Deutschland ist das der
Subnet e.V. und im Raum Leipzig ist es
Kay Prüfer. Kay ist auch nur
Mitglied bei Subnet, aber er schließt bereitwillig Leute an. Aber
Vorsicht, Kay verkauft dir semi-stabile Software und Protokolle, zum
Beispiel empfielt er Smail und benutzt gerne BSMTP,
einen katastrophalen Whack, der SMTP ohne eine bidirektionale
Verbindung zwischen Sender und Emfänger benutzt. Du wurdest gewarnt
;-)
ZConnect ist das bevorzugte Protokoll der wenigen noch verbliebenen MSDOS-basierten Mailboxen hierzulande. ZConnect räumt zwar mit der Altlast Zerberus auf, bietet aber einen Transitionsmechanismus namens Janus an. Sysops schließen Points gerne mit Janus an, sprechen bei Janus von "ZConnect für Points" und vergessen, dass Janus ill-designed ist.
Wer bereits UUCP für einen Kluge hält, wird beim Kontakt mit ZConnect unheilbare Schäden davon tragen. Das Protokoll ist aufwändig und unflexibel, die für Unix existierende Software ist noch schlimmer. Der ZConnect-Standard hat ein paar dunkle Ecken, die man aber nicht einsehen kann, denn er kostet Geld.
ZConnect stürzt jeden Unix-Rechner in eine Identitätskrise.
Das liegt daran, dass zwar jeder Point einen Namen bekommt (etwa
p0001069.elektron.east.de), aber Mail trotzdem an die
Mailbox adressiert wird (etwa marvin@elektron.east.de).
Beim Versenden muss aber die Pointadresse drinstehen (also
marvin@p0001069.elektron.east.de), sonst wird sie unter
Vernichtung des Realnamen überschrieben, usw. Wäre ich ein
Rechner, würde mich sowas in den Wahnsinn treiben. Wenn du also die
Wahl hast, halte dich von ZConnect fern. Ich tue das mittlerweile
auch.
Fetchmail ist ein typisches Unix-Programm: Es erfüllt exakt eine Aufgabe, und es erfüllt sie gut. Außerdem ist es ganz einfach verwendbar und in Skripte einzubinden.
Die Aufgabe von Fetchmail ist das Abholen von EMail, und zwar mit jedem Protokoll (POP, IMAP, ETRN in allen denkbaren Varianten, mit allen Authentifizierungsverfahren und sogar über SSL). Fetchmail kümmert sich nicht darum, was mit der Mail geschehen soll, es leitet sie ganz einfach an den ohnehin vorhandenen MTA (also etwa Sendmail) weiter. Fetchmail gibt es unter www.fetchmail.org oder in der Linux-Distributiion deiner Wahl.
Bind war lage Zeit effektiv der einzige Domain Name Server. Das wäre nicht schlimm, wenn er nicht so ein übles Stück Software wäre. Bind ist schwer zu konfigurieren und der Code macht mittlerweile keinen vertrauenerweckenden Eindruck mehr. Dennoch setzt fast jeder Bind als Nameserver ein, es gibt ja praktisch keine Alternative. Wenn du nicht sowieso einen Nameserver aufsetzen mußt, laß die Finger von Bind. Brauchst du nur einen Cache, ist PDNSD einen Blick wert.
PDNSD ist der Persistent Name Service Caching Daemon. Er agiert als Nameserver, weiß aber selbst nichts. Alle Anfragen werden an andere Nameserver weitergeleitet und die Ergebnisse zwischengespeichert. Wenn du einen Web-Proxy benutzt (Squid oder wwwoffle vielleicht), hast du dich sicher schon geärgert, dass dein Browser erst den Nameserver fragt, dann den Proxy. In dem Fall ist PDNSD richtig für dich. Außerdem nervt dann Sendmail nicht mehr so, obwohl Name Canonification eingeschaltet ist. Erhältlich auf der PDNSD-Homepage, allerdings nur im Quellcode (was kein Problem darstellen sollte).