UUCP-Mail-News-FAQ: Unterschied zwischen den Versionen

Aus Knowledgebase
Zur Navigation springen Zur Suche springen
 
(kein Unterschied)

Aktuelle Version vom 27. Juni 2018, 16:22 Uhr

… 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. 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./
      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.
  • 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 rwxrwxrwt, uucp:uucp. Hier werden z. 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)
    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 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
    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 /dev/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 Verbindungen ü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 wiederum 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.

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

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/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 su - uucp 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 ''
  • 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 -Suucppeer & 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.
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). 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. 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.

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

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

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

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. 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 #! cunbatch, 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 #! 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"
}

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:

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

Historie

Diese FAQ unterliegt der GFDL.

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