Quelltext der Seite UUCP-Mail-News-FAQ

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

==  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 Dateiübertragung.

Im einfachsten Sinne kann man UUCP mit ''rcp'' gleichsetzen, nur dass UUCP bessere Möglichkeiten zum unbeaufsichtigten Betrieb hat und keine bestehende IP-Verbindung voraussetzt, sowie weitergehende Authentisierungsmöglichkeiten als ''.rhosts'' ermöglicht. Es wurde ursprünglich für Modem-Strecken 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 Aufrufparameter) in ein Spoolverzeichnis, aus dem der ''uucico''-Dämon liest und die Jobs entsprechend verarbeitet. Dafür, dass ''uucico'' regelmäßig aufgerufen wird, um die Jobs abzuarbeiten, muß der Administrator selbst Sorge tragen (cron).

=== Wofür braucht man sowas? ===
Bedeutung hat UUCP heutzutage nur für den Nachrichtenaustausch. Früher wurde fast alles per uucp übertragen, heute wird nur noch selten 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 standardisiert noch verbreitet. Andererseits packen Modems seit Generationen die Daten in Hardware, sodaß der Packpunkt bei Dialupstrecken eigentlich nur bei (unkomprimierten) X.75-ISDN-Verbindungen 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, dass kein Protokoll für die Übertragung fest eingestellt ist; das Protokoll ''i'' arbeitet unter Linux ab Kernel 2.4 z.&thinsp;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. Eine weitere Einsatzmöglichkeit ist die Übertragung vom Mailgateway in einer DMZ auf den Mailserver im internen Netz, falls firewallseitig kein Paketfilter, sondern reine Proxylösungen zum Einsatz kommen.

=== Auf welchen Plattformen gibt’s 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. Die gängigen modernen Distributionen liefern allerdings alle die entsprechenden Pakete mit.

Auf dem Mac existiert 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.

== Wie ist es organisiert? ==
UUCP auf Unix (und bei der hier behandelten Version von Ian Taylor unter der Debian-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./'''<br />hier stehen die eigentlichen Daten (deren Inhalt), allerdings nicht mit Originalnamen.
** '''C./'''<br />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./'''<br />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.

* Im Logverzeichnis liegen eine Log- und ein Statusdatei, welche Informationen über die UUCP-Tätigkeit enthalten. ''uustat'' benutzt die Statusdatei, ebenfalls der Cronjob für das Reporting.

* '''/var/spool/uucppublic/''' ist eine Art ''public directory'' mit den Rechten <code>rwxrwxrwt</code>, <code>uucp:uucp</code>. Hier werden z.&thinsp;B. an Benutzer adressierte Kopien abgelegt.
* '''/etc/uucp/''' beherbergt die Konfigurationsdateien.
* '''/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.

=== Welche Programme gibt es, was tun sie? ===
Eine Übersicht über die häufigst gebrauchten Programme und ihre Berechtigungen:
* '''/usr/lib/uucp/uucico''' (-r-sr-sr-x, uucp:uucp)<br />Dämon, der die eigentlichen Jobs erledigt, läßt sich z.&thinsp;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)<br />Dämon führt die Kommandos in den übertragenen Dateien aus.
* '''/usr/lib/uucp/uuchk''' (-rwxr-xr-x, root:root)<br />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)<br />Setzt einen Kopierjob in die Queue.
* '''/usr/bin/uux''' (-r-sr-sr-x, uucp:uucp)<br />Setzt einen Executejob in die Queue.
* '''/usr/bin/uuname''' (-r-sr-sr-x, uucp:uucp)<br />Zeigt alle in ''sys'' spezifizierten Systeme oder den eigenen Namen an.
* '''/usr/bin/uustat''' (-r-sr-sr-x, uucp:uucp)<br />Zeigt Informationen über ausstehende Jobs. Damit können Jobs z.&thinsp;B. auch gekillt werden, z.&thinsp;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 pocmail.CR45hqWAAAgggy
löscht den zur Übertragung anstehenden Job mit z.B. der ID pocmail.CR45hqWAAAgggy aus der Queue.

=== 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'''<br />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.&thinsp;B. ein Unterschlüsselwort ''alternate'', um eine alternative Erreichbarkeitsmethode zu definieren sowie ''alias'' für einen alternativen Namen für dieses System.
* '''port'''<br />Hier werden die Schnittstellen wie ''/dev/ttyS'' oder auch Netzverbindungen mit den entsprechenden Parametern konfiguriert. Schlüsselwort ist ''port''.
* '''dial'''<br />Hier stehen die Chatscripte für die an den in Port definierten Geräte (Modems). Schlüsselwort ist ''dialer''.
* '''passwd'''<br />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 Verbindungen über den ''inetd'' annehmen soll.
* '''call'''<br />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 wiederum für jeden lesbar sein darf.
* '''config'''<br />Hier können einkompilierte Defaults umgebogen werden. Normalerweise beschränkt sich diese Datei auf den UUCP (Node) Namen des lokalen Rechners.

Es wird dringend empfohlen, die Dateien call und passwd auf Mode 640, uucp:uucp zu halten (security)! Besser gleich die Permissions auf 600 stellen, häufig tragen die Leute nämlich diejenigen User, die aufs Modem zugreifen dürfen, in die Gruppe uucp ein und dann dürfen diese Leute plötzlich die Passworte lesen, falls eine Gerätedatei der Gruppe uucp angehört …

=== 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 <code>Permission Denied</code> 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 befriedigen. Nicht vergessen sollte man allerdings, daß auf der Gegenseite auch ein Eintrag für das eigene System stehen muß!<br />
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.

=== Wie funktioniert das mit uucp und Dateien versenden? ===
Normalerweise expandiert die Shell den UUCP-Pfadtrenner ! als Kommandowiederholung. Daher muß das ! mit \ maskiert werden: \!<br />
In der Konfigdatei ''sys'' muß ''uucp'' als Kommando erlaubt sein, falls verkettete Versendungen (<code>uucp hier!da!dort!~user/home/work</code>) erlaubt sein sollen.

Was in dem Zusammenhang ganz wichtig ist, sind die Zugriffsrechte! Uucp wie auch der uuxqt laufen alle setuid/setgid ''uucp: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'' oder dessen Gruppe(n) sein. Für das übergeordnete Directory genügt 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''.

=== UUCP ist ein Klartextprotokoll. Was ist mit der Security? ===
Am einfachsten ist es, man tunnelt UUCP über eine SSH-Verbindung.

Zuerst müssen beide beteiligten Seiten per SSH ohne Passwortabfrage einen Login auf die jeweils gegenüberliegende Seite durchführen dürfen. Zum Anlegen der Schlüssel und automatischen hinterlegen des Hostkeys in ''~/.ssh/known_hosts'' empfehle ich, mit <code>su - uucp</code> als uucp-Benutzer zu arbeiten und nicht als root. Vorteil: Die Dateien landen an den richtigen Stellen und die Zugriffsrechte passen auch von Anfang an.

* Keys auf beiden Hosts anlegen, alle Abfragen mit Return bestätigen.
 mkdir ~/.ssh
 ssh-keygen -t rsa -f ~/.ssh/id_rsa -N <nowiki>''</nowiki>
* Kopieren des Public-Keys eines Hosts auf den anderen zwecks automatisiertem Login. Das erste ''cat'' gibt die Schlüsselzeile aus, das zweite (muss auf dem jeweils anderen Host ausgeführt werden!) erzeugt die Datei ''authorized_keys'' und hinterlegt den Schlüssel dort. Wichtig, der Key ist und bleibt eine einzige lange Zeile!
 cat ~/.ssh/id_rsa.pub
 cat > ~/.ssh/authorized_keys
* Beschränken des Zugriffs mit diesem Schlüssel. Dazu wird vor dem ''ssh-rsa'' noch der folgende Konfiguration ergänzt:
 ''command="/usr/sbin/uucico -l",no-agent-forwarding,no-port-forwarding,no-X11-forwarding'' ssh-rsa AAAAB…
* Anlegen eines neuen Ports für diese Verbindung in ''/etc/uucp/port'':
 port ''uucppeer''-ssh
 type pipe
 command /usr/bin/ssh ''otherside.example.com''
 seven-bit false
 reliable true
* Änderungen gegenüber einem normalen Host via ''inetd.conf'' in ''/etc/uucp/sys'':
 system ''uucppeer''
 […]
 port ''uucppeer''-ssh
 protocol t
* Hinterlegen des Host-Keys in der ''known_hosts'', Nachfrage bestätigen, beim Loginprompt (von uucico!) dann mit ein paarmal Ctrl-C abbrechen. Es darf kein "nur Passwort"-Prompt erscheinen: Das ist dann ssh und die gegenseitige Auth mit den RSA-Keys funktioniert nicht. Das muss vorher behoben werden.
 ssh ''otherside.example.com''
* Test:
 uucico -S''uucppeer'' & tail -f /var/log/uucp/Log
Im Log steht dann sinngemäß:
 uucico - - (2018-01-08 13:45:12.79 27991) Incoming call (login ''uucppeer'' port stdin)
 uucico ''uucppeer2'' - (2018-01-08 13:45:14.80 27991) Handshake successful (protocol 't')
 uucico ''uucppeer2'' - (2018-01-08 13:45:14.81 27991) Call complete (2 seconds 0 bytes 0 bps)

== 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.<br />
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 <code>-q''xx''m</code> festgelegt. Xx ist die Zeit in Minuten zwischen den Queue-Scans. Wenn einen der Delay zwischen ''rmail'' und <code>sendmail -q</code> nervt, kann man auch ''rmail'' patchen, so daß es nicht mehr <code>sendmail -odq</code> sondern <code>sendmail -odi</code> aufruft (entweder im Source ändern oder einfach den einen Buchstaben im Binary patchen), soll mit Emacs gehen (unverified). Der Source liegt sendmail bei.

=== 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.&thinsp;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 <code>/usr/bin/uux</code> mit bestimmten Parametern auf, die spezifizieren was schlußendlich in der Kommandodatei in <code>/var/spool/uucp/system/C./</code> 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.

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.<br />
Den Defaultmailer in der ''sendmail.cf'' definiert man über den Makro DS: <code>DSuucp-dom:''remotesys''</code>, 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

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'' in der ''sendmail.cf'' 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 muß einfach mit einem Punkt beginnen, um relativ zu sein.<br />
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).

=== Wie kommen die Daten von UUCP zum Sendmail? ===
[[#Wie gelangt eine Mail von Sendmail zu UUCP?|Weiter oben]] haben wir (ohne Details) 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 [[#Wie arbeitet UUCP mit Sendmail zusammen?|hier]] bereits beschrieben, schaut Sendmail normalerweise selbständig die Queue regelmäßig durch. Wenn Mails zum Testen sofort ausgeliefert werden sollen, muß Sendmail mit <code>-q</code> aufgerufen werden, dann schaut er die Queue durch, liefert alles aus und beendet sich wieder. Alternativ kann auch ''rmail'' geändert oder frisch kompiliert werden.

=== 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.

=== Er kann es nicht, kann ich ihm UUCP beibringen? ===
Klar! Alle moderneren Distros benutzen einen Weg, aus einer Definitionsdatei (oft ''/etc/mail/sendmail.mc'') eine entsprechende ''sendmail.cf'' zu generieren.

Wichtig ist, dass keinerlei
 FEATURE(`nouucp', `nospecial')dnl
oder was in der Art in der mc auftaucht.

Folgende Punkte wären noch zu ergänzen, dabei sollten diese entsprechend einsortiert werden, also Feature zu den Features, Mailer zu den Mailern, usw.
 FEATURE(mailertable)dnl
 define(`UUCP_MAILER_MAX', `0')dnl
 MAILER(uucp)dnl
Die verqueren Quotes müssen so übernommen werden, das liegt an m4.<br />
''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 [[#Wie gelangt eine Mail von Sendmail zu UUCP?|oben]]). Als nächstes gilt es, die Konfigurationsdatei mit m4 zu erstellen, auch das ist wiederum distributionsspezifisch.
 cd /etc/mail
 make

Stimmt jetzt alles, kann Sendmail neu gestartet und getestet werden:
 leela:root # /usr/sbin/sendmail -bv heiko@hk.pocnet.net
 heiko@hk.pocnet.net… deliverable: mailer uucp-dom, host heiko, user heiko@hk.pocnet.net

Umfangreichere Checks der einzelnen Regelsätze sind mit dem Testmode möglich:
 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

=== Eine UUCP-Mail-Client Beispielkonfiguration ===
[[#Er kann es nicht, kann ich ihm UUCP beibringen?|Oben]] haben wir Sendmail beigebracht, Mails an ''bestimmte'' Domains per UUCP weiterzuleiten. Das paßt wunderbar für eine Site, die Relay spielt, also z.&thinsp;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 Default-Mailer deklarieren, der UUCP benutzt. Die m4 Beispielkonfigurationsdatei ohne dann unnötige Mailertable sieht beispielsweise 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
 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.

== 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 (hier: ''newsfeeds'') weitergeleitet. Zum anderen werden per UUCP eingegangene News an ''rnews'' verfüttert, der diese gegebenenfalls auspackt, entbatcht und an INN weiterschaufelt.

=== 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 <code>#! cunbatch</code>, welche dafür sorgt, daß die Datei ordnungsgemäß entpackt wird. Rnews führt nun als erstes dieses Kommando aus. Danach liegt der entpackte Batch vor, alle News aneinandergekleistert und durch eine Zeile <code>#! rnews ''bytes''</code> 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"
 }
Details siehe INN-Doku.

=== Wie kommen die Daten vom INN zu uucp? ===
In ''/etc/news/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.

=== 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:
:{| class="wikitable"
!leela (UUCP-Node: poc)
!deep-thought (UUCP-Node: heiko)
|-
|align="center"|heiko/deep-thought.hk.pocnet.net:poc.*:Tf,Wn:
|align="center"|poc/leela.pocnet.net:poc.*:Tf,Wn:
|}

Anhand des Domainexcludes 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.&thinsp;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.

== Was kann ich tun wenn mir die FAQ zu kurz ist? ==
Ganz einfach, selbst basteln und die offenen Fragen beantworten. :-)

== 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 [mailto:poc@pocnet.net 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 sein! Sie soll zusammenfassen, ergänzen und Lösungen zeigen. Trotzdem gilt nach wie vor: RTFM!

Danke an [mailto:Falk_Sauer@MGN.maus.de Falk Sauer] und [mailto:Ralf_Zehender@ccwn.fido.de 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 [mailto:christophe@saout.de Chtephan], [mailto:dominik@vallendor.de Dominik], [mailto:heiko@wurst-wasser.net Heiko] und [mailto:phranck@phranck.net Phrank] sowie [mailto:roland@spinnaker.rhein.de Roland Rosenfeld] für weitere Tips.

== Historie ==
Diese FAQ unterliegt der [http://www.gnu.org/licenses/fdl-1.3.html GFDL].

{| class="wikitable"
|valign="top"|15.06.97
|erste offizielle Version.
|-
|valign="top"|21.06.97
|Client-UUCP ergänzt, Tippfehler bereinigt.
|-
|valign="top"|23.06.97
|Wie verläßt man Sendmail -bt? Sendmail -q, Tippfehler bereinigt.
|-
|valign="top"|25.06.97
|Kleinere Tips von Ralf Zehender eingebaut.
|-
|valign="top"|14.07.97
|Dicken Bug in der Client-Sendmail-Konfiguration ausgemerzt.
|-
|valign="top"|10.09.97
|Tippfehler und logische Ungereimtheiten ausgebügelt.
|-
|valign="top"|23.09.97
|Navigation verbessert (Backlinks ins Inhaltsverzeichnis um lahme Browserreloads zu vermeiden).
|-
|valign="top"|29.09.97
|Newsteil ergänzt und bereinigt, Disclaimer erweitert, Tips von Roland eingearbeitet.
|-
|valign="top"|10.10.97
|Mailteil bereinigt und ergänzt.
|-
|valign="top"|22.10.97
|Timegradegeheimnis ausgetüftelt und eingebracht.
|-
|valign="top"|06.03.98
|Timegrades nochmals besser erklärt.
|-
|valign="top"|09.03.99
|Kleinere Fehler ausgemerzt, Tippfehler bereinigt, Umzug der Seite zum neuen Arbeitgeber.
|-
|valign="top"|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.
|-
|valign="top"|22.11.00
|Layout angepaßt, kleinere Typos behoben, Umzug auf den eigenen Server.
|-
|valign="top"|17.01.01
|Security mit called-login ergänzt.
|-
|valign="top"|22.02.01
|Neue URLs durch Umstrukturierungen.
|-
|valign="top"|14.03.01
|Copyright-Ergänzung, damit die FAQ auch mal offizielle Wege findet.
|-
|valign="top"|21.05.01
|Kernel-2.4 Note ergänzt.
|-
|valign="top"|16.12.01
|Ergänzung von Beispielen zu uustat, Tippfehler korrigiert. Danke an [mailto:andre@family-uhlt.de André Uhl] für die Verbesserungen!
|-
|valign="top"|05.04.02
|URL zur Doku ergänzt.
|-
|valign="top"|03.05.04
|Kernel 2.4/Protokoll besser erklärt (für Götz).
|-
|valign="top"|22.12.06
|Mailadresse entfernt.
|-
|valign="top"|18.03.11
|Überarbeitet: Modernisiert, alten Krempel raus, Tippfehler korrigiert, usw., Umsetzung.
|-
|valign="top"|8.01.18
|Überarbeitet: Abschnitt über Ssh als Transport eingefügt.
|}

[[Kategorie:Internet]]
[[Kategorie:Protokoll]]
[[Kategorie:UNIX]]