Die Taylor-UUCP-Mail-News-FAQ

Startseite -> Hobby -> Computer -> UUCP-Mail-News-FAQ

...oder wie einfach es sein kann, sendmail, inn und taylor uucp unter Linux unter einen Hut zu bringen.

Inhalt:

Was ist UUCP?

Wofür braucht man sowas?
Auf welchen Plattformen gibts das?

Wie ist es organisiert?

Welche Programme gibt es, was tun sie?
Welche Konfigurationsdateien gibt es, was tun sie?
Wie sieht eine Beispielkonfiguration aus?
Wie funktioniert das mit uucp und Dateien versenden?

Wie arbeitet UUCP mit Sendmail zusammen?

Wie gelangt eine Mail von Sendmail zu UUCP?
Wie kommen die Daten von UUCP zum Sendmail?
Kann mein Sendmail denn UUCP?
Er kann es nicht, kann ich ihm UUCP beibringen?
Eine UUCP-Mail-Client Beispielkonfiguration

Wie arbeiten UUCP und INN zusammen?

Wie kommen die Daten von UUCP zum INN?
Wie kommen die Daten vom INN zu UUCP?
Eine INN Beispielkonfiguration

Was kann ich tun wenn mir die FAQ zu kurz ist?

Disclaimer

1. Was ist UUCP?

UUCP heißt ausgeschrieben Unix to Unix CoPy, und ist eine Sammlung verschiedener Übertragungsprotokolle die nicht nur einfach Dateien schaufeln, sondern auch auf dem entfernten Rechner Programme starten können, welche im Allgemeinen die übertragenen Daten gleich weiterverarbeiten. Ursprünglich diente UUCP aber hauptsächlich zur Dateienübertragung.

Im einfachsten Sinne kann man UUCP mit rcp gleichsetzen, nur daß UUCP bessere Möglichkeiten zum unbeaufsichtigten Betrieb hat und keine bestehende IP-Verbindung voraussetzt, sowie bessere Authentisierungsmöglichkeiten als .rhosts ermöglicht. Es wurde ursprüglich für Modemstrecken entwickelt, funktioniert aber auch problemlos über IP.

Das uucp oder uux Programm macht allerdings nicht die eigentliche Arbeit, es legt normalerweise nur die Jobs (oder eine Referenz darauf, je nach Aufrufparamter) in ein Spoolverzeichnis, aus dem der uucico-Dämon liest und die Jobs entsprechend verarbeitet. Dafür, daß uucico regelmäßig aufgerufen wird, um die Jobs abzuarbeiten, muß der Administrator selbst Sorge tragen (cron).

Inhalt

1.1. Wofür braucht man sowas?

Bedeutung hat UUCP heutzutage nur für den Nachrichtenaustausch. Früher wurde fast alles per uucp übertragen, heute wird eigentlich nur noch Mail und News per uucp verschickt, da das Batching auf dem Remote-System erfolgt und keine Feste IP benötigt, wie manche SMTP-Expensive-Krücken.

Für diese Mail und News ist uucp bei dial-up Systemen das effizienteste Verfahren da vor allem (in der Regel) platzintensive News vor der Übertragung gepackt vorliegen können und die Bandbreite so am besten ausgenutzt werden kann. Es gibt auch Möglichkeiten, Mail zu packen (Stichwort bsmtp), aber es ist weder vernünftig standartisiert noch verbreitet. Andererseits packen Modems seit Generationen die Daten in Hardware, sodaß der Packpunkt bei Dialupstrecken eigentlich nur bei ISDN wirklich interessant ist.

Der User braucht sich im Idealfall keine Gedanken mehr um seine Einwahl beim UUCP-Host zu machen, ein Cronjob erledigt das normalerweise, holt die dort liegenden Daten ab und schickt gleichzeitig die lokalen neuen Nachrichten zum Provider. UUCP kann auch problemlos über TCP gefahren werden, man muß dann aber aufpassen, daß kein Protokoll für die Übertragung fest eingestellt ist; Das Protokoll i arbeitet unter Linux ab Kernel 2.4 z.B. nicht mehr zuverlässig bei großen Dateien.

Eine Anbindung per UUCP macht heutzutage nur dann Sinn, wenn eine Einwahl fuer jede einzelne SMTP-Verbindung vermieden werden soll, wie das bei einem System mit einem normal eingerichteten Mailer ohne schmutzige Tricks auch der Fall wäre (egal ob die Mails 'raus oder 'rein sollen). Durch das Batching von UUCP wird die Effektivität erhöht, die bidirektionalen internen Protokolle nutzen die Verbindungen auch besser aus als SMTP über IP.

Inhalt

1.2. Auf welchen Plattformen gibts das?

So ziemlich auf allen. Manche kommerzielle Unixvarianten haben möglicherweise noch Versionen, die die Features von Taylor UUCP nicht besitzen. In vielen Fällen läßt sich Taylor UUCP aber auch auf diesen Systemen problemlos zusammenkompilieren.

Auf dem Mac gibt's zum Beispiel ->MacUCP, welches aber leider vom ->Autor nicht mehr gepflegt wird, es unterstützt zum Beispiel noch kein i-Protokoll. Links und Ergänzungen für andere Betriebssysteme werden per Mail gerne angenommen.

Inhalt

2. Wie ist es organisiert?

UUCP auf Unix (und bei der hier behandelten Version von ->Ian Taylor unter der SuSe Distribution von Linux) besteht aus nachfolgenden Dateien und Verzeichnissen:

Dem Hauptverzeichnis, allgemein /var/spool/uucp, Rechte normalerweise uucp.uucp 750. Für jedes Remote-System gibt es ein Unterverzeichnis mit dem Namen des Systems (werden automatisch angelegt. Darunter gibt es jeweils drei Verzeichnisse:
- D./
  hier stehen die eigentlichen Daten (deren Inhalt), allerdings nicht mit Originalnamen.
- C./
  hier steht für jede Datei in D./ eine nicht mit der Datenseite gleichnamige Datei, in der die Kommandos drin stehen die auf der Remote Seite ausgeführt werden sollen. Über diesen Dateinamen wir die mit uustat ausgegebene Job-ID erzeugt.
- X./
  hier steht nach dem Empfang von Daten das Futter für den uuxqt, den Dämon, der das ausführt, was auf dem Remote-System vorher in C./ gestanden hat.
Direkt im Verzeichnis liegen eine Log- und ein Statusdatei, welche Informationen über die UUCP-Tätigkeit enthalten. Diese können regelmäßig weggeputzt werden. Bei der Statusdatei empfiehlt sich ein Cut, bei der die letzten 7 Tage erhalten bleiben, damit uustat richtig funktioniert.
/var/spool/uucppublic/ ist eine Art public Directory mit den Rechten rwxrwxrwt, uucp.uucp.

/var/lib/uucp/taylor_config/ beherbergt die Konfigurationsdateien, manchmal finden diese sich auch in /usr/lib/uucp oder /etc/uucp, manche Distributionen setzen die Pfade wieder völlig anders. Im Zweifelsfalle suchen :-)

/usr/lib/uucp/ beherbergt verschiedene ausführbare Dateien und Dämonen. Manchmal liegen diese auch in /usr/libexec/uucp (NetBSD).

In /usr/bin/ liegen die Benutzerprogramme selbst.

Daneben gibt es noch ein paar Verzeichnisse die temporäre Daten enthalten und ein /var/spool/uucp/.Failed/ Verzeichnis, das die schiefgegangenen Daten und Kommandos für jedes Remote System getrennt enthält. Hier ist die Stelle wo man bei einem Ausführungsfehler der Kommandos seinen Kram retten kann, indem man einfach Daten- und Kommandodateien wieder an Ort und Stelle schafft (nach X. und D.) und den uuxqt von Hand aufruft, was aber auch nicht zwangsweise funktionieren muß, wenn die Daten selbst schadhaft sind oder die Zugriffsrechte nicht stimmen. Es ist sicherlich kein Fehler, sich den Kram vorher anzusehen.

Inhalt

2.1. Welche Programme gibt es, was tun sie?

Eine Übersicht über die häufigst gebrauchten Programme und ihre Rechte:

/usr/lib/uucp/uucico (-r-sr-sr-x, uucp.uucp)
Dämon, der die eigentlichen Jobs erledigt, läßt sich z.B. mit Cron regelmäßig aufwecken, damit er nachsehen kann, ob's Arbeit gibt. Er muß auch als Shell für die Accounts eingetragen sein, die (dann halt ausschließlich) UUCP machen sollen! Besser (sicherer und weniger aufwendig) ist aber, die eingebaute Getty-Funktion zu benutzen.

/usr/lib/uucp/uuxqt (-r-sr-sr-x, uucp.uucp)
Dämon führt die Kommandos in den übertragenen Dateien aus.

/usr/lib/uucp/uuchk (-rwxr-xr-x, root.root)
Das Programm zeigt die gesamte Konfiguration human-readable an und ist angenehmerweise sehr gesprächig, was die Fehlersuche ungemein erleichtert.

/usr/bin/uucp (-r-sr-sr-x, uucp.uucp)
Setzt einen Kopierjob in die Queue.

/usr/bin/uux (-r-sr-sr-x, uucp.uucp)
Setzt einen Executejob in die Queue.
/usr/bin/uuname (-r-sr-sr-x, uucp.uucp)
Zeigt alle in sys spezifizierten Systeme oder den eigenen Namen an.

/usr/bin/uustat (-r-sr-sr-x, uucp.uucp)
Zeigt Informationen über ausstehende Jobs. Damit können Jobs z.B. auch gekillt werden, z.B. falls eine Mail nun doch nicht verschickt werden soll.
Beispiele:
uustat -s pocmail zeigt alle Jobs die zur Auslieferung an das System pocmail bereitliegen mit ID an.
uustat -k [ID] löscht den zur Übertragung anstehenden Job mit z.B. der ID pocmail.CR45hqWAAAgggy aus der Queue.

Inhalt

2.2. Welche Konfigurationsdateien gibt es, was tun sie?

Es gibt sechs Konfigurationsdateien, die alle nach demselben Schema aufgebaut sind. Als erstes folgen Defaulteinträge, danach durch bestimmte Schlüsselworte getrennt die spezifischen Einstellungen.

sys
Hier werden die remote Systeme konfiguriert sowie Defaults für alle Remotes definiert. Das Schlüsselwort ist hier system (beginnt einen neuen Abschnitt). Für einen Sys-Eintrag gibt es z.B. ein Unterschlüsselwort alternate, um eine alternative Erreichbarkeitsmethode zu definieren sowie alias für einen alternativen Namen für dieses System.

port
Hier werden die Schnittstellen wie ttyS oder auch Netzverbindungen mit den entsprechenden Parametern konfiguriert. Schlüsselwort ist port.

dial
Hier stehen die Chatscripte für die an den in Port definierten Geräte (Modems). Schlüsselwort ist dialer.

passwd
Hier stehen die Logins der Systeme die anrufen dürfen mit ihren Passworten im Klartext. /etc/passwd oder shadow wird nicht benutzt. Wird benötigt, wenn uucico im Getty-Mode läft oder Vernindungen über den inetd annehmen soll.

call
Eine Paßworttabelle für die Systeme, die angerufen werden. So weiß der uucico, welches Login-Paßwort-paar er für welches System zu verwenden hat. Die Paßworte brauchen dann nicht im Klartext in sys stehen, die dann für jeden lesbar sein darf.

config
Hier können einkompilierte Defaults umgebogen werden. Normalerweise beschränkt sich diese Datei auf den UUCP (Node) Namen des lokalen Rechners. Bei der SuSe Linux Distribution wird dummerweise keine Beispielpasswd mitgeliefert, weshalb der Default-Platz für diese Datei meist nicht bekannt ist. Hier kann man dann den Pfad eintragen.

Es wird dringend empfohlen, die Dateien call und passwd auf Mode -rw-r-----, uucp.uucp zu halten (security)! Besser gleich die Permissions auf -rw------ stellen, häufig tragen die Leute nämlich diejenigen User, die auf's Modem zugreifen dürfen, in die Group uucp ein und dann dürfen diese Leute plötzlich die Paßworte lesen...

Inhalt

2.3. Wie sieht eine Beispielkonfiguration aus?

In den nicht aufgeführten Dateien stehen meist Defaults, die unverändert übernommen werden können.

port

#
# port - Beschreibung der Schnittstellen
#
speed   38400
#
port    isdn
device  /dev/ttyI2
dialer  isdn
#
port    netz
type    tcp
#
port    seriell
device  /dev/ttyS2
dialer  generic
#

Ich denke, daß sich hier eine Erklärung erübrigt.

config

#
# config - Haupt UUCP-Konfigurations-Datei
#
nodename poc
passwdfile /var/lib/uucp/taylor_config/passwd

Hier wohl ebenso.

sys

#
# sys - Beschreibung der bekannten Systeme
#
#
# Globale Einstellungen fuer alle Systeme
#
#
# Passwort und Login aus call lesen
call-login      *
call-password   *
#
# Ich darf jederzeit 'rausrufen
time            any
#
# Das darf ich ausführen und finde das im command-path
commands        uucp rmail rnews
command-path    /usr/bin /home/news/bin
# Wie führe ich ich einen Login durch
chat            ogin: \L word: \P
# Grundsätzlich diesen Port benutzen
port            netz
# Verkettung hier!da!sonstwo erlauben
forward         ANY
# uucp remote!/tmp/herdamit /tmp erlauben (weil /tmp unterhalb / liegt)
local-receive   /
#
#
system          pocmail
called-login	pocmail
alias           ci
address         ci.pocnet.net
remote-receive  /home/poc ~   # Darf auf diesem System von fern nur dahin senden
remote-send     /home/poc     # Darf auf diesem System von fern nur von da empfangen
#
system          heiko
called-login	heiko
time            never         # Der ruft nur hier an
remote-receive  /home/heiko ~
remote-send     /home/heiko
#

Erläuterung:

Commands sind die Kommandos, die ausgeführt werden dürfen. Ohne Pfadangabe eintragen!
Command-Path ist der Suchpfad, in dem nach diesen Kommandos gesucht wird. Dieser ist unbedingt richtig anzugeben, da ein uux-Aufruf mit direkter Pfadangabe ein Permission Denied provoziert.
Chat ist ein wie von PPP bekanntes kleines Expect-Send-Expect... Script, welches den Login durchführt. Nähere Informationen finden sich in der Manpage zu chat(8).
Called-login ist eine recht nette Sache, um das Faken von Systemen zu unterbinden: So kann man ein System für eingehende Calls an einen Login binden. Normalerweise kann jedes System mit sich jedem in der UUCP-Passwd eingetragenen Login-Paßwort-Paar gegenüber der Gegenseite authentisieren, wenn der Systemname bekannt ist. Wenn man Systemname, Login und Paßwort recht abstrakt wählt, kriegt man UUCP auf diese Weise genau so dicht wie einen normalen POP3 Zugang.

Aus dieser Beispielkonfiguration lassen sich die wichtigsten eigenen Konfigurationsbedürfnisse abändern. Nicht vergessen sollte man allerdings, daß auf der Gegenseite auch ein Eintrag für das eigene System stehen muß!
Um zu testen, ob UUCP selbst nun funktioniert, sollte man einen Job in Auftrag geben:

uucp -r /bin/bash heiko\!~/poc-bash

Das nächste Mal, wenn uucico eine Verbindung mit Heiko eingeht (wenn er anruft), wird /bin/bash nach /var/spool/uucppublic/poc-bash kopiert. Das Ausrufezeichen muß escaped werden, damit die bash es nicht als Befehlswiederholung (wie sonst üblich) expandiert.

Inhalt

2.4. Wie funktioniert das mit uucp und Dateien versenden?

Normalerweise expandiert die Shell den UUCP-Pfadtrenner ! als Kommandowiederholung. Daher muß das ! mit \ maskiert werden: \!
In der Konfigdatei sys muß uucp als Kommando erlaubt sein, falls verkettete Versendungen (uucp hier!da!dort!~user/home/work) erlaubt sein sollen.

Was in dem Zusammenhang ganz wichtig ist, sind die Zugriffsrechte! Uucp wie auch der uuxqt laufen alle setuid uucp und setgid uucp. Sprich, wenn die Konfiguration auch sonstwas erlaubt, je nach setup muß das Directory, aus welchem gelesen werden kann, mindestens Mode 5 (r-x) für uucp sein. Das Übergeordnete Directory genügt dahingehend allerings mit Mode 1 (--x). Wenn in ein Directory geschrieben werden soll, muß es zusätzlich schreibbar sein, Mode 7 (rwx) oder als Dropbox Mode 3 (-wx), wenn uucp nicht mehr draus lesen können soll.

Siehe auch die entsprechenden Abschnitte in der UUCP-Dokumentation, Abschnitt sys-Konfigurationsdatei, Punkte local-send, local-receive, remote-send, remote-receive.

Inhalt

3. Wie arbeitet UUCP mit Sendmail zusammen?

Mail (und News) Requests werden per uux übertragen. Sendmail zum Beispiel verfüttert die Mail an dessen stdin und ein paar Parameter dazu. Auf der Gegenseite ruft nach der Übertragung uuxqt diese Kommandodatei auf, welche ihrerseits rmail anwirft, welches dann den Kram in die Sendmail-Queue verschiebt.
Sendmail wacht alle paar Minuten aus seinem Dämonenschlaf auf und schaut, ob's in der Queue was zu schaufeln gibt: Die Mail wird ausgeliefert.

Wie oft er das tut, wird beim Aufruf von Sendmail mit dem Parameter -qxxm festgelegt. Xx ist die Zeit in Minuten zwischen den Queue-Scans. Wenn einen der Delay zwischen rmail und sendmail -q nervt, kann man auch rmail patchen, so daß es nicht mehr sendmail -odq sondern sendmail -odi aufruft (entweder im Source ändern oder einfach den einen Buchstaben im Binary patchen), soll mit Emacs gehen (unverified). Ich habe hier den Source geändert und mangels GNU-Make-kompatiblem Makefile mit gcc -O2 -o rmail rmail.c kompiliert und die Manpage und das Binary an den richtigen Platz kopiert (/usr/bin). Der Source liegt sendmail bei.

Inhalt

3.1. Wie gelangt eine Mail von Sendmail zu UUCP?

In Sendmail gibt es für jede Übertragungsart einen sogenannten Mailer. Das ist das Programm welches die eigentliche Verschiebearbeit tut. Sendmail selbst wurschtelt nur an den Adressen 'rum, bis er weiß, welchen Mailer er benutzen muß. Diese Mailer haben einen symbolischen Namen z.b. local für das Programm was die Mails lokal auf dem Rechner ausliefert, oder eben auch uucp für den (oder besser gesagt die) uucp Mailer. Sendmail ruft als uucp Mailer direkt /usr/bin/uux mit bestimmten Parametern auf, die spezifizieren was schlußendlich in der Kommandodatei in /var/spool/uucp/system/C./ drin steht, also den Aufruf von rmail auf der Gegenseite.

Über eine Tabelle, die mailertable, stellt sendmail fest, daß eine Mail an eine Adresse über UUCP ausgeliefert werden soll und mit welcher Mailer-Spezifikation das geschehen soll. So eine Konfiguration ist zweckmäßig für ein UUCP-Relay, welches Mails per SMTP empfängt und sie per UUCP weiterleitet, quasi den Server.

Ein Rechner, der Mails nur über UUCP senden und empfangen kann, braucht einen Defaultmailer, der alle abgesendeten Mails weiterverwurstelt, solange er keine näheren Infos in der mailertable findet. Im Prinzip kann man das mit der Defaultroute von TCP/IP vergleichen. Findet sich kein Mailer für eine Adresse, wird der Defaultmailer verwendet.

Den Defaultmailer in der sendmail.cf definiert man über den Makro DS: DSuucp-dom:remotesys, wobei remotesys einem Eintrag in sys entspricht. In der entsprechenden m4 Datei für die Sendmail-Konfigurationszusammenschraubung ist das dann define(`SMART_HOST', `uucp-dom:remotesys')dnl.

Beispiel-mailertable zur Sys weiter oben passend:

#Domain             mailer:new_domain
#
hk.pocnet.net       uucp-dom:heiko

Normalerweise muß die Datenbank noch gehasht (indiziert) werden, damit Sendmail ordnungsgemäß darauf zugreifen kann:

makemap hash mailertable.db < mailertable

Sowas kann man auch ganz nett in das Sendmail-Anwerf-Script eintragen:

#! /bin/sh
#
# /sbin/init.d/sendmail
#

TABLES='mailertable virtusertable access_db'

case "$1" in
    start)
        for F in $TABLES; do
                if test -f /etc/mail/$F; then
                        echo -n "$F neu aufbauen..."
                        makemap hash /etc/mail/$F.db < /etc/mail/$F
                fi
        done
        echo -n "Sendmail starten"
        /usr/sbin/sendmail -bd -q10m -om
        echo '.'
        ;;
    stop)
        echo -n "Stoppe Sendmail:"
        kill `head -n1 /var/run/sendmail.pid` && echo -n " okay"
        echo '.'
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
esac

exit 0

Sendmail merkt durch diese Tabelle, daß Mail an heiko@hk.pocnet.net über UUCP geroutet werden muß, aktiviert den Mailer uucp-dom, der die Mail im heute üblichen user@host.domain Stil weiterleitet (in die C./D. Verzeichnisse von uucp legt). hk.pocnet.net ist in diesem Falle eine Subdomain, uucp funktioniert logischerweise auch mit normalen Domains. Das heißt, im Nameserver für die Zone pocnet.net müssen entsprechende MX-Einträge stehen, die die Mail an das UUCP-Relay leiten:

$ORIGIN pocnet.net.
; For the UUCP-Users
hk             IN   MX  1    uucp-host

Als Anmerkung hier nur das Stichwort Replyadresse, eine Mail von deep-thought.hk.pocnet.net wird zwar richtig ausgeliefert, aber sobald der User einen Reply setzt, funktioniert eine Antwort auf diesen Reply nicht mehr. Das rührt daher, daß es für den Rechner deep-thought keinen DNS-Eintrag gibt. Lösung: Entweder passende DNS-Zonen mit Rechnernamen anlegen oder den User treten, daß er seine Replyadresse richtig setzt.

Zu beachten ist auch, daß die Hosts nicht in der Klasse w (lokaler Hostname) auftauchen dürfen, das heißt, ihr darf weder direkt über Cwlocalhost andere.dom noch indirekt über die Klassendatei (in der sendmail.cf allgemein über Fw/etc/mail/local-host-names) ein UUCP-Host zugeordnet werden. Ansonsten würde die Mail lokal ausgeliefert. Wir wollen aber nur weiterleiten (Relaying).
Je nach Installation heißt die Datei local-host-names auch sendmail.cw und ist unter /etc oder /etc/mail zu finden.

Ein weiterer interessanter Aspekt zu der Problematik von oben sind wildcard-MXer, Einträge im DNS, der pauschal alle Mail an *.pocnet.net (Host, nicht User!) an das UUCP-Relay schickt. So eine allgemeine Formulierung ist in der Mailertable auch möglich, der Eintrag im mailertable muß einfach mit einem Punkt beginnen, um relativ zu sein.
Nachteil: Schickt jemand eine Mail an eine nicht existente Subdomain, schicken sich beide UUCP-Systeme die Mail solange zu, bis ein Sendmail aufgibt (normalerweise nach 26 Bounces).

Inhalt

3.2. Wie kommen die Daten von UUCP zum Sendmail?

In 3.1 haben wir gelernt das uux in der Kommandodatei etwas wie "Spezifikation der Daten absender@irgendwo 0 rmail empfänger@irgendwoanders" einträgt. Uuxqt macht nun nichts anderes als die empfangene Datei auszuführen, sprich die Daten an rmail zu verfüttern, welches sie dann brav bei sendmail abgibt, also in dessen Queue legt. Wie in 3 bereits beschrieben, schaut Sendmail normalerweise selbständig die Queue regelmäßig durch. Wenn Mails zum Testen sofort ausgeliefert werden sollen, muß Sendmail mit -q aufgerufen werden, dann forked der, schaut die Queue durch, liefert alles aus und beendet sich wieder. Alternativ kann auch rmail geändert oder frisch kompiliert werden, siehe 3..

Inhalt

3.3. Kann mein Sendmail denn UUCP?

Das bleibt festzustellen. Im Zweifelsfalle, testen:

leela:/root # fgrep Muucp /etc/mail/sendmail.cf
Muucp,          P=/usr/bin/uux, F=DFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-old,      P=/usr/bin/uux, F=DFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-new,      P=/usr/bin/uux, F=mDFMhuUd, S=FromU, R=EnvToU/HdrToU,
Muucp-dom,      P=/usr/bin/uux, F=mDFMhud, S=EnvFromUD/HdrFromSMTP, R=EnvToSMTP,
Muucp-uudom,    P=/usr/bin/uux, F=mDFMhud, S=EnvFromUUD/HdrFromSMTP, R=EnvToSMTP,

Wenn da nix erscheint, kann er es nicht. Falls das der Fall sein sollte, nicht verzweifeln, soo schwer ist Sendmail auch nicht. Continue with Punkt 3.4.

Inhalt

3.4. Er kann es nicht, kann ich ihm UUCP beibringen?

