*ACHTUNG*		!VERALTET!			*ACHTUNG*

Definition eines Protokolls für asynchronen Filetransfer im Internet und
                     Referenzimplementierung für Unix









Ulli Horlacher





Allmandring 30

Rechenzentrum Universität Stuttgart



framstag@rus.uni-stuttgart.de







5. März 1996

:

Kurzbeschreibung

SAFT (Simple Asynchronous File Transfer) ist ein neues Internet-Protokoll, das es erlaubt, 
Dateien und Nachrichten asynchron zu verschicken, d.h. ohne daß es notwendig ist, sich beim 
Empfängersystem einzuloggen. Als Referenzimplementation wurden ein sendfile-Client (ver-
schickt Dateien), ein sendmsg-Client (verschickt einzeilige Nachrichten), ein receive-Client 
(empfängt Dateien aus dem sendfile-spool) und ein sendfiled-Server (empfängt Dateien und 
Nachrichten und verteilt sie weiter) geschrieben.

INHALT

1	Definition des asynchronen Dateitransfers und Abgrenzung 
gegenüber existierenden Diensten		4

1.1	Filetransfer im Bitnet	4

1.2	Das SIFT/UFT Protokoll	5

1.3	Das SAFT Protokoll	5

1.3.1	Beispiele	10

1.3.2	Begründung des Protokolldesigns	12

2	sendfile: eine SAFT Referenzimplementation für Unix	14

2.1	Programmbeschreibung	14

2.1.1	sendfiled	14

2.1.2	sendfile	16

2.1.3	sendmsg	18

2.1.4	receive	18

2.2	Benutzerkonfigurationsdateien	20

2.3	Installation	21

2.4	Sourcen	23

2.4.1	Aufrufdiagramm	26

2.4.2	Datenstrukturen	27

3	Danksagungen	30

4	Informationsverzeichnis	31

5	Glossar	32

1  Definition des asynchronen Dateitransfers und Abgrenzung 
gegenüber existierenden Diensten

Bei einem asynchronen Filetransfer werden Dateien von einem Sender an einen Empfän-
ger geschickt, ohne daß letzterer aktiv an der Übertragung teilnehmen muß. E-mail ist z.B. 
ein asynchroner Dienst, während ftp einen synchronen Dienst darstellt.

Asynchronen Filetransfer gab es bisher im Internet nicht. Wollte ein Benutzer A einem 
beliebigen Benutzer B eine Datei zukommen lassen, hatte er bisher nur folgende wenig 
brauchbare Möglichkeiten:

·	ftp [13] zum Empfängeraccount 		
Dazu muß das Paßwort des Empfängeraccounts bekannt sein. Wenn A und B nicht 
physisch identisch sind, ist diese Methode sicherheitstechnisch indiskutabel. Aber 
auch wenn es sich bei A und B um dieselbe Person handelt, so wandert doch das Paß-
wort als Klartext in einem tcp-Päckchen durchs Internet.

·	ftp über einen anonymous ftp Server	 	
Die Datei muß von A auf den anonymous ftp Server mittels ftp übertragen werden, A 
muß B mit einer e-mail informieren, daß dieser die Datei abholen kann und B muß 
dann ebenfalls ftp aufrufen. Als Nebenbedingung muß ein ftp Server gefunden wer-
den, der von beiden gut erreicht werden kann und dieser Server muß ein allgemein 
schreibbares Verzeichnis aufweisen. Während die Datei auf dem anonymous ftp Ser-
ver liegt, kann sie aber praktisch von jedermann gelesen, gelöscht oder verändert wer-
den.

·	verschicken via e-mail		
Die Datei wird von A an B als e-mail geschickt. Nach RFC 822 darf eine e-mail nur 
Zeichen aus dem NVT-ASCII Zeichensatz enthalten, welcher eine Untermenge von 7 
bit ASCII ist. Somit ist der Dateientransfer auf englische Textdokumente beschränkt, 
wenn man nicht die zu verschickende Datei entsprechend kodiert, so daß sie nur noch 
NVT-ASCII Zeichen enthält. Als Kodierung bieten sich an: uuencode oder MIME 
[16]. Beide sind aber umständlich zu handhaben, unterstützen nicht alle Dateiattribute 
und vergrößern zwangsläufig die zu übertragende Datenmenge. Zudem sind die real 
existierenden Mailsysteme nicht in der Lage, mit größeren Übertragungen fertig zu 
werden.

1.1  Filetransfer im Bitnet

Im Bitnet gibt es einen asynchronen Filetransferdienst. Dieser wurde als Vorbild genom-
men und auf das Internet abgebildet, wobei die Funktionalität wesentlich erweitert wurde.

Tatsächlich basieren sämtliche Bitnetdienste auf asynchronen Filetransfers.

Bitnet erlaubt aufgrund von IBM-internen Restriktionen nur Dateinamen mit 8 Byte 
und 8 Byte Extension, Zeilenlängen von maximal 80 Byte und EBCDIC bzw. 7 bit 
ASCII als Zeichensatz.

1.2  Das SIFT/UFT Protokoll

In der Vorbereitungsphase wurde das SIFT/UFT (Sender-Initiated/Unsolicited File 
Transfer) Protokoll aka RFC 1440 gefunden [15] , welches ebenfalls einen asynchro-
nen Filetransferdienst für das Internet beschreibt. Dieses Protokoll hat den ,Experi-
mental" Status und enthält noch einige Fehler bzw. Inkonsistenzen. Außerdem ist es 
stark an IBMs VM Betriebssystem angelehnt, da es ausschliesslich dessen Dateitypen 
unterstützt. 

Es wurde versucht, mit dem Author (Rick Troth, troth@compassnet.com) e-mail Kon-
takt aufzunehmen. Leider lagen seine Antwortzeiten im Schnitt bei ca. 2  Wochen, so 
daß eine sinnvolle Diskussion mit ihm nicht möglich war. SIFT/UFT weist folgende 
Mängel auf:

·	der Zeichensatz des Protokolls ist nicht spezifiziert

·	als Dateitypen sind nur propritäre VM-Files vorgesehen

·	das Datumformat ist nicht spezifiziert

·	die Zeichensätze der Dateien sind nicht spezifiziert

·	Designfehler in der DATA-Anweisung: ein String ,EOF" in der zu übertragenden 
Datei führt zum Abbruch der Übertragung

·	die Return Codes des Servers sind nicht spezifiziert

·	Rick Troth ist anscheinend der einzige, der SIFT/UFT real benutzt; es ist nur ein 
einziger Server bekannt (ua1vm.ua.edu), der nicht mal selber RFC 1440 konform 
ist

Somit war eine Projektrealisation auf Basis von SIFT/UFT nicht möglich und es 
mußte ein eigenes Protokoll entwickelt werden.

1.3  Das SAFT Protokoll

Als Grundlage für den asynchronen Filetransfer wurde das SAFT-Protokoll entwik-
kelt:

	Simple Asynchronous File Transfer

Wesentliche Merkmale sind:

·	Betriebssystemunabhängigkeit	
SAFT soll auf möglichst allen Computersystemen im Internet verfügbar sein.

·	Einfachheit 	
,keep it simple": ein überschaubares Protokoll auf ASCII-Basis, so daß es leicht mit 
telnet auf den Serverport zu debuggen ist.

·	Erweiterbarkeit		
spätere Erweiterungen sollen keine künstlichen Grenzen behindern. Als abschrecken-
des Beispiel sei die 7 Bit Beschränkung von smtp / RFC 822 genannt.

Quasi als ,Abfallprodukt" wurden noch asynchrone Nachrichten (,messages") als weite-
rer Internetdienst integriert. Bei solch einer Nachricht handelt es sich um einen einzeiligen 
Text, der normalerweise direkt auf das Terminal des Empfängers geschrieben wird.

SAFT ist ein Client/Server-Protokoll. Der SAFT-Client, typischerweise ein Userpro-
gramm, verschickt Dateien oder Nachrichten via Internet an den SAFT-Server, welcher sie 
entgegennimmt und an den lokalen Adressaten direkt ausliefert oder in einem Spoolbe-
reich zwischenlagert, wo sie dann der Adressat mittels eines Receive-Clients abholen 
kann. Die Funktionsweise ist ähnlich wie bei normaler Internet-mail.

Der Spooling-Mechanismus und der Receive-Client werden nicht von SAFT beschrieben, 
sondern bleiben der jeweiligen Implementation überlassen. SAFT definiert nur das reine 
Übertragungsprotokoll.

SAFT unterstützt folgende Dateiattribute:

·	Dateiname in Unicode [19] mit beliebiger Länge

·	Zeitstempel		
Spezifikation nach ISO-8601 [7] (UTC full date & time)

·	BINARY	
unstrukturierter Bytestrom

·	SOURCE		
Datei besteht aus einzelnen Zeilen jeweils beliebiger Länge mit CR/LF als EOL Mar-
kierung

·	TEXT		
wie Source, nur daß zusätzlich das Attribut CHARSET (siehe unten) ausgewertet wird

·	Name des Zeichensatzes		
Spezifikation nach RFC 1345 [14]

·	Betriebssystemspezifische Attribute		
Diese können bei der ersten SAFT-Implementation für das jeweilige Betriebssystem 
vom Autor beliebig verwendet werden. Kompatibilität ist dabei aus prinzipiellen 
Gründen nur zwischen Client und Server desselben Betriebssystems gewährleistet.

SAFT kann Dateien mittels gzip Algorithmus komprimiert übertragen. Dieses stellt kein 
Dateiattribut sondern ein Übertragungsmerkmal dar. Für den Sender und Empfänger 
geschieht dies völlig transparent. Diese Komprimierung wurde eingeführt, um Netzband-
breite zu schonen. Der Flaschenhals eines Filetransfers stellt in der Regel das Netz dar 
und nicht die Leistungsfähigkeit der lokalen CPU.

SAFT benutzt tcp als Transportmedium und den tcp-Port 487. Der SAFT-Client stellt 
eine Verbindung zu diesem Port auf dem Host des SAFT-Servers her.

Die Client/Server Kommunikation ist zweigeteilt, sie setzt sich aus dem eigentlichen 
Kommunikationsprotokoll und der zu übertragenden Datei als ,data-stream" zusam-
men.

Das Kommunikationsprotokoll ist NVT-konform, also 7 bit ASCII ohne Steuerzeichen 
und CR/LF (ASCII 13 und ASCII 10) als EOL Markierung. HT (ASCII 9) ist zwar 
zulässig, sollte aber vermieden werden.

Ein Kommando vom Client besteht aus einer Zeile, die ein Befehlswort und je nach 
Bedarf ein oder mehrere Parameter enthält, getrennt durch Whitespace. Ein White-
space ist eine nicht-Null Zeichenfolge aus SPACE (ASCII 32) oder HT (ASCII 9) in 
beliebiger Reihenfolge. Nach Möglichkeit sollte immer ein einzelnes SPACE als 
Whitespace verwendet werden.

Als Kommandos sind definiert:

·	FROM <sender> [<real name>]
Absender Loginname und optional echter Name und pgp Signatur.

·	TO <recipient>		
Empfänger Loginname

·	FILE <name>	
Name der zu übertragenden Datei

·	DATE <date>		
Zeitstempel der Datei in UTC ISO-8601 Format (YYYY:MM:DD hh:mm:ss)

·	TYPE BINARY|SOURCE|TEXT [COMPRESSED]		
Typ der Datei.

·	CHARSET <name>	
Name des Zeichensatzes einer Textdatei nach RFC 1345 (&charset Eintrag) . Ali-
ase sind nicht erlaubt. Wenn möglich sollte ISO_8859-1:1987 verwendet werden.

·	ATTR <attribute-string>	
Betriebssystemspezifische Dateiattributerweiterung, implementationsabhängig.

·	MSG <message>		
Einzeilige Nachricht, die direkt auf das Terminal des Empfängers ausgegeben 
werden soll.

·	DEL		
Datei, die zuvor übertragen wurde, wird gelöscht.

·	RESEND		
Die Datei soll nach vorhergehenden Übertragungsabbruch erneut geschickt werden. 
Die Serverantwort enthält als erster String die Anzahl der bereits übertragenen Bytes: 
<transmitted> 

·	SIZE <size> <size uncompressed>	
Größe der zu übertragenden Datei in Bytes: die erste Zahl stellt die tatsächlich zu 
übertragenden Bytes dar, die zweite die Größe der Datei nach der Dekomprimierung.

·	DATA		
Ab hier folgen <size> - <transmitted> Bytes der Datei als aufeinanderfolgender 
Strom von 8-bit Bytes.

·	QUIT		
Ende der Verbindung

Die Befehlswörter können in Groß- oder Kleinbuchstaben oder sogar gemischt geschrie-
ben werden. FROM, from oder FrOm sind gleichbedeutend. Nach Möglichkeit sollten 
alle Befehlswörter aber einheitlich in Großbuchstaben geschrieben werden.

<sender>, <real name>, <recipient>, <name> und <message> sind UTF-7 [20] kodierte 
Strings. Nach Möglichkeit sollten hier nur NVT-ASCII oder ISO Latin-1 Zeichen [14] 
enthalten sein.

Zur Übertragung einer Datei müssen mindestens die Kommandos FROM, TO, FILE und 
SIZE angegeben werden. DATA startet dann den eigentlichen Transfer. Die anderen 
Kommandos sind optional. Die Reihenfolge der Kommandos spielt im Allgemeinen keine 
Rolle. Ausnahme sind (Format: Kommando (Kommandos, die vorhergehen müssen)):

·	DATA ( FROM, TO, FILE , SIZE )

·	MSG ( FROM , TO )

·	RESEND ( FROM, TO, FILE )

·	DEL ( FROM, TO, FILE, DATE, SIZE )

Jedes dieser Kommandos wird vom Server mit einer sogenannten ,reply-message" beant-
wortet, die folgendermaßen aufgebaut ist:

Antwort	=	{reply-line} reply-end

reply-line	=	reply-code "-" text

reply-end	=	reply-code " " text

reply-code	=	number number number

number	=	"0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

text	=	char {char} CR LF

char	=	<Zeichen aus NVT-ASCII Zeichensatz>

 CR ist ASCII 13, LF ist ASCII 10. Die erste Ziffer (number) des reply-code gibt Aus-
kunft über die Kategorie der Antwort:

·	2 steht für: korrekte Kommandodurchführung

·	3 steht für: weitere Daten/Informationen werden benötigt

·	4 steht für: fataler Fehler mit anschliessendem Verbindungsabbruch

·	5 steht für: sonstiger Fehler, der aber durch weitere Kommandos wieder behebbar 
ist



Definiert sind folgende ,reply-messages":

·	200 Command o.k..

·	201 File has been correctly received.

·	202 Command not implemented, superfluous at this site.

·	205 Non-ASCII character in command line ignored.

·	214 <help-text>

·	220 <hostname> SAFT server (sendfiled <version> on <OS>) ready.

·	221 Goodbye.

·	230 <number> Bytes already received.

·	302 Header ok, send data.

·	410 Spool directory does not exist.

·	411 Can`t create user spool directory.

·	412 Can`t write to user spool directory.

·	415 TCP error: received too few data.

·	421 Service not available.

·	451 Requested action aborted: local error in processing.

·	452 Insufficient storage space.

·	453 Insufficient system resources.

·	500 Syntax error, command unrecognized.

·	501 Syntax error in parameters or arguments.

·	502 Command not implemented.

·	503 Bad sequence of commands.

·	504 Command not implemented for that parameter.

·	505 Missing argument.

·	510 This SAFT-server can only receive messages. Send files to xx@yy

·	511 This SAFT-server can only receive files.

·	520 User unkown.

·	521 User is not allowed to receive files or messages.

·	522 User cannot receive messages.

·	523 You are not allowed to send to this user.

·	530 User cannot receive messages.

·	531 This file has been already received.

·	599 Unknown error.

 Nur die aus 3  Ziffern bestehende Replycodes sind fest vergeben, die Texte dahinter kön-
nen beliebig verändert werden, solange sie weiterhin dem Sinn der Meldung entsprechen. 
Ausnahmen hiervon sind die Texte zu den Replycodes 220 und 230:  bei 220 muß der  
String , SAFT " enthalten sein und bei 230 muß das erste Wort im Text die Anzahl der 
bereits übertragenen Bytes sein.

1.3.1  Beispiele

Beispiele einer SAFT-Session anhand eines direkten telnet Zugriffs auf den Serverport 
(fett gedruckte Textteile sind Benutzereingaben):



> telnet linux saft

Trying 129.69.58.50...

Connected to linux.rus.uni-stuttgart.de.

Escape character is '^]'.

220 linux SAFT server (sendfiled 1.4 on Linux) ready.

FROM gaga

200 Command ok.

TO framstag

200 Command ok.

FILE blubb

200 Command ok.

SIZE 5 5

200 Command ok.

DATA

302 Header ok, send data.

ABC

201 File has been correctly received.

QUIT

221 Goodbye.

Connection closed by foreign host.

> telnet linux saft

Trying 129.69.58.50...

Connected to linux.rus.uni-stuttgart.de.

Escape character is '^]'.

220 linux SAFT server (sendfiled 1.4 on Linux) ready.

HELP

214-The following commands are recognized:

214-  FROM <sender> [<real name>] [<pgp signature>]

214-  TO <recipient>

214-  FILE <name>

214-  SIZE <size to transfer> <size uncompressed>

214-  TYPE BINARY|SOURCE|TEXT [COMPRESSED]

214-  DATE <ISO-8601 date string>

214-  CHARSET <RFC-1345 character set name>

214-  ATTR TAR|EXE|NONE

214-  MSG <message>

214-  DEL

214-  RESEND

214-  DATA

214-  QUIT

214-All argument strings have to be UTF-7 encoded.

214 You must specify at least FROM, TO, FILE, SIZE and DATA to send a file.

FROM gaga

200 Command ok.

TO dengibtsnicht

520 User unkown.

TO framstag

200 Command ok.

MSG huhu!

530 User cannot receive messages.

TYPE TEXT

200 Command ok.

FILE x1

200 Command ok.

SIZE 6 6

200 Command ok.

abcd

500 Syntax error, command unrecognized.

DATA

302 Header ok, send data.

abcd

201 File has been correctly received.

FILE x2

200 Command ok.

SIZE 3 3

200 Command ok.

SIZE 5 5

200 Command ok.

DATA

302 Header ok, send data.

123

201 File has been correctly received.

QUIT

221 Goodbye.

Connection closed by foreign host.

Eine Anmerkung zur anscheinenden Diskrepanz bei SIZE und DATA: telnet überträgt 
eine Zeile mit CR LF als EOL-Markierung. Diese Bytes zählen natürlich mit.

1.3.2  Begründung des Protokolldesigns

Die Ablehnung von SIFT/UFT wurde bereits weiter oben besprochen. Als weitere bereits 
existierende Alternativen wurden untersucht:

·	http		
Das Hyper Text Transfer Protocol [12] ist zu sehr spezialisiert auf Dokumente mit 
,festem Platz". Es geht davon aus, daß Dateien immer unter derselben Adresse anzu-
finden sind. Außerdem kann man mit der derzeitigen http Spezifikation Dateien nur 
holen, nicht aber verschicken.

·	fsp		
Das File Service Protocol kennt nur einen anonymous User und keine realen Benutzer 
als Adressaten. Zudem benutzt es udp als Transportmedium, was es zwar sehr sicher 
gegenüber Netzproblemen aber auch recht langsam macht.

·	smtp mit MIME		
Das Simple Mail Transport Protocol mit Multipurpose Internet Mail Extensions [11] 
[16] [17] ist zwar das flexibelste Transportprotokoll für Dokumente aller Art, aber lei-
der auch eins der ineffektivsten was den Datendurchsatz angeht und Aufgrund der 7 
bit Restriktion von smtp am schwersten zu implementieren. Dies verdeutlicht die Tat-
sache, daß es selbst Jahre nach der Einführung von MIME noch keinen brauchbaren 
freien MUA für Unix oder VMS gibt.

Als große Probleme stellten sich die Wahl des Zeichensatzes für Textdateien und das For-
mat der Dateinamen heraus. Für beide liessen sich keine gemeinsame Basis finden, die 
allen Betriebssystemen im Internet gerecht werden würde.

Der einzige Zeichensatz, der eine echte Obermenge aller anderen Zeichensätze ist, ist 
ISO-10646 aka Unicode [9] [10] [19]. Unicode basiert aber auf 16 bit breiten Zeichen und 
hat noch keine nennenswerte Verbreitung gefunden. Deshalb erlaubt SAFT die Verwen-
dung eines beliebigen in RFC 1345 definierten Zeichensatzes und überläßt die korrekte 
Konvertierung der Empfängerseite. Empfohlen wird jedoch die Verwendung von ISO-
8859-1 aka ISO Latin 1 [14], da dies von der Anzahl der Benutzer und installierten 
Systeme her führend ist.

Beim Format des Dateinamens stellt sich ein ähnliches Dilemma. Stellvertretend seien 
hier einige verbreitete Betriebssysteme bzw. Filesysteme genannt:

·	DOS		
8+3 Zeichen; alle Zeichen bis auf . und \

·	VM und MVS		
8+8 Zeichen; A..Z 0..9

·	VMS/RMS	 
39+39 Zeichen; A..Z 0..9 $ _ - ; $ - nicht am Anfang; Versionsnummern

·	Unix < SysV 4.0		
14 Zeichen; alle Zeichen bis auf ASCII(0) und /

·	Unix >= SysV 4.0 und BSD		
255 Zeichen; alle Zeichen bis auf ASCII(0) und /

·	Windows NT		
255 Zeichen; alle Unicodezeichen (?)

Ein kleinster gemeinsamer Nenner ließ sich hier nicht bilden. Deshalb erlaubt SAFT 
bei Dateinamen die Verwendung von Unicodezeichen und beliebige Länge. Der Client 
kann aber nicht sicher sein, daß der Dateiname auf dem Empfängersystem verarbeitet 
werden kann. Deshalb sollten bei Unkenntnis der Möglichkeiten des Empfängersy-
stems eher konservative Werte benutzt werden.

Der Flaschenhals bei praktisch jeder Kommunikation im Internet stellt die zur Verfü-
gung stehende Bandbreite dar. Deshalb kann SAFT Dateien mittels gzip Algorithmus 
komprimiert übertragen. gzip wurde ausgewählt, weil es

·	lizenzfrei ist (GNU Copyleft)

·	sehr gute Kompressionsraten liefert

·	auf praktisch allen Betriebssystemen verfügbar ist

·	einen Quasistandard im Internet darstellt

Viele Betriebssysteme bieten weitere Dateiattribute, als die von SAFT abgedeckten 
an. Diese Attribute sind aber Filesystem-proprietär und nicht zwischen verschiedenen 
Betriebssystemen konvertierbar. VMS/RMS kann z.B. nichts mit dem Hidden-bit von 
DOS/FAT anfangen, während wiederum auf allen anderen Betriebssystemen die FDL 
von VMS/RMS keinen Sinn macht.

Deshalb wurde das ATTR Kommando eingeführt, welches nur für das jeweilige 
Betriebssystem von Relevanz ist. Jeder Autor einer neuen SAFT Implementation kann 
das ATTR Kommando für sein Betriebssystem erweitern, indem er neue Parameter 
einführt (siehe Kapitel sendfile weiter unten). Er sollte dies jedoch dokumentieren und 
dem Autor von SAFT zwecks Koordination melden.

Die Verwendung von MIME [16] [17] zur Spezifizierung von Dateiattributen wurde 
verworfen, weil MIME Dokumente beschreibt, die visualisiert werden sollen. Hierbei 
wird der Inhalt einer Datei meist einer nicht reversiblen Transformation unterworfen, 
was in Hinblick auf die eigentliche Aufgabenstellung nicht wünschenswert ist.

2  sendfile: eine SAFT Referenzimplementation für Unix

Das sendfile Paket ist eine Umsetzung des SAFT Protokolls für Unix-Systeme und umfaßt 
die Teile:

·	sendfiled		
der sendfile daemon, ein SAFT-Server 

·	sendfile		
ein SAFT-Client zum Verschicken von Dateien

·	sendmsg		
ein SAFT-Client zum Verschicken von Nachrichten

·	receive		
ein Client, der bereits empfangene Dateien aus dem lokalen Spool abholt

·	Utilities: 

- check_sendfile: informiert beim login auf files im sendfile-Spool

- sf_cleanup: räumt alte Files aus dem Spool

·	Dokumentation:

- man-pages: Hilfetexte im Standard-Unix-Format

- LIESMICHe bzw. READMEs: Kurze Hilfetext für schnelle Information

- doku.ps bzw. doc.ps: dieses Dokument

Der sendfile-Client ist ein Userprogramm, das Dateien an den sendfiled verschickt, wel-
cher sich auf demselben Host befinden kann oder sonst irgendwo im Internet. Der sendfi-
led nimmt die Dateien entgegen, legt sie im Spoolbereich ab und informiert den 
Empfänger mit einer Nachricht, die direkt auf sein Terminal geschrieben wird. Der Emp-
fänger kann sich dann die Dateien mittels des receive-Clients in sein Directory kopieren, 
wobei das Original im Spool gelöscht wird. Der sendmsg-Client ist ein Userprogramm, 
das einzeilige Textnachrichten an den sendfiled verschickt, welcher sie dann direkt auf das 
Terminal des Empfängers schreibt.

Das sendfile-Paket setzt voraus, daß die Programme gzip, tar und GNU-recode (letzteres 
optional) bereits installiert sind und zur Installation der gcc-Compiler vorhanden ist. Ver-
wendete Programmierstandards sind ANSI-C, POSIX 1003.1 und BSD sockets.

2.1  Programmbeschreibung

2.1.1  sendfiled

Der sendfiled muß nur einmal installiert werden (siehe weiter unten) und läuft dann ohne 
weitere direkte Benutzeraktion, da er automatisch vom inetd gestartet wird. Er verhält sich 
damit analog zu einem ftpd.

sendfiled legt ankommende Dateien im Spool-Directory des Empfängers ab und gibt 
ankommende Nachrichten (messages) auf den tty des Empfängers aus, sofern dies 
nicht durch die Konfigurationsdateien verboten wurde (siehe weiter unten).

Das Spoolverzeichnis ist normalerweise /var/spool/sendfile/username (sofoern beim 
installieren nicht anders spezifiziert).

Zum sendfiled gehören zwei Konfigurationsdateien: nosendfile und sendfile.cf, die 
normalerweise in /usr/local/etc/ liegen. 

In nosendfile können lokale Benutzer eingetragen werden, die keine Dateien oder 
Nachrichten erhalten sollen, also vom SAFT-Service ausgeschlossen werden sollen. 
dies sind normalerweise Pseudo-User wie ftp, news, admin, root, nobody, lpd, etc. 

Steht in nosendfile in der ersten Zeile allow-only,bewirkt dies, daß jetzt nur noch 
die nachfolgend aufgeführten Benutzer Dateien oder Nachrichten empfangen können.

In sendfile.cf stehen Optionen, die das genau Verhalten des sendfiled steuern und die 
jederzeit geändert werden können. Die Bezeichnungen sind im wesentlichen Selbster-
klärend. Hier ein Beispiel:



# sendfile configuration file



# ring the gong when a message arrives (on/off)

bell = on



# maximum allowed files to receive per user

maxfiles = 200



# maximum total disk space quota for spool in MB

# (WARNING! Defining this option will sendfile slow down!)

# maxspool = 100



# minimum free disk space for spool partition in MB

minfree = 10



# accept only messages or files

# acceptonly = messages



# address of your generic SAFT-server (for NFS)

# saftserver = saft.banana.net



# notify by message, mail, both or none

notification = message



# keep spool files at least xx days, then delete them (0=infinity)

keep = 0



# delete aborted or corrupted spool files after xx days (0=never)

deljunk = 10



maxspool beschränkt die maximale Anzahl an belegten MBs im Spool (total), wärend 
minfree ein Minimum an freien MBs in der Spool Partition garantiert. Die Unterschei-
dung ist deshalb sinnvoll, weil der Spool nicht in einer eigenen Partition sein muß, son-
dern nur ein Directory-Baum innerhalb einer Partition sein kann, die auch noch anderen 
Zwecken dient.

Die Optionen keep und deljunk werden durch den Aufruf von receive oder durch 
ankommende Files über sendfiled getriggert. Um sicher zu gehen, daß auch alte Files von 
allen Usern gelöscht werden, gibt es das Programm sf_cleanup. Dies kann bei Bedarf 
gestartet werden (einmal pro Woche oder so).

Mit NFS tut sich sendfile etwas schwer, weil NFS keinerlei Locking-Mechanismus besitzt 
und es so zu Race Conditions und Datenkorruption kommen kann, wenn auf den sendfile-
spool via NFS zugegriffen wird (wenn /var/spool/sendfile via NFS gemountet wird). Mit 
folgendem Workaround funktioniert sendfile aber auch in einer NFS-Umgebung:

·	Auf NFS-Clients in sendfile.cf eintragen:

acceptonly = messages

saftserver = nfs.server.host.name

·	Auf dem NFS-Server in sendfile.cf eintragen:

notification = mail

Wenn jetzt versucht wird, an einen NFS-Client ein File zu schicken, kommt folgende Feh-
lermeldung (Beispiel):

$ sendfile LIESMICH framstag@moep.bb.bawue.de

%sendfile-F, server error: For sending files use: 
framstag@syssrv.bb.bawue.de

Messages können trotzdem weiterhin verschickt werden.

In beiden Konfigurationsdateien dient ein # als Kommentarzeichen, d.h. alles inklusive 
diesem Zeichen bis Zeilenende wird ignoriert.

Als Unix-betriebssystemspezifische Erweiterung des SAFT-Protokolls wurden die Attri-
but TAR und EXE eingeführt. TAR erlaubt alle Unix-Fileattribute mit zu übertragen. Hat 
eine Datei das tar-Attribut, so handelt es sich um ein tar-Archiv nach POSIX 1003 und 
diese wird vom receive-Client dann entsprechend behandelt. EXE sagt aus, daß die über-
tragene Datei ein ausführbares Programm (z.B. executable oder Shell-Script) ist. Der 
receive-Client setzt dann die korrekte Protection. Alle POSIX kompatiblen Betriebssy-
steme, wie z.B. VMS und Windows NT, können auch diese erweiterte Attribute überneh-
men, sollte für diese Systeme eine SAFT-Implementation realisiert werden.

2.1.2  sendfile

Der sendfile-Client ist ein Userprogramm, das Dateien an den Empfänger verschickt. Der 
Aufruf von sendfile -h ergibt die Ausgabe:

usage: sendfile [-stuvd] file-name [...] user[@host]

 or: sendfile [-uva] archive-name file/directory-name [...] user[@host]

 -s send file(s) in source mode

 -t send file(s) in text mode

 -u send file(s) uncompressed

 -v verbose mode

 -a send file(s) as one archive

 -d  delete previous sent file(s)

 ( default mode: send file(s) in binary mode and compressed )

example: sendfile rabbit.gif beate@juhu.lake.de



Im einfachsten Fall reicht die Zeile (Beispiel) 

sendfile bdsm.txt andrea 

um die Datei bdsm.txt an den lokalen Benutzer andrea zu schicken.

sendfile verschickt dann die Datei binär, d.h. ohne jede Veränderung, und komprimiert 
(Falls es sich um eine komprimierbare Datei handelt).. Die Anzahl der übertragenen 
Bytes wird immer angezeigt. Es können aber auch die folgenden Optionen angegeben 
werden:

-s	behandelt die zu verschickende Datei als Programm Sourcecode. Dies ist nur 
notwendig, wenn das Empfängersystem kein Unix ist.

-t	behandelt die zu verschickende Datei als Text. Beim Textmodus werden 
Umlaute und andere Sonderzeichen korrekt gewandelt. Dies ist nur notwendig, 
wenn das Empfängersystem kein Unix ist.

-u	verschickt unkomprimiert. Default ist komprimierte Übertragung. Dies sollte 
nur dann verwendet werden, wenn sich Sender und Empfänger auf dem selben 
Host befinden. Komprimierte Übertragung ist ein wesentliches Mittel zur Reduk-
tion von Netzlast.

-v	gibt alle SAFT-Meldungen mit aus (verbose mode). Dies dient zur Lokalisa-
tion von Protokollfehlern oder zur Befriedigung der Neugier (,Was geht denn da 
ab?").

-a	schickt mehrere Dateien oder ganze Verzeichnisbäume als ein Archiv. Das 
erste Argument nach -a gibt den Namen des Archivs an. Diese Option ist nur gül-
tig, wenn das Empfängersystem ebenfalls ein Unix ist.

-d	löscht eine vorher verschickte Datei auf dem Serversystem, vorausgesetzt, es 
befindet sich dort noch im Spool.

Die Optionen -s -t, -d und -a schließen sich jeweils gegenseitig aus.

Als user-Name darf auch ein elm-Alias verwendet werden, wenn kein sendfile-Alias 
(siehe weiter unten) gleichen Namens vorhanden ist und der elm-Alias auf eine echte 
Internet-Adresse zeigt.

Weitere Beispiele:

sendfile -s *.pas uranus@bigvax.inka.de

sendfile -va C-Projekt sendfile doku.ps uwe

2.1.3  sendmsg

Der sendmsg-Client ist ein Userprogramm, das einzeilige Textnachrichten an den sendfi-
led verschickt, welcher sie dann direkt auf das Terminal des Empfängers schreibt.

Der Aufruf von sendmsg -h ergibt den Output:

usage: sendmsg [-v] user@host

or: sendmsg [-mM]

options: -v verbose mode

         -m receive messages only on this tty (default)

         -M receive messages on other ttys, too

example: sendmsg orakel@main01.bb.bawue.de



sendmsg verlangt nach Aufruf, die zu übertragende Nachricht einzugeben.

Als user-Name darf auch ein elm-Alias verwendet werden.

Beispiel:

sendmsg framstag@moep.bb.bawue.de

message: geiles Programm, das sendfile!



Ankommende Nachrichten werden normalerweise (sofern via Konfigurationsdatei nicht 
anders geregelt) auf allen ttys des Empfängers ausgegeben. Wird der Empfänger selbst 
zum Sender, indem er sendmsg aufruft (z.B. mit sendmsg -m), so werden ab sofort Messa-
ges nur noch auf diesem tty ausgegeben.

2.1.4  receive

Der Empfänger kann sich die Dateien mittels des receive-Clients in sein Directory kopie-
ren, wobei das Original im Spool gelöscht wird.

Der Aufruf von receive -h ergibt den Output:

usage: receive [-d] file-name

   or: receive -n [-dr] file-number

   or: receive [-l] [-L]

   or: receive -a [-dr]

options: -l  short list of files

         -L  full list of files

         -n  specify a file number

         -a  specify all files

         -d  delete

         -r  rename file when receiving

examples: receive -a      ! receive all files

          receive -n 1    ! receive file with number 1

          receive blubb   ! receive file with name blubb

Im einfachsten Fall gibt der Benutzer an (Beispiel): 

receive blubb.txt

%receive-I, blubb.txt received

Dies kopiert die Datei blubb.txt ins aktuelle Directory und löscht sie aus dem Spool.

Weitere Optionen sind:

-d	löscht die Datei ohne sie vorher zu kopieren

-n	anstelle des Dateinamens wird seine Spoolnummer verwendet

-a	alle Dateien abholen bzw. löschen

-l	auflisten der Dateien

-L	auflisten der Dateien und Inhalt der Archive mit ausgeben

-r	umbenennen der Datei beim abholen

Weitere Beispiele:

receive -l

From zrxh0370@baracke.rus.uni-stuttgart.de (Ulli Horlacher)

 1) 10-Aug-1995 15:41:24      3 KB  LIESMICH

 2) 10-Aug-1995 15:41:37     30 KB  doku.txt

 3) 11-Aug-1995 16:12:09    113 KB  Sourcen (archive)



receive -n 1

LIESMICH already exists. Overwrite it (yYnN)? y

%receive-I, LIESMICH received



receive -d Sourcen

%receive-I, Sourcen deleted

Existiert eine Datei gleichen Namens bereits, so fragt receive nach, ob es sie über-
schreiben soll. Ist die Eingabe Y oder N oder so werden bei anderen Dateien keine 
weiteren Fragen gestellt, sondern diese einfach überschrieben bzw. übergangen. Bei y 
oder n wird jedesmal neu nachgefragt.

Der Dateiname darf auch * oder ? als Wildcard-Zeichen enthalten, allerdings ist durch 
Einschliessung in '' Quote-Zeichen dafür zu sorgen, daß die Shell die Metazeichen * 
und ? nicht vorher selber interpretiert.

Enthält eine Datei besondere Zeichen, wie Unicodezeichen, Controlcodes oder Shell-
metazeichen, so frägt receive nach, in welchem Format der Dateiname abgespeichert 
werden soll.

Beispiel:

receive 'gaga*'

The next file name contains characters which may cause problems with 
your shell or may do strange things with your terminal.

These characters have been substituted with '_'.

(c)omplete file name with control code characters is not displayable

(n)ormal file name: >gaga blubb<

(s)hell file name: >gaga_blubb<

Select one of c n s (or C N S for no more questions): n

gaga blubb already exists. Overwrite it (yYnN)? y

%receive-I, gaga blubb received

Wenn Dateien bereits aus dem Spool gelöscht worden sind, besteht trotzdem noch eine 
Möglichkeit herauszubekommen, wer was geschickt hatte. Mit 

more /var/spool/sendfile/$LOGNAME/log 

läßt sich die sendfile-Protokolldatei anschauen.

2.2  Benutzerkonfigurationsdateien

Sowohl sendfile als auch sendmsg greifen auf diverse benutzerspezifische Konfigurations-
dateien zurück, die alle unter /var/spool/sendfile/username/config/ liegen. Diese Dateien 
werden per default vom sendfiled angelegt, sobald der entsprechende Benutzer zum ersten 
mal etwas empfangen sollen. Ihre Erzeugung kann also z.B. mit: sendmsg $LOGNAME 
erzwungen werden.

Es handelt sich bei diesen Konfigurationsdateien um:

·	config

Hier können die globale Konfigurationsoptionen bell und notification (aus /usr/local/
etc/sendfile.cf) überschrieben werden:

  bell = on                        # Bimmel an

  bell = off                       # Bimmel aus

  notification = none              # keine Benachrichtigung fuer Files

  notification = message           # Benachrichtigung via msg

  notification = mail              # Benachrichtigung via mail

  notification = both              # Benachrichtigung via mail und msg

  notification = mail blubber@blah # Benachrichtigung via mail an ...



·	aliases

Hierbei handelt es sich um ein Aliasfile, in dem oft benutzte Adressen abgekürzt wer-
den können. Das Format ist:

	alias address

Beispiel:

chief grmblfz@bigvax.somewhere.net

beate beate@juhu.lake.de



·	restrictions

Hier drin stehen Adressen, von denen man keine Dateien oder Nachrichten bekom-
men möchte. Das Format ist:

	user@host [mfb]

Dabei steht m für Message, f für File und b für both. Beispiele:



gates@microsoft.com b

*aol.com m



·	msg

Hier drin steht der Name des tty auf das ankommende Nachrichten ausgegeben 
werden sollen. Wird automatisch von sendmsg gesetzt.

2.3  Installation

Es wird vorausgesetzt, daß grundlegende Kenntnisse der Administration einer vernet-
zen Unix-Workstation vorhanden sind. Diese hier zu erklären, würden bei weitem den 
Rahmen der  Dokumentation sprengen.

1.	Pfade anpassen:

Bei Bedarf können in config.h (und NUR da!) Default-Werte für bestimmte Pfade 
geändert werden. Dies sind:



#define BINDIR 		"/usr/local/bin"

#define MANDIR 		"/usr/local/man/man1"

#define SERVERDIR 	"/usr/local/sbin"



#define SPOOL 		"/var/spool/sendfile"

#define NOSENDFILE 		"/usr/local/etc/nosendfile"

#define CONFIG 		"/usr/local/etc/sendfile.cf"



Bei den ersten drei Werten handelt es sich Verzeichnis, in die sendfile installiert 
wird, bei den letzten drei um den Ort des Spool bzw. der Systemkonfigurationsda-
teien.



2.	Laufzeit-Konfiguration anpassen:

Der sendfiled wertet zur Laufzeit die Systemkonfigurationsdatei sendfile.cf aus 
(wird normalerweise nach /usr/local/etc/ kopiert, siehe oben). Dies kann entweder 
jetzt oder zu jedem späteren Zeitpunkt geändert werden, falls Bedarf besteht.



3.	alles compilieren: 

	make 

Es dürfen keine Fehlermeldungen auftreten. Auf manchen Systemen mit fehlerhaf-
ten System-Include-Files kann es zu Warnings kommen, die aber ignoriert werden 
können. Sendfile wurde bisher getestet unter AIX, BSDI, Convex-OS, Digital 
Unix, FreeBSD, HP-UX, IRIX, Linux, NeXTstep/Mach, OSF/1, SunOS 4, SunOS 
5 (Solaris 2) und Ultrix mit gcc 2.5.8.

Ultrix-ACHTUNG!  Bei Ultrix muss vor ,make all" noch ,sh5 genmake" einge-
geben werden (weil Ultrix-sh buggy ist)!





4.	alles automatisch installieren (muss root machen!):

	make install



oder von Hand installieren:

- korrekte Fileprotection einstellen:

	umask 022



- sendfiled hinkopieren, wo es Sinn macht, zB /usr/local/sbin, /usr/etc :

	cp sendfiled /usr/local/sbin/



- spool-directory anlegen (wie in config.h angegeben!):

	mkdir /var/spool/sendfile

	chmod 755 /var/spool/sendfile



 - Eintragung in /etc/services (bzw mit ,niload services ." bei NeXT):

 	saft 487/tcp # simple asychronous file transfer



 - Eintragung in /etc/inetd.conf:

 	saft stream tcp nowait root /wo/auch/immer/sendfiled

 

- inetd neu starten:

	kill -HUP <pid des inetd>

	/usr/sbin/inetd #(oder wo auch immer der inetd liegt)

 

- Userbeschränkung aktivieren (wie in config.h angegeben!):

 	cp nosendfile /etc

 

- man-pages installieren:

	cp sendmsg.1 sendfile.1 receive.1 /usr/man/man1



- notify-script installieren:

	$ cp check_sendfile /usr/local/bin

/usr/local/bin/check_sendfile in /etc/profile aufnehmen



- Clients installieren:

	cp sendfile sendmsg receive /usr/local/bin



5.	testen:

	sendfile LIESMICH $LOGNAME

	receive -l

	receive -n 1



6.	Ich bin sehr an Kommentaren und Bugreports interessiert. Geschenke via Post 
schicken. :-)

7.	Wer mir die Adresse seines neu installierten SAFT-Servers mitteilt, bekommt zur 
Belohnung ein schönes gif zugeschickt. :-)

8.	Es gibt eine Mailingliste, die ich von Hand führe und in der Ankündigungen zu 
updates und bugfixes geposted werden. Wer da aufgenommen werden möchte, 
sende mail an mich.

2.4  Sourcen

Das sendfile Paket besteht aus (Module und darin enthaltene Funktionen):

·	sendfile.c - Das sendfile Hauptmodul.

usage : print short help usage text 

whereis : search for program name in PATH 

send_data : send file data

clean_up: delete tmp-file

·	sendfiled.c - Das sendfiled Hauptmodul.

getline : get a command line 

writeheader : write one line to header spool file 

msg2tty : write a message to all ttys of the user 

mail2user : send a mail to the recipient

spoolid : get the next spool id number 

restricted : check killfile

wlock_file : write-lock a file

tlock_file : test the lock status of a file

·	sendmsg.c - Das sendmsg Hauptmodul.

usage : print short help usage text 

·	receive.c - Das receive Hauptmodul.

usage : print short help usage text 

receive_sf : receive a spool file 

list : list all spool files 

crlf2lf : translate NVT format file to Unix text format file 

fcopy : copy a file 

spawn : spawn a subprocess and direct output to a file

·	spool.c spool.h - Funktionen zum lesen und schreiben von Spoolfiles

out : send string conforming to NVT standard

scanspool : scan the spool directory and create structure lists 

delete_sf : delete a spool file 

·	reply.c reply.h - reply-codes für sendfiled.

reply: send string conforming to NVT standard

·	string.c string.h - Erweiterte Stringfunktionen.

str_trim : trim white spaces 

str_toupper : transform string to upper case 

str_tolower : transform string to lower case 

strins : insert one string in another 

simplematch : match a simple pattern 

·	utf7.c utf7.h - UTF-7 und Unicode Kodierungsroutinen.

utf2iso : UTF-7 to ISO Latin-1 decoding 

iso2utf : ISO Latin-1 to UTF-7 encoding 

iso2uni : transform ISO Latin-1 to Unicode 

add_char : add a char depending on its range 

decode_mbase64 : decode mbase64 string to Unicode 

encode_mbase64 : encode Unicode pstring to mbase64 

·	pstring.c pstring.h - Routinen zum Umgang mit Pascalähnliche Strings.

pstr_create : create a pstring

pstr_delete : delete a pstring 

pstr_addchar : add a char to a pstring 

pstr_assign : assign one pstring to another 

pstr_addstring : add a string to a pstring 

pstr_print : print a pstring 

·	message.c message.h - VMS-like Informations und Fehlermeldungsroutine.

message : print information, warning and error messages on stderr 

·	peername.c peername.h - Funktion zur Erkennung des aufrufenden Host über stdin.

peername : returns the peername of the connecting host on stdin 

·	io.c io.h - Socket read und write Funktionen.

readn : read n bytes from network socket 

writen : write n bytes to network socket 

·	net.c net.h - Verschiedener Netzwerkkram.

open_connection : open socket and connect to client 

sock_getline : get a line from the network socket 

sock_putline : send a line to the network socket 

getreply : get the reply on a command from the server 

sendheader : send a headerline and check the reply code 

·	destination.c destination.h - Bestimmung des Empfängers

destination: parsen von elm-aliasen und hostname-Daten.

·	config.h - Verschiedene Preprozessordefinitionen.

·	bsd.h - Das blöde AIX hat keine eigenen include-Files für sockets.

·	genmake - Shellscript zur Bestimmung des Betriebsystems und zur Generierung 
des Makefiles.

·	check_sendfile - Shellscript um zu überprüfen, ob Dateien im Spool vorliegen. 
Sollte von /etc/profile aufgerufen werden.

·	sf_cleanup - Shellscript zum löschen alter Files aus dem Spool.

·	install - automagic install-script

·	nosendfile - Liste aller Benutzer, die vom SAFT-Dienst ausgeschlossen sind.

·	sendfile.cf - sendfile-Systemkonfigurationsfile.

·	LIESMICH - Eine deutsche Installationsschnellhilfe.

·	LIESMICH.auch - Kurzbeschreibung von sendfile/SAFT

·	README - a quick installation guide

·	README.too - a short description of sendfile/SAFT

·	HISTORY - last changes

·	sendmsg.1 - Man-page für sendmsg.

·	sendfile.1 - Man-page für sendfile.

·	receive.1 - Man-page für receive.

·	doku.ps - Diese Dokumentation hier.

·	doc.ps - this documentation

2.4.1  Aufrufdiagramm

Modulübersicht 

2.4.2  Datenstrukturen

Von den Programm-Datenstrukturen, die implementiert wurden, sind 3 von Interesse 
(bei den restlichen handelt es sich um Standard C Typen wie int, char *, etc):

·	pstring - Strings mit Längeninformationen (von Pascal abgeleitet).

Die pstrings sind notwendig, um Unicode-Strings zu verarbeiten, welche 
ASCII(0) Zeichen enthalten können. Die normalen C-Strings vom Typ char* 
behandeln ASCII(0) als Ende des Strings und sind somit für Unicode unbrauchbar.

In Anlehnung an Pascal wurden die pstrings implementiert, deren Länge nicht 
durch ein Terminalzeichen definiert wird, sondern über extra Struktureinträge.

Die pstrings haben folgende Struktur:





struct {

	int size;	/* absolute Länge */

	int length;	/* belegte string-Länge */

	char *string;	/* der String selber ohne Terminierungssymbol */

}



size ist dabei die Speicherkapazität des pstrings, während length die tatsäch-
lich belegte Länge ist.

In *string steht der eigentlich Textstring.

Per Definition beginnt der Inhalt des pstring mit string[1] und nicht wie sonst 
üblich in C mit string[0]. Dies hat zwar zur Folge, daß pro pstring ein Byte ver-
schwendet wird, aber es hat gleichzeitig den Vorteil, leichter mit den Längenange-
ben rechnen zu können.

In string.c sind die pstring-Funktionen definiert, die im Zusammenhang mit den 
Unicode-Strings im sendfile-Paket benötigt werden.



·	filelist - Eine einfach verkettete Liste zum Speichern der Dateiattribute und deren  
Absender.

Pro Absender existiert eine Liste, pro Datei wird ein Listenelement angelegt, 
wobei die Liste nach dem Empfangsdatum aufwärts geordnet ist, d.h. die zuerst 
empfangene Datei wird als erstes Listenelement gespeichert.

Ein filelist-Element hat folgende Struktur:

struct filelist {

	int 

	id, 		/* id number */

	osize, 		/* original size */

	csize, 		/* compressed size */

	tsize, 		/* transfered size */

	flags; 		/* binary,source,text,compress and tar flag */

	char 

	rdate[30], 		/* receiving date */

	date[30], 		/* file date */

	charset[30], 		/* character set name */

	fname[MAXLEN]; 		/* UTF-7 file name */

	struct filelist *next; 		/* next list element */

};



id ist die eindeutige Dateinummer im Spool. Siehe dazu weiter unten.

osize ist die Originalgröße der Datei ohne Kompression.

csize ist die Größe der Datei, wie sie (komprimiert) übertragen wird.

tsize ist die tatsächlich Anzahl der übertragenen Bytes.

flags sind die Dateiattribute für SOURCE, TEXT, COMPRESS und TAR.

rdate ist das Empfangsdatum.

date ist das Originaldatum der Datei, wie sie der Sender mit angibt.

charset ist der Name des Zeichensatzattributs.

fname ist der Dateiname, UTF-7 codiert.

*next ist der Zeiger um die Liste zu verketten.



Die Definition von filelist und den Flags befindet sich in spool.h.



·	senderlist - Eine einfach verkettete Liste zum Speichern der Absender und der filelists.

Im Gegensatz zu den filelists existiert nur eine senderlist. Pro Absender wird ein 
Listenelement angelegt. 

Ein senderlist-Element hat folgende Struktur:

struct senderlist {

	char 

	from[MAXLEN],		/* sender */

	sig[MAXLEN];		/* authentification signature */

	struct filelist *flist; 	/* list of files */

	struct senderlist *next;	/* next list element */

};



from ist der Name des Absenders, UTF-7 codiert.

*flist ist der Zeiger auf die dazugehörige filelist.

*next ist der Zeiger auf das nächste Listenelement.



Die senderlist und filelists ergeben also zusammen folgende Struktur::

Diese Datenstruktur wird jedesmal neu erzeugt, wenn Informationen über Spoolfi-
les benötigt werden. Diese verketteten Listen können in einem C Programm 
wesentlich einfacher ausgewertet werden, als daß für jede Information das betref-
fende Spoolheaderfile explizit ausgelesen wird



Der Spool selber wird in /var/spool/sendfile angelegt, wo jeder Empfän-
ger bei Bedarf, d.h. wenn zum ersten mal eine Datei für ihn empfangen wird, auto-
matisch ein eigenes Spoolverzeichnis bekommt (im Source als userspool 
bezeichnet).

Im userspool befinden sich für jede empfangene Datei zwei Spoolfiles: das 
Spoolheaderfile und das Spooldatafile. Im Spoolheaderfile sind alle Dateiattribute 
eingetragen, die der Sender übermittelt hat, im Spooldatafile ist die Datei selbst als 
Bytestrom abgelegt, so wie sie übertragen wurde.Weiterhin befindet sich in die-
sem Directory das sogenannte log-File, in dem alle Übertragungen protokolliert 
werden.

Beispiel eines userspool:



baracke:~/sendfile> ll /var/spool/sendfile/zrxh0370/

-rw-------   1 zrxh0370 system     1176 Sep 13 18:03    1.d

-rw-------   1 zrxh0370 system      137 Sep 13 18:03    1.h

-rw-------   1 zrxh0370 system      994 Sep 13 18:03    2.d

-rw-------   1 zrxh0370 system      136 Sep 13 18:03    2.h

-rw-------   1 zrxh0370 system     5178 Sep 13 18:03    log



baracke:~/sendfile> cat /var/spool/sendfile/zrxh0370/1.h

FROM	gaga@linux.rus.uni-stuttgart.de 

FILE	blubb.txt

TYPE	TEXT

SIZE	5 5

DATE	1995-09-14 12:38:06

CHARSET	ISO_8859-1:1987



3  Danksagungen

Mein besonderer Dank geht an:

·	Lorenz Adena - für Featurewünsche und Betatesting

·	Thomas Beisel - für C Beratung, Postscripthexerei  und Betatesting

·	Uwe Berger - für Grundsatzdiskussion und Designhilfen

·	Beate Herrmann - für grundlegende Ideen, psychologische Betreuung und Betatesting

·	Andreas Ley - für jede Menge Hilfe bei obskuren C Problemen und für die peername 
Funktion

·	Shannon Miller - for his corrections to my english documentation

·	Uwe Obermüller - für viele Vorschläge und Betatesting

·	Bernd Onasch - für C Beratung

·	Ingo Wilken - für die simplematch Funktion

ohne deren Hilfe die Realisation dieses Projekts unmöglich gewesen wäre.

4  Informationsverzeichnis

[1] Andrew Tanenbaum: Computer Networks

[2] Bettina Reimer, Paul Müller: Kommunikationssysteme auf der Basis des ISO-
Referenzmodells

[3] Kernighan, Ritchie: Programmieren in C

[4] Jürgen Gulbins: UNIX

[5] W. R. Stevens: Advanced Programming in the UNIX Environment

[6] W. R. Stevens: UNIX Network Programming

[7] ISO-8601 - International Time and Date Representing

[8] C-FAQ-list in news.answers

[9] Umlaute-FAQ in de.comp.standards

[10] internationalization/programming-faq in news.answers

[11] mail/mime-faq in news.answers

[12] http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-spec-00.txt

[13] RFC 859 - ftp 

[14] RFC 1345 - Character Mnemonics & Character Sets

[15] RFC 1440 - SIFT/UFT: Sender-Initiated/Unsolicited File Transfer

[16] RFC 1521 - MIME

[17] RFC 1522 - MIME

[18] RFC 1543 - Instructions to RFC Authors

[19] RFC 1641 - Using Unicode with MIME

[20] RFC 1642 - UTF-7

[21] RFC 1700 - Assigned Numbers



Die RFCs sind zu finden unter ftp://ftp.uni-stuttgart.de:/pub/doc/standards/rfc/

Die FAQs sind zu finden unter ftp://ftp.uni-stuttgart.de:/pub/doc/faq/

5  Glossar

·	ASCII - American Standard Code of Information Interchange		
7 bit Zeichensatzkodierung der wichtigsten im amerikanischen Sprachraum vorkom-
menden Zeichen. Siehe RFC 1345.

·	Bitnet - Because It`s Time Network		
Aussterbendes weltweites Forschungsnetzwerk auf IBM RSCS Technologie. In vielen 
Belangen der Vorgänger zum Internet.

·	DOS - Diskette Operating System		
Primitiver Diskettenmonitor und Interrupthandler für i8088 PCs

·	EBCDIC - Extended Binary Coded Decimals Interchange Code	
IBMs Zeichensatz für ihre Großrechner.

·	EOL - End Of Line

·	FAT - File Availibility Table		
Filesystem für DOS.

·	FDL - File Definition Languange		
Filesystembeschreibungssprache für RMS.

·	ftp - file transfer protocol/program		
Standardmethode um Dateien zu transferieren (synchron). Siehe RFC 959.

·	GNU - GNU`s not Unix	
Ein fortlaufendes Projekt der Free Software Foundation um qualitativ hochwertige 
und lizenzfreie Software im Sourcecode der Internetgemeinde zur Verfügung zu stel-
len.

·	MIME - Multipurpose Internet Mail Extensions		
Multimediaerweiterungen für Mail. Siehe RFC 1341.

·	MUA - mail user agent		
Der Mailclient, den der Benutzer direkt verwendet.

·	MTA - mail transfer agent		
Der Mailserver (daemon), der vom MUA kontaktiert wird.

·	NVT - Network Virtual Terminal	
Remote login im Internet: telnet. Siehe RFC 854.

·	RFC - Request for Comment		
Internet Standard und Protokoll Beschreibungen.

·	RMS - Record Management System		
Das native Filesystem von VMS.

·	tcp/ip - transmission control protocol / internet protocol		
Netzwerk- und Transport-Ebene (ISO Level 3+4) des Internets. Siehe RFC 791/793.

·	VMS - Virtual Memory System	Das beste Betriebssystem der Welt von DEC :-) 