Klar! Als erstes empfehle ich, diese Chance zu nutzen um einen aktuellen Sendmail zu saugen. Fündig wird man bei ftp://ftp.sendmail.org/pub/sendmail/.

Wenn das Paket ausgepackt auf der Platte liegt, gibt es innerhalb des Sendmail-Verzeichnisses ein paar Unterverzeichnisse, unter Anderem cf. Es empfiehlt sich, nicht nur sendmail selbst, sondern auch noch das Eine oder Andere Hilfsprogramm mit durchzukompilieren (mail.local, makemap, rmail, smrsh). Für nähere Infos siehe die Doku zu Sendmail.

Im eigentlichen Sendmail-Sourceverzeichnis liegt ein Script, Build, welches aufgerufen, Sendmail komplett zusammenschustert und in ein systemabhängiges Unterverzeichnis legt, hier war das ../obj.Linux.2.2.16.i586. Mit ./Build install wird dann sendmail am rechten Fleck installiert.

Im cf Unterverzeichnis liegen die m4-Makros zur Erstellung der sendmail.cf Damit muß für das lokale System eine Konfiguration erstellt werden. Hier wäre es eine cf, die SMTP und UUCP beherrscht, also für ein Relay (einen Server) geeignet ist:

VERSIONID(`$Id: client.mc, 2.1.3 for sendmail 8.11.0 07/23/00 by PoC Exp $')dnl
OSTYPE(linux)dnl
DOMAIN(generic)dnl
FEATURE(mailertable)dnl
FEATURE(access_db)dnl
FEATURE(relay_entire_domain)dnl
FEATURE(relay_based_on_MX)dnl
FEATURE(blacklist_recipients)dnl
define(`SMART_HOST', `esmtp:user.baden-online.de.')dnl
define(`UUCP_MAILER_MAX', `0')dnl
define(`confTRUSTED_USERS', `bin')dnl
define(`confPRIVACY_FLAGS', `goaway')dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)dnl

Die verqueren Quotes müssen so übernommen werden, das liegt an m4.
UUCP_MAILER_MAX setzt das Mailgrößenlimit im Beispiel oben auf keins, sonst gehen etwas größere Mails wieder zurück.

Danach kann die Mailertable angelegt und gehasht werden (Siehe 3.1). Als nächstes gilt es, die Konfigurationsdatei mit m4 zu erstellen:

m4 m4/cf.m4 leela.cf > /etc/mail/sendmail.cf

Stimmt jetzt alles, kann Sendmail wieder gestartet und getestet werden:

leela:root # /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>

Danach wird explizit Ruleset 3 aufgerufen und die zu testende UUCP-Adresse eingegeben:

> 3,0 heiko@hk.pocnet.net
canonify           input: heiko @ hk . pocnet . net
Canonify2          input: heiko < @ hk . pocnet . net >
Canonify2        returns: heiko < @ hk . pocnet . net . >
canonify         returns: heiko < @ hk . pocnet . net . >
parse              input: heiko < @ hk . pocnet . net . >
Parse0             input: heiko < @ hk . pocnet . net . >
Parse0           returns: heiko < @ hk . pocnet . net . >
ParseLocal         input: heiko < @ hk . pocnet . net . >
ParseLocal       returns: heiko < @ hk . pocnet . net . >
Parse1             input: heiko < @ hk . pocnet . net . >
MailerToTriple     input: < uucp-dom : heiko > heiko < @ hk . pocnet . net . >
MailerToTriple   returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >
Parse1           returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >
parse            returns: $# uucp-dom $@ heiko $: heiko < @ hk . pocnet . net . >

So, das sieht gut aus, der UUCP-DOM-Mailer wird aufgerufen. Sendmail kann UUCP und die Mails werden weitergeroutet. Sendmail kann nun verlassen werden:

^D

Inhalt

3.5. Eine UUCP-Mail-Client Beispielkonfiguration

In 3.4 haben wir Sendmail beigebracht, Mails an bestimmte Domains per UUCP weiterzuleiten. Das paßt wunderbar für eine Site, die Relay spielt, also z.B. für den Rechner beim Provider. Die Rechner, die per UUCP als Clients unter diesem Server hängen, müßten alle möglichen Domains, erst in den Mailertable eintragen, damit Mails 'rausgehen. Das ist natürlich völlig unpraktikabel und deshalb gibt's da eine Alternative. Man muß einen anderen Default-Mailer deklarieren, der UUCP statt SMTP benutzt. Die m4 Beispielkonfigurationsdatei ohne dann unnötige Mailertable sieht dann so aus:

VERSIONID(`$Id: client.mc, 2.1.3 for sendmail 8.11.0 07/23/00 by PoC Exp $')dnl
OSTYPE(linux)dnl
DOMAIN(generic)dnl
FEATURE(promiscous_relay)dnl
FEATURE(nocanonify)dnl
define(`SMART_HOST', `uucp-dom:remotesys')dnl
define(`UUCP_MAILER_MAX', `0')dnl
define(`confTRUSTED_USERS', `bin')dnl
define(`confPRIVACY_FLAGS', `goaway')dnl
LOCAL_NET_CONFIG
R$* < @ $* .$m > $*	$#smtp $@ $2.$m $: $1 < @ $2.$m > $3
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(uucp)dnl

Das Define smarthost definiert den oben beschriebenen Default-Mailer für Mails, die nicht auf dem lokalen Rechner bleiben sollen.

LOCAL_NET_CONFIG ist eine Regel, die schaut, ob eine Mail in der eigenen Domain ausgeliefert werden soll und macht das dann per SMTP und geht nicht über das UUCP-Relay. Mehr Infos dazu stehen in contrib/bsdi.mc.

Inhalt

4. Wie arbeiten UUCP und INN zusammen?

Das Network News Konzept ist im Vergleich zu Mail komplett anders. News sind Massenartikel und entsprechend diesem massenhaften Auftreten werden News über UUCP auch anders behandelt als Mails.

So werden News normalerweise nicht Artikel für Artikel gesendet sondern als Batch: Mehrere Artikel in einem Archiv, welches häufig noch zusätzlich gepackt (compress) wird, um den Datendurchsatz zu erhöhen.

News werden -ähnlich wie bei sendmail durch die Mailertable- anhand einer Regeldatei (newsfeeds) weitergeleitet. Zum Anderen werden per UUCP eingegangene News an rnews verfüttert, der diese gegebenenfalls auspackt, entbatcht und an INN weiterschaufelt.

Inhalt

4.1. Wie kommen die Daten von UUCP zum INN?

In der Kommandodatei eines Newspaketes steht ein ähnlicher Aufruf wie bei Mail drin, in Etwa Spezifikation der Daten 0 rnews. Uuxqt füttert nun rnews einfach mit den Daten aus dem Datenpaket. Die Daten liegen meist gepackt im Datenpaket vor, send-uucp hat diese beim Versand gepackt (compressed). Das Datenpaket beginnt deshalb mit der Zeile #! cunbatch, welche dafür sorgt, daß die Datei ordnungsgemäß entpackt wird. Rnews führt nun als erstes dieses wohl interne Kommando aus. Danach liegt der entpackte Batch vor, alle News aneinandergekleistert und durch eine Zeile #! rnews bytes getrennt. Diese Datei wird jetzt von rnews in einzelne Artikel zerhackt und an INN weitergesendet. Dazu sollte aber ein ME-Eintrag in der incoming.conf von INN stehen:

peer ME {
    hostname:   "localhost, 127.0.0.1, leela.pocnet.net"
}

Inhalt

4.2. Wie kommen die Daten vom INN zu uucp?

In etc/newsfeeds sollte ein Eintrag für das System, welches News empfangen soll stehen. Ich empfehle den UUCP-Namen und den Eintrag in newsfeeds gleich zu halten.

Wenn jetzt ein Artikel neu über einen Kanal (ein beliebiger Feed) eintrifft, wird in einer Datei spool/out.going/name ein Eintrag auf den Pfad des neu eingetroffenen Artikels hinzugefügt.

Diese Datei dient in festen Zeitabständen (cron) dem Script bin/send-uucp dazu, die eigentliche Verpackarbeit und uuxerei der Artikel durchzuführen.

Inhalt

4.3. Eine INN Beispielkonfiguration

Als Beispiel geht es hier um die Rechner leela.pocnet.net sowie deep-thought.hk.pocnet.net. Beide Server müssen eine passende Zeile für das "gegenüberliegende" System in ihrer Feeddatei newsfeeds haben:

leela (UUCP-Node: poc) deep-thought (UUCP-Node: heiko)

heiko/deep-thought.hk.pocnet.net:poc.*:Tf,Wn: poc/leela.pocnet.net:poc.*:Tf,Wn:

leela (UUCP-Node: poc)	deep-thought (UUCP-Node: heiko)
heiko/deep-thought.hk.pocnet.net:poc.*:Tf,Wn:	poc/leela.pocnet.net:poc.*:Tf,Wn:

Anhand der Domainexclude nach dem ersten / werden Bounces vermieden, das heißt, daß ein Artikel nicht immer wieder für das betreffende System wieder gebatcht wird, sobald er eingetroffen ist. Artikel, die hk.pocnet.net in der Path-Zeile stehen haben, werden nicht mehr an deep-thought geschickt und umgekehrt. Das vermeidet Bounces und schlechte Laune bei den Newsadministratoren.

Ansonsten entspricht die Konfiguration weitestgehend der Defaultmäßigen von INN. Kleinere Abwandlungen wie z.B. Expires oder Moderatorenliste und Ähnliches tun für die UUCP-Konfiguration nicht mal indirekt was zur Sache, dazu existieren weit mehr als genug Manpages und andere Dokumentationen.

Wichtig ist natürlich daß Gruppen, die an ein System gesendet werden, dort auch eingerichtet sind. Damit sollte ein einfacher Feed recht schnell zum Laufen zu bringen sein.

Inhalt

5. Was kann ich tun wenn mir die FAQ zu kurz ist?

Ganz einfach, selbst basteln und die offenen Fragen beantworten. :-)

Inhalt

6. Disclaimer

Diese FAQ wurde nach bestem Wissen und Gewissen zusammengestellt. Trotzdem kann es immer wieder passieren, daß sich Fehler einschleichen. Ich bitte deshalb um die Zusendung von Korrekturen an mich, falls so ein Fehler entdeckt wird! Ansonsten haftet der Leser für seine Handlungen selbst.

Diese FAQ soll kein Ersatz zur Doku der beschriebenen Programmpakete (sendmail-8.11.0, inn 2.2.2, Taylor UUCP 1.06.1) sein! Sie soll zusammenfassen, ergänzen und Lösungen zeigen. Trotzdem gilt nach wie vor: RTFM!

Danke an Falk Sauer und Ralf Zehender für die Initialzündung und erste Tips. Danke auch an die Jungs von O'Reilly Books, ohne die ich den ganzen Krempel wohl nie zum Laufen bekommen hätte. Danke auch an meine Tester Chtephan, Dominik, Heiko und Phrank sowie Roland Rosenfeld für weitere Tips.

Inhalt

Diese FAQ liegt im Original unter http://www.pocnet.net/hobby/computer/uucp-mail-news-faq.html bezogen werden. Die FAQ unterliegt der GFDL.

22.12.06 Mailadresse entfernt.

03.05.04 Kernel 2.4/Protokoll besser erklärt (für Götz).

05.04.02 URL zur Doku ergänzt.

16.12.01 Ergänzung von Beispielen zu uustat, Tippfehler korrigiert. Danke an André Uhl für die Verbesserungen!

21.05.01 Kernel-2.4 Note ergänzt.

14.03.01 Copyright-Ergänzung, damit die FAQ auch mal offizielle Wege findet.

22.02.01 Neue URLs durch Umstrukturierungen.

17.01.01 Security mit called-login ergänzt.

22.11.00 Layout angepaßt, kleinere Typos behoben, Umzug auf den eigenen Server.

23.07.00 Größere Überarbeitung, einige Kapitel vereinfacht, Pfadangaben an aktuelle Programmversionen angepaßt, Timegrades 'rausgeworfen, weil das bei den heutigen Telefontarifen mehr verwirrt als hilft, uvAm.

09.03.99 Kleinere Fehler ausgemerzt, Tippfehler bereinigt, Umzug der Seite zum neuen Arbeitgeber.

06.03.98 Timegrades nochmals besser erklärt.

22.10.97 Timegradegeheimnis ausgetüftelt und eingebracht.

10.10.97 Mailteil bereinigt und ergänzt.

29.09.97 Newsteil ergänzt und bereinigt, Disclaimer erweitert, Tips von Roland eingearbeitet.

23.09.97 Navigation verbessert (Backlinks ins Inhaltsverzeichnis um lahme Browserreloads zu vermeiden).

10.09.97 Tippfehler und logische Ungereimtheiten ausgebügelt.

14.07.97 Dicken Bug in der Client-Sendmail-Konfiguration ausgemerzt.

25.06.97 Kleinere Tips von Ralf Zehender eingebaut.

23.06.97 Wie verläßt man Sendmail -bt? Sendmail -q, Tippfehler bereinigt.

21.06.97 Client-UUCP ergänzt, Tippfehler bereinigt.

15.06.97 erste offizielle Version.

(c) by Patrik Schindler <webhamster@pocnet.net>, 1999-2008

22.12.06	Mailadresse entfernt.
03.05.04	Kernel 2.4/Protokoll besser erklärt (für Götz).
05.04.02	URL zur Doku ergänzt.
16.12.01	Ergänzung von Beispielen zu uustat, Tippfehler korrigiert. Danke an André Uhl für die Verbesserungen!
21.05.01	Kernel-2.4 Note ergänzt.
14.03.01	Copyright-Ergänzung, damit die FAQ auch mal offizielle Wege findet.
22.02.01	Neue URLs durch Umstrukturierungen.
17.01.01	Security mit called-login ergänzt.
22.11.00	Layout angepaßt, kleinere Typos behoben, Umzug auf den eigenen Server.
23.07.00	Größere Überarbeitung, einige Kapitel vereinfacht, Pfadangaben an aktuelle Programmversionen angepaßt, Timegrades 'rausgeworfen, weil das bei den heutigen Telefontarifen mehr verwirrt als hilft, uvAm.
09.03.99	Kleinere Fehler ausgemerzt, Tippfehler bereinigt, Umzug der Seite zum neuen Arbeitgeber.
06.03.98	Timegrades nochmals besser erklärt.
22.10.97	Timegradegeheimnis ausgetüftelt und eingebracht.
10.10.97	Mailteil bereinigt und ergänzt.
29.09.97	Newsteil ergänzt und bereinigt, Disclaimer erweitert, Tips von Roland eingearbeitet.
23.09.97	Navigation verbessert (Backlinks ins Inhaltsverzeichnis um lahme Browserreloads zu vermeiden).
10.09.97	Tippfehler und logische Ungereimtheiten ausgebügelt.
14.07.97	Dicken Bug in der Client-Sendmail-Konfiguration ausgemerzt.
25.06.97	Kleinere Tips von Ralf Zehender eingebaut.
23.06.97	Wie verläßt man Sendmail -bt? Sendmail -q, Tippfehler bereinigt.
21.06.97	Client-UUCP ergänzt, Tippfehler bereinigt.
15.06.97	erste offizielle Version.