Höhere Protokolle

DHCP und RADIUS

DHCP

• Anschluß über einen Ethernet-Hub oder -Switch
• Zugang durch drahtlose Netze (und evtl. einen Router zum drahtlosen Subnetz)
• Zugang vom Internet über eine Firewall
• Modemzugang über einen Modemserver

Günstig wäre es, wenn der Zugang eines Rechners zum Netz folgenden Anforderungen genügen würde:

• automatisiert, d. h. ohne manuellen Eingriff
• authentifiziert, d. h. nur zugelassene Systeme erhalten Zugriff
• vollständig (Netz-, System- und Anwendungskonfiguration)
• standardisiert, d. h. für alle Systeme in einheitlicher Form

Eine Lösung für dieses Problem bietet DHCP (Dynamic Host Configuration Protocol). Dieser Dienst ermöglicht es, einem Client dynamisch eine IP-Nummer und andere Netzwerkparameter, wie den Netzwerknamen, die Gatewayadresse, etc., zuzuweisen, ohne daß der Administrator den Rechner überhaupt zu Gesicht bekommt. DHCP ist dabei völlig unabhängig von der eingesetzten Plattform. Das heißt, es kann sowohl Windows-Maschinen wie auch zum Beispiel Unix-Rechner mit den Netzwerkeinstellungen versorgen. Um ein Mindestmaß an Verfügbarkeitsanforderungen zu erfüllen, sollte natürlich mehr als nur ein DHCP-Server vorhanden sein, da sonst dessen Ausfall die Funktion sämtlicher Clienten beeinträchtigt.

Das in RFC 2131 definierte Protokoll DHCP arbeitet nach dem Client-Server-Modell. Als Server wird ein Programm bezeichnet, das den Pool der zu vergebenden Nummern verwaltet und sich darum kümmert, daß eine Nummer nicht zweimal vergeben wird. Client oder Client ist ein Programm auf dem lokalen Rechner, das zunächst den Server selbsttätig im Netz suchen muß und ihn anschließend darum bittet, eine IP-Nummer zuzuteilen. Die Grundfunktion des Servers ist recht einfach aufgebaut: _ber eine Konfigurationsdatei teilt der Administrator ihm mit, welche Adreßbereiche er für die Weitergabe an Client zur Verfügung hat. Fragt ein Client nach einer IP-Adresse, dann muß der Server zunächst nachsehen, ob noch eine Adresse frei ist. Diese freie IP-Nummer liefert er an den Client aus. Gleichzeitig muß er eine Datei (Leases-File) führen, in der er protokolliert, welche Adresse bereits an wen vergeben ist. Bei der Adreßvergabe sind drei verschiedene Modi einstellbar:

• Automatic Allocation: Fordert ein Client eine IP-Nummer an, wird sie ihm auf unbegrenzte Zeit zugeteilt, solange noch Adressen zur Verfügung stehen. Sind alle Adressen verbraucht, kann kein neuer Client mehr konfiguriert werden, auch wenn ein Teil der zuvor bedienten Rechner im Moment gar nicht eingeschaltet ist.
• Manual Allocation: In dieser Betriebsart geht es nur darum, Verwaltungsaufwand zu minimieren. In der Konfigurationsdatei ist für jeden Client im Netzwerk eine IP-Nummer fest zugeordnet. Der Server ist lediglich für die Auslieferung der Adresse an den Client verantwortlich.
• Dynamic Allocation: Jeder Client bekommt auf Anfrage eine IP-Nummer, solange im definierten Pool noch Einträge frei sind. Der Unterschied gegenüber der Automatic Allocation besteht darin, daß die IP-Nummer nur für eine bestimmte, maximale Zeitspanne (Lease-Time) gültig ist und vom Client innerhalb dieser Zeit zurückgegeben werden kann, wenn sie nicht mehr benötigt wird. Als einzige der drei Betriebsarten erlaubt Dynamic Allocation, kleine IP-Nummern-Pools mit einer großen Anzahl von Rechnern zu teilen. Einzige Voraussetzung: nicht alle Maschinen dürfen gleichzeitg laufen. Damit lassen sich auch Computer, die eher selten ins Netzwerk integriert werden, wie Laptops, zuverlässig mit einer IP-Nummer versorgen. Wird der Rechner vom Netz getrennt, kann die Adresse für eine andere Station verwendet werden. In dieser Betriebsart werden die meisten DHCP-Server betrieben.

DHCP ist eine Erweiterung des BOOTP-Protokolls und konkurriert in seiner Basisfunktionalität mit RARP. Gegenüber BOOTP zeichnet es sich vor allem durch die Flexibilität bzüglich der abfragbaren Konfigurationsparameter und durch das Konzept der Lease aus, d. h. die Möglichkeit eine Information dem Client gegenüber als nur begrenzt gültig zu markieren. Damit wird die Flexibilität bei Veränderungen der Netztopologie und weiterer Konfigurationsparameter gewahrt. Ferner ist die Unterstützung von großen Netzen, in denen nichts stets alle Systeme zugleich aktiv sind, mit limitierten Pools von Adressen möglich. Durch die Rückwärtskompatibilität zum PDU-Format von BOOTP ist die Verwendung existierender BOOTP-Relay-Agents in Subnetzen ohne DHCP-Server gewahrt.

Beim Start des Systems schickt der Client ein DHCPDISCOVER-Paket in Form eines Broadcasts an 255.255.255.255 (Phase 1). Anhand der Identifikation des Client im Paket können sich einige (oder ein einzelner) DHCP-Server entscheiden, dem Client die gewünschte IP-Adresse sowie andere Konfigurationsinformation in Form eines DHCPOFFER-Pakets zuzuteilen. (Vor der Vergabe können und sollten die Server die Konfliktfreiheit bzgl. der Adresse mittels ICMP-Ping oder ARP prüfen.) Der Client kann sich in Phase 2 aus den Antworten eine für ihn geeignete aussuchen und bestätigt dies gegenüber dem Server durch ein DHCPREQUEST-Paket (Phase 3). Entscheidungsparameter können z.B. die Leasedauer (t_l) oder die Menge der angebotenen Konfigurationsinformation Bei korrekter Information im DHCPREQUEST bestätigt der Server die Lease durch ein DHCPACK-Paket, womit die Konfiguration abgeschlossen ist Bevor die IP-Adresse verwendet wird, sollte der Client ihre Einzigartigkeit durch ein Gratuitious ARP prüfen. Sollte der Client die angebotene Adresse ablehnen wollen, teilt er dies durch DHCPDECLINE-Paket dem Server und beginnt nach einer kurzen Wartefrist erneut mit Phase 1. Sobald der Client die Bestätigung durch DHCPACK erhalten hat, ist er für die Ü berwachung der Lease-Dauer selbst verantwortlich. Insbesondere kennt das Protokoll auch keine Methode, einem Client die Lease zu entziehen. Vor Ablauf der Lease-Dauer (meist nach der Hälfte der Zeit = 0,5 * t_l) sollte der Client durch einen erneuten Durchgang durch Phase 3 versuchen, die Lease vom selben DHCP-Server verlängert zu bekommen. Gelingt ihm das nicht, kann er vor endgültigem Ablauf der Lease-Dauer (meist nach ca. 0,8 * t_l) die Phase 1 nochmals durchlaufen, um eine Verlängerung bzw. Neuausstellung der Lease (eventuell von einem anderen Server) zu erhalten. Die vorzeitige Aufgabe einer Lease sollte der Client dem Server durch ein DHCPRELEASE mitteilen, um den Pool freier Adressen möglichst groß und den Vergabestand im Server möglichst akkurat zu halten. Alle Zustandsübergange im Client sind in folgender Abbildung zusammengefaßt. Die Komplexität hat in der Vergangenheit zu einigen Fehlimplementierungen mancher Client-Software geführt, die jedoch aufgrund der großen "Toleranz" im Protokoll meist keine kritischen Auswirkungen hatten.

Es darf natürlich nicht jeder beliebige Rechner Zugang zum LAN erhalten. Deshalb kann der DHCP-Server auch eingeschränkt werden - bis hin zu einer Liste von "erlaubten" MAC-Adressen. Man kann auch eine gemischte Versorgung der Rechner im Netz vorsehen, teils mit festen IP-Adresse (z. B. Server mit "Außenwirkung"), teils mit dynamisch zugewiesenen Adressen.

Remote-Zugang mit RADIUS

Ein spezieller Terminalserver-Modus gestattet es, sich mit einem normalen Terminalprogramm (z.B. Hyperterminal, Kermit, usw.) auf dem Access-Server anzumelden und von dort aus Telnetverbindungen aufzubauen. IP-Adressen werden normalerweise aus einem IP-Adresspool vergeben. Oft werden auch "virtuelle Verbindungen" unterstützt. Diese erlauben den physikalischen Abbau von Verbindungen, wenn gerade keine Daten übertragen werden, ohne daß die logische Verbindung verloren geht. Die Verbindung wird automatisch mit den gleichen Parametern wie vorher wieder aufgebaut, wenn Daten wieder übertragen werden müssen.

Für die standardisierte Authentifizierung am Modem- und Internetzugang setzt sich zunehmend das RADIUS-Protokoll (Remote Authentication and Dial-In User Service) durch. Seine Client-Proxy-Server-Architektur erlaubt die flexible Positionierung an Netzzugangspunkten und wird von fast allen Herstellern von Modemservern unterstützt. In Kombination mit DHCP und PPP ist die Aufgabe der Konfiguration der anwählenden Endsysteme in automatisierter Weise gelöst. Der Radius-Server ist ein zentraler Authentifizierungs-Server, an den sich alle RA-Server wenden. Auf diese Weise lassen sich unabhängig von der Netz-Infrastruktur alle Remote-User zentral verwalten und Benutzerprofile mit Zugangsrestriktionen definieren, aber auch zusätzliche Sicherheitsverfahren vorsehen. Beispielsweise kann festgelegt werden, dass der Nutzer nur nach einem Rückruf durch den Einwahlknoten an eine zuvor vereinbarte Rufnummer Zugriff auf das Unternehmensnetzwerk bekommen darf. Diese Informationen übergibt der Radius-Server an den RA-Server, der das weitere Login entsprechend koordiniert. Der Vorteil dieses Verfahrens liegt in den einmalig generierten Zugangsdaten der Nutzer, die auch in verteilten Netzwerken jederzeit aktuell verfügbar sind und mit einfachen administrativen Eingriffen an zentraler Stelle definiert und verändert werden können. Darüber hinaus ist die innerbetriebliche Abrechnung der Nutzung des Systems durch ein entsprechendes Accounting möglich.

Das Radius-Protokoll setzt auf UDP auf. Die Struktur eines Radius-Pakets ist ausgesprochen einfach. Es besteht aus fünf grundlegenden Elementen: einem Radius-Code, einem Identifier, einer Angabe zur Paketlänge, einem Authenticator und gegebenenfalls aus einer Reihe von Attributen. Der Radius-Code beschreibt die Aufgabe des Datenpakets.

Aufbau des Radius-Pakets

Die Codes 1, 2 und 3 verwalten den reinen Access vom Request bis zur Bestätigung oder Abweisung. Die Codes 4 und 5 dienen dem Accounting. Der Identifier ist acht Bit lang und dient der Zuordnung von Anfragen und Antworten. Das sicherheitstechnisch wichtigste Feld eines Radius-Rahmens ist der Authenticator, der eine Länge von 16 Oktetts beziehungsweise vier 32-Bit-Worten hat. Dabei wird zwischen dem Request Authenticator und dem Response Authenticator unterschieden. Inhalt des Request Authenticators ist eine Zufallszahl, die das gesamte Feld ausfüllt. Die Länge dieser Zufallszahl gewährleistet mit einer sehr hohen Wahrscheinlichkeit die Einmaligkeit dieses Wertes. Damit bietet das System einen gewissen Schutz vor Hackerattacken. Mit dem Versand des Request Authenticators werden die Zugangsdaten des Nutzers, der sich im gesicherten Netzwerk anmelden möchte, als Attribute übergeben. Der Radius-Server wird diese Anfrage entweder mit einer Access-Accept-, Access-Reject- oder Access-Challenge-Nachricht beantworten, die ihrerseits mit einem 16 Oktett langen Response Authenticator versehen ist. Dieser ist ein MD5-Hash-Fingerprint setzt sich zusammen aus dem empfangenen Radius-Paket einschließlich der Attribute sowie den geheimen Zugangsdaten, die auf dem Server abgelegt sind, zusammensetzt. Die Attribute eines Radius-Pakets beinhalten alle wichtigen Informationen, die zwischen dem RAS und dem Radius-Server ausgetauscht werden müssen.

Attribute sind sehr einfach aufgebaut

Attribute werden in einer Liste mit variabler Länge im Anschluss an den Authenticator übertragen. In den Attributen können natürlich Nutzernamen und Passwörter, aber auch IP-Adresse, Service-Typen, Status-Meldungen, Filter-IDs und - wichtig beim CHAP - ein entsprechender Challenge-Wert übergeben werden. Attribute werden in Datensätzen variabler Länge übertragen, die jeweils aus drei Feldern bestehen. Das erste aus acht Bit bestehende Feld benennt die Art des Attributes. Da nicht nur die Liste aller Attribute, sondern auch jeder einzelne Datensatz selbst in der Länge variabel ist, gibt das zweite Oktett die Länge des Attributes an. Erst ab dem dritten Oktett werden die eigentlichen Informationen übertragen.

Im einfachsten Fall wird ein Radius-Request mit einer Legitimierung des Nutzers oder dessen Abweisung beantwortet. Dazu folgt auf dem Access-Request eine Access-Accept- oder eine Access-Reject-Nachricht vom Radius-Server. Die Art der Antwort wird mit dem Radius-Code angezeigt. Das Verfahren harmonisiert mit PAP und CHAP.

SMTP - Simple Mail Transfer Protocol

 

Kommando	Argument	Beschreibung
HELO	Systemname	Beginn, Name des sendenden Systems
MAIL	From: Absenderadresse	Beginn der Übermittlung
RCPT	To: Empfängeradresse	Adressat der E-Mail
DATA		Brieftext, Ende durch eine Zeile mit "."
HELP	Topic	Hilfestellung
VRFY	Mailadresse	Mailadresse verifizieren
EXPN	Mailadresse	Mailadresse expandieren (z. B. Liste)
RSET		Senden abbrechen, Zurücksetzen
NOOP		nichts tun
QUIT		Verbindung beenden

Die Verbindung eines MTA zu einem anderen läßt sich nachstellen:

	telnet lx-lbs.e-technik.fh-muenchen.de smtp
	Trying 129.187.106.196...
	Connected to lx-lbs.e-technik.fh-muenchen.de.
	Escape character is '^]'.
	220 lx-lbs.e-technik.fh-muenchen.de Smail3.1.28.1 #1 ready at Sun, 25 Feb 96 23:15 MET
	helo www.netzmafia.de
	250 lx-lbs.e-technik.fh-muenchen.de Hello www.netzmafia.de
	mail from: paulsen@fitug.de
	250 
 ... Sender Okay
	rcpt to: holm@lx-lbs.e-technik.fh-muenchen.de
	250 
 ... Recipient Okay
	data
	354 Enter mail, end with "." on a line by itself
	Hallo Holm,
	
	zu Deiner Frage bezeglich der Reinigung von Morgensternen
	wollte ich Dir nur den Tip geben, dazu reine Kernseife zu
	verwenden.
	Damit ist die Drecksarbeit im Handumdrehen erledigt.
	
	Beste Gruesse, Paulsen
	.
	250 Mail accepted
	quit
	221 lx-lbs.e-technik.fh-muenchen.de closing connection
	Connection closed by foreign host.

Beim Verbindungsaufbau meldet sich der lokale MTA mit einer "Begrüßungszeile". Der lokale empfangende MTA wird mit "HELO" angesprochen und als sendender MTA der des Systems www.netzmafia.de angegeben. Der lokale MTA antwortet mit einem Zahlencode, der dem Sender-MTA signalisiert, daß seine geforderte Aktion in Ordnung geht. Die Klarschrift nach dem Zahlencode dient nur der besseren Lesbarkeit für den Menschen (z. B. für den, der Fehler suchen muß). Auf "MAIL FROM:" folgt die Adresse des Absenders, und auf "RCPT TO:" die des Empfängers. Auf das Schlüsselwort "DATA" folgt schließlich der ganze Brief, also sowohl die Kopfzeilen, als auch der Text. Der Empfänger-MTA wird solange Text erwarten, bis ihm der Sender-MTA über eine Zeile, die nur einen Punkt enthält, signalisiert, daß der Brief zu Ende ist. Nach der letzten Bestätigung des Empfänger-MTAs könnte der Sender den nächsten Brief übermitteln, wiederum beginnend mit "MAIL FROM:". Nach dem Empfang des Briefes kopiert der lokale MTA den Brief in die Postfach-Datei des Empfängers.

Der RFC 821 legte noch einige weitere Schlüsselworte fest, z. B. "EXPN" für expand, welches eine Unterstützung von Mailing-Listen erlaubt, oder "VRFY" für verify, mittels dessen eine Bestätigung der Empfänger-Adresse gefordert werden kann. Eine ganze Reihe von RFCs haben den Standard für SMTP erweitert. Die erweiterte Version heißt nun offiziell ESMTP (für Extended SMTP). Hinzugekommen sind beispielsweise Schlüsselworte für die Unterstützung von 8bit-Briefen (z. B. solche mit Umlauten), und die Möglichkeit eine maximale Größe für Briefe, die empfangen werden, festzulegen.

Auf Arbeitsplatzrechnern, die normalerweise nicht ständig eingeschaltet sind, erfordert E-Mail spezielle Betriebsweisen. Falls der Rechner in ein lokales Netz integriert ist, bietet sich eine Lösung über den Netzwerkserver oder einen speziellen Mail-Server an. Es gibt auch die Möglichkeit, direkt vom PC-Kompatiblen oder Macintosh auf eine Unix-Mailbox zuzugreifen. Voraussetzung dafür ist, daß der Arbeitsplatzrechner direkt mit TCP/IP am Ethernet angeschlossen ist oder über eine Modem-Verbindung per PPP-Protokoll angebunden ist. Die Mailer sind lokale Programme am PC oder Mac. Der Vorteil ist, daß man in der PC-Umgebung bleibt, und Dateien direkt aus dem PC-Directory-System versandt werden können. Die Mailbox des Benutzers liegt dabei selbst auf einem Mail-Server (Postfach). Der Zugriff vom PC auf das Mailsystem des Servers wird über den Client/Server-Mechanismus realisiert. Protokolle, die dieses erlaubt, sind POP ('Post Office Protocol') und IMAP ('Internet Message Access Protocol').

POP

• Die für den Empfänger bestimmten E-Mails landen beim Provider im Spool-Verzeichnis und müssen dort vom Empfänger abgeholt werden.
• Der Provider stellt einen POP-Server zur Verfügung, welcher die Schnittstelle des POP-Clients auf dem Empfänger-Rechner darstellt. Der lokale POP-Client kommuniziert mit dem POP-Server beim Provider. "Uber ihn werden die vorhandenen E-Mails angeboten.

Eine Kommunikation zwischen dem POP-Client und dem POP-Server beim Provider kann schematisch beispielsweise so aussehen :

Client: Hast Du neue E-Mails für mich?
Server: Ja, insgesamt fünf Stück!
Client: Liste mir die Absender auf!
Server: Meier, Mueller, Huber, Schulze
Client: Zeige die E-Mails an!
Server: ((Zeigt E-Mails an))
Client: ((Speichert E-Mails ab))
Client: Lösche alle angezeigten E-Mails
Server: ((Löscht alle angezeigten E-Mails))

Wenn ein Client über POP3 Nachrichten abrufen möchte, baut er eine TCP-Verbindung über Port 110 auf. Ist die Verbindung zustande gekommen, sendet der Server eine Begrüßungsmeldung. Die weitere Kommunikation zwischen beiden Rechnern erfolgt über Kommandos, die aus drei oder vier Zeichen langen Wörtern (mit einem oder mehreren Argumenten mit bis zu je 40 Zeichen) bestehen. Antworten enthalten einen Status-Indikator und ein Statuswort sowie optionale Informationen. Es gibt zwei Status-Indikatoren:

• Positiv: +OK
• Negativ: -ERR

Viele POP3-Server haben zusätzlich einen Inaktivitäts-Timer. Laut Spezifikation muß dieser auf mindestens zehn Minuten eingestellt sein. Jedes Kommando des Clients setzt den Timer zurück. Ist der Timer abgelaufen, wird die TCP-Verbindung beendet, ohne in den "Update State" zu wechseln - eventuelle Änderungen werden auf dem Server nicht gespeichert.

Nachdem der POP3-Client eine Verbindung zum Server aufgebaut hat, sendet dieser eine einzeilige Begrüßungsmeldung beliebigenInhalts, z. B.:

Server: +OK POPEL-3 server ready

 

Kommandos im "Authorization State"
Kommando	Argument	Beschreibung
USER	Name	Das Argument identifiziert eine Mailbox.
PASS	String	Der String enthält ein Mailbox-spezifisches Passwort.
QUIT	-	Beendet die Verbindung.

Die Kombination aus den Kommandos USER und PASS ist am gebräuchlichsten. Dabei werden die jeweiligen Parameter im Klartext an den Server gesendet. Ein Beispiel: Der Username für das Postfach soll "plate", das Passwort "XYZ1230" heißen. In diesem Fall wird folgender Authentifizierungsdialog ablaufen:

Client: USER plate
Server: +OK name is a valid mailbox 
Client: PASS YXZ1230
Server: +OK platesÝs maildrop has 9 messages (1600 octets)

Client: USER plato
Server: -ERR sorry, no mailbox for plato here

Client: USER plate
Server: +OK name is a valid mailbox 
Client: PASS tralala
Server: -ERR invalid password

Hat sich der Client beim Server identifiziert, wechselt die Verbindung in den "Transaction State". Dem Client stehen nun eine Reihe von Kommandos zur Behandlung der Mails zur Verfügung:

 

Kommandos im "Transaction State"
Kommando	Argument	Beschreibung
STAT	-	Liefert die Anzahl der gespeicherten Mails und die Größe der Mailbox zurück (in Byte).
LIST	Nummer	Liefert die Nummer und Größe (in Bytes) aller Mails zurück. Wird als Argument eine Mail-Nummer angegeben, wird nur die Größe dieser Mail ausgegeben.
RETR	Nummer	Gibt die Mail mit der als Argument übergebenen Nummer aus.
DELE	Nummer	Löscht die Mail mit der übergebenen Nummer.
NOOP	-	Bewirkt die Antwort "+OK". Dient zur Aufrechterhaltung der Verbindung, ohne daß ein Time-Out auftritt.
RSET	-	Setzt die aktive Verbindung zurück. Noch nicht ausgeführte Änderungen werden verworfen.
QUIT	-	Beendet die Verbindung und führt alle gespeicherten Änderungen aus.

Der Server führt das Kommando DELE nicht unmittelbar aus. Die entsprechenden E-Mails werden als gelöscht marlkiert und erst bei Beenden der Verbindung endgültig vom Server gelöscht. Hat man eine Nachricht zum Löschen gekennzeichnet, möchte dies jedoch rückgängig machen, führt man das Kommando RSET aus. Der Server verwirft alle noch nicht ausgeführten Operationen.
Sendet der Client das QUIT-Kommando, wechselt die Verbindung in den "Update State". Der Server trennt die TCP-Verbindung und führt alle gespeicherten Änderungen aus.

Neben den hier vorgestellten, für eine minimale Implementation ausreichenden Kommandos gibt es noch weitere, die von den meisten Clients und Servern unterstützt werden. Details hierzu finden Sie in RFC1725.

Im folgenden Beispiel sehen Sie den Ablauf einer POP3-Verbindung. Der Client identifiziert sich gegenüber dem Server und ruft eine Liste der gespeicherten E-Mails ab. Danach werden die Nachrichten einzeln heruntergeladen, auf dem Server zum Löschen gekennzeichnet, und die Verbindung wird beendet.

Server: +OK POP3 server ready
Client: user plate
Server: +OK
Client: pass xyz1230
Server: +OK
Client: LIST
Server: +OK 3 messages (520 octets)
Server: 1 120
Server: 2 190
Server: 3 210
Server: .
Client: RETR 1
Server: +OK 120 octets
Server: <... sendet Nachricht 1>
Server: .
Client: DELE 1
Server: +OK message 1 deleted
Client: RETR 2
Server: +OK 190 octets
Server: <... sendet Nachricht 2>
Server: .
Client: DELE 2
Server: +OK message 2 deleted
Client: RETR 4
Server: -ERR no such message
Client: QUIT
Server: +OK

IMAP: Internet Message Access Protocol

Die Antwort eines Servers kennzeichnet den Erfolg oder Fehler eines Kommandos:

• OK (Kommando erfolgreich ausgeführt),
• NO (Fehler beim Ausführen) oder
• BAD (Protokoll-Fehler: Kommando unbekannt oder Syntax-Fehler).

• Non-Authenticated State: Unmittelbar nach dem Aufbau der Verbindung. Der User muß sich gegenüber dem Server identifizieren.
• Authenticated State: Der User hat sich erfolgreich identifiziert und muß nun eine Mailbox auswählen.
• Selected State: Eine Mailbox wurde ausgewählt. Mailbox und Mails lassen sich bearbeiten.
• Logout State: Die Verbindung wird beendet; der Server führt noch anstehende Tätigkeiten aus.

Der "Non-Authenticated State" stellt mehrere Möglichkeiten zur Identifizierung des Anwenders zur Verfügung. Es gibt in diesem Zusatand folgende Kommandos:

 

Kommandos im "Non-Authenticated State"
Kommando	Argument	Beschreibung
AUTHENTICATE	Authentifizierungs-Mechanismus	Das Kommando bestimmt den Authentifizierungs-Mechanismus, zum Beispiel "Kerberos" oder "S/Key". Details zu den Authentifizierungs-Mechanismen finden Sie in RFC1731.
LOGIN	Name/Passwort	Identifiziert den Anwender über Benutzername und Passwort.

Beispiel für eine Authentifizierung mit dem LOGIN-Kommando:

Client: X001 LOGIN PLATE XYZ1230
Server: X001 OK LOGIN completed

Im "Authenticated State" hat sich der User authentifiziert und muß nun eine Mailbox auswählen, welche in dieser Sitzung bearbeitet werden soll. Dazu stehen unter anderem folgende Kommandos zur Verfügung:

 

Wichtige Kommandos im "Authenticated State"
Kommando	Argument	Beschreibung
SELECT	Mailbox-Name	Wählt eine Mailbox zur weiteren Bearbeitung aus. Als erfolgreiche Antwort sendet der Client Informationen zur gewählten Mailbox, wie beispielweise die Anzahl der gespeicherten Nachrichten.
EXAMINE	Mailbox-Name	Identisch mit dem Kommando SELECT. Jedoch wird die Mailbox als "read-only" ausgewählt, es sind keine dauerhaften Änderungen möglich.
CREATE	Mailbox-Name	Erstellt eine Mailbox mit dem als Argument übergebenen Namen.
DELETE	Mailbox-Name	Löscht die als Argument übergebene Mailbox.
RENAME	Bestehender Mailbox-Name / Neuer Mailbox-Name	Ändert den Namen einer Mailbox.

Beispiel: Löschen einer Mailbox:

Client: X324 DELETE TRALALA
Server: X234 OK DELETE completed

Im "Selected State" gibt es viele Kommandos zum Bearbeiten einer Mailbox:

 

Wichtige Kommandos im "Selected State"
Kommando	Argument	Beschreibung
CLOSE	-	Entfernt alle zum Löschen gekennzeichneten Mails und setzt die Verbindung in den Authenticated State zurück.
EXPUNGE	-	Entfernt alle zum Löschen gekennzeichneten Mails, die Verbindung bleibt im Selected State.
SEARCH	ein oder mehrere Suchkriterien	Erlaubt die Suche nach bestimmten Nachrichten in der aktuellen Mailbox. Das Kommando unterstützt logische Verknüpfungen.
FETCH	Gewünschte Daten einer Nachricht	Bewirkt das Senden von Daten einer Nachricht vom Server zum Client.

Beispiel: Suchen einer Nachricht. Ergebnis sind die Nummern der entsprechenden Mails:

Client: X246 SEARCH SINCE 1-NOV-2001 FROM "ADAM"
Server: * SEARCH 2 84 882
Server: X246 OK SEARCH completed

Beendet der Client mit dem Kommando LOGOUT die Verbindung, wechselt der Server in den "Update State" und führt noch anstehende Arbeiten aus.
Es gibt eine Reihe weiterer Befehle im "Authenticated State" und "Selected State", die in RFC2060 nachzulesen sind.

Im abschließenden Beispiel sehen Sie den Ablauf einer IMAP4-Verbindung. Der Client identifiziert sich gegenüber dem Server, wählt eine Mailbox aus und lädt den Header einer Nachricht herunter.

Server: * OK IMAP4 Service Ready
Client: X001 login plate XYZ1230
Server: X001 OK LOGIN completed
Client: X002 select inbox
Server: * 12 EXISTS
Server: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
Server: * 2 RECENT
Server: * OK [UNSEEN 11] Message 11 is first new message
Server: * OK [UIDVALIDITY 2905753845] is first new message
Server: X002 OK [READ-WRITE] SELECT completed
Client: X003 fetch 9 rfc822.header
Server: * 9 FETCH (RFC822.HEADER {346}
Server: Date: mon, 11 Mar 2002 09:23:25 -0100 (MET)
Server: From: plate <plate@netzmafia.de>
Server: Subject: Schulung Netzwerke am Donnerstag
Server: To:  <schulung@ee.fhm.edu>
Server: Message-Id: <20020311104452.GH1474.plate@netzmafia.de>
Server: Mime-Version: 1.0
Server: Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Server: )
Server: X003 OK FETCH completed
Client: X004 LOGOUT
Server: * BYE IMAP4 server terminating connection
Server: X004 OK LOGOUT completed

Nachdem der Mail-Client über TCP eine Verbindung zum SMTP-Server aufgebaut hat, wartet er auf einen Begrüßungstext des Servers. Im nächsten Schritt identifiziert sich der Client mit dem Kommando LOGIN, als Argument übergibt er den Benutzernamen und das Passwort. Nach dem Auswählen der Mailbox sendet der Server einige Informationen, z. B. die Anzahl der ungelesenen Nachrichten. Mit dem Kommando FETCH fordert der Client den Header der Nachricht 9 an. LOGOUT beendet die Verbindung.

Bei Inbetriebnahme eines POP- bzw. IMAP-Clients (Outlook, Pegasus Mail, Netscape) muß dieser zunächst konfiguriert werden. Wichtige Angaben sind:

• Domainname des POP- bzw. IMAP-Servers, d.h. Systems, auf dem die eigentliche Mailbox liegt.
• Benutzernummer auf diesem System
• Paßwort für diese Benutzernummer
• für den Versand: Angabe des SMTP-Mail-Relayhosts

POP/IMAP dient nur zum Abholen der Post vom Mail-Server. Der Versand von E-Mail vom PC oder Mac aus geschieht ganz normal mit SMTP (Simple Mail Transfer Protocol).

FTP

• Benutzerspezifisches FTP
• Anonymous-FTP

Der Kommandoaufruf des FTP-Kommandos lautet

ftp [ -v ] [ -d ] [ -i ] [ -n ] [ -g ] [ host ]

Wird beim Programmaufruf der gewünschte Kommunikationspartner (host) mit angegeben, so wird sofort versucht, eine Verbindung zu diesem Rechensystem aufzubauen. Ist der Versuch erfolglos, so wird in den Kommandomodus umgeschaltet. Der Prompt "ftp>" erscheint immer auf dem Bildschirm, wenn ftp-Kommandos eingegeben werden können. ftp verfügt über einen help-Mechanismus, über den sämtliche auf dem jeweiligen System verfügbare Kommandos mit Kurzerklärungen abfragbar sind.
Nachfolgend werden wesentliche Kommandos nach Funktionalität gruppiert vorgestellt. Kommandos können soweit verkürzt eingegeben werden, als sie noch eindeutig erkennbar sind. Enthalten Kommandoargumente "Blanks", so sind die Argumente beidseitig mit Hochkommas eingeschlossen einzugeben. Nicht alle ftp-Implementierungen unterstützen alle ftp-Kommandos.

• help [ kommando ]
  zeigt kurze Informationen zu dem angegebenen Kommando. Wird das Kommando weggelassen, zeigt dieser Aufruf eine Liste der zulässigen Kommandos.
• open host
  Öffene einer Verbindung zu einem fernen Host. Je nach angewähltem System werden Benutzerkennung und Passwort abgefragt.
• user user-name [ password ]
  Eingabe von Benutzerkennung und Passwort.
• !
  Aufruf einer (eingeschränkten) Shell auf dem lokalen System. Für Dateiübertragung relevante Kommandos wie mkdir, mv, cp, etc sind absetzbar. Verlassen wird diese Shell mit "exit".
• lcd [directory ]
  Wahl des lokalen Directories für die Dateiübertragung.
• pwd
  Anzeige des aktuellen Directories auf dem entfernten System.
• cd remote-directory
  Wahl des aktuellen Directories auf dem entfernten System.
• cdup
  Wechsel in das nächsthöhere Directory auf dem entfernten System.
• dir [ remote-directory [ local-file ] ]
  ls [ remote-directory [ local-file ] ]
  Ohne Optionen erfolgt eine Anzeige der Einträge des entfernten aktuellen Directories. Dabei liefert dir ausführliche und ls eine knappe Information bezüglich des Directory-Inhalts.
  Bei Angabe des remote-directory erfolgt die Anzeige der Einträge des entfernten Directories. Wird local-file angegeben, erfolgt eine Umlenkung der Directory-Anzeige in die Datei local-file auf dem lokalen System.
• mdir remote-files [ local-file ]
  mls remote-files [ local-file ]
  Anzeige von Dateien aus dem entfernten aktuellen Directory und Abspeicherung in eine lokale Datei.
• mkdir directory-name
  Einrichten eines neuen Directories directory-name auf dem entfernten System.
• rmdir directory-name
  löscht das Directory directory-name auf dem entfernten System.
• rename [ from ] [ to ]
  Umbenennen einer Datei auf dem entfernten System von from nach to.
• delete remote-file
  Löschen der Datei remote-file auf dem entfernten System.
• mdelete remote-files
  Löschen mehrerer Dateien remote-files auf dem entfernten System.
• put local-file [ remote-file ]
  send local-file [ remote-file ]
  Dateiübertragung der Datei local-file vom lokalen zum entfernten System. Wird remote-file nicht angegeben, so wird auch auf dem Zielsystem der Dateiname local-file verwendet.
• append local-file [ remote-file ]
  überträgt die Datei local-file vom lokalen System an das entfernte System und hängt diese am Ende der Datei remote-file an. Wurde remote-file nicht angegeben, wird die Datei ans Ende der Datei local-file auf dem entfernten System angehängt.
• mput local-files
  Dateiübertragung einer Dateigruppe namensgleich vom lokalen zum entfernten System.
• get remote-file [ local-file ]
  recv remote-file [ local-file ]
  Dateiübertragung einer Datei remote-file vom entfernten System zum lokalen System. Wird local-file nicht mitangegeben, so erhält die Datei auch auf dem lokalen System den Dateiname remote-file.
• mget remote-files
  Dateiübertragung einer Dateigruppe namensgleich vom entfernten zum lokalen System.
• ascii
  type ascii
  Die Dateiübertragung findet im ASCII-Code statt. Gegebenfalls werden Bei Binärdateien Zeichen verändert (z. B. die Zeilenendedarstellung ans Zielsystem angepaßt) oder Zeichen verfälscht.
• binary
  type image
  type binary
  Die Dateiübertragung findet transparent statt.
• case
  Mit diesem Schalter läßt sich einstellen, ob Dateinamen beim Empfangen (get, recv, mget) von Großbuchstaben nach Kleinbuchstaben übersetzt werden sollen.
• glob
  Mit diesem Schalter läßt sich einstellen, ob bei den Kommandos mdelete, mget und mput bei Dateinamen, die Metazeichen (*?[]~{}) enthalten, diese Metazeichen übertragen werden oder nicht. ("off" = keine Metazeichenbehandlung).
• ntrans [ inchars [ outchars ] ]
  Definition und Aktivierung einer Übersetzungstabelle für Dateinamen, wenn beim Dateiübertragungsauftrag (Senden und Empfangen) keine Zieldateinamen angegeben werden. Zeichen eines Dateinamens, die in inchars zu finden sind, werden durch das positionsgleiche Zeichen in outchars übersetzt. Ist inchars länger als outchars, so werden die korrespondenzlosen Zeichen von inchars aus dem Zieldateinamen entfernt.
• prompt
  Mit diesem Zeichen wird bei Mehrdateienübertragung gesteuert, ob jede zu übertragende Datei extra quittiert werden muß oder nicht.
• verbose
  Wenn der "verbose"-Modus eingeschaltet ist, erhält man für jede übertragene Datei den Dateinamen auf dem lokalen und entfernten Rechner, sowie die Datenmenge und die dafür benötigte Übertragungszeit angezeigt.
• bell
  Dieser Schalter bewirkt, daß je nach Stellung am Ende jedes Dateiübertragungsauftrages ein akustisches Signal ertönt oder nicht.
• status
  Anzeige der aktuellen logischen Schalterstellungen sowie des Verbindungszustandes.
• close
  disconnect
  Beendigung einer aktiven Verbindung.
• quit
  Beendigung des Programmes ftp.
• bye
  Beendigung einer aktiven Sitzung und des Programmes ftp.

Die optionalen Parameter beim ftp-Kommando setzen logische Schalter für den ftp-Programmlauf. Im Kommandomodus sind die Einstellungen jederzeit wieder änderbar.

• -v verbose-Schalter einschalten.
• -d debug-Schalter einschalten.
• -i interactive-Modus für Mehrdateiübertragung einschalten.
• -n verhindert, daß FTP zum Beginn der Sitzung einen Login-Versuch unternimmt.
• -g glob-Schalter einschalten.

Die Datei-Übertragung wird durch die Terminal "interrupt"-Taste (üblicherweise Ctrl-C) abgebrochen, was einen sofortigen Abbruch zur Folge haben soll. Nicht alle Kommunikationspartner verstehen die Abbruchaufforderung, wodurch dennoch die gesamte Datei übertragen ausgeführt wird.

Dateinamen, die als Argumente von FTP-Kommandos Verwendung finden, werden wie folgt bearbeitet: Ist "file globbing" eingeschaltet, werden bei den Kommandos mget, mput und mdelete die Namen lokaler Dateien folgendermaß behandelt:

• Der * steht für eine beliebige Anzahl (auch Null) von Zeichen.
• Das ?steht für ein einziges beliebiges Zeichen.
• Wird im Dateinamen eine Zeichenfolge angetroffen, die zwischen eckigen Klammern oder zwischen geschweiften Klammern steht, so sind alle Dateinamen zutreffend, die an dieser Stelle ein einziges beliebiges Zeichen aus der Zeichenfolge innerhalb der Klammern enthalten.
• Steht die Zeichenfolge ~/ (Tilde, Schrägstrich) am Beginn des Dateinamens, so wird sie durch den Home-Directory-Pfad ersetzt. Das Zeichen ~, dem eine Benutzerkennung folgt, wird durch den Home-Directory-Pfad dieser Benutzerkennung ersetzt.

Kommandos und Protokoll-Anweisungen:

 

ftp-Client	FTP-Protokoll	Aufgabe
login	USER username PASS password	anmelden
help help command	HELP HELP command	Hilfe
	SYST	Server-Identifikation
status	STAT	Transfer-Status
	STAT path	wie LIST, über control-Verbindung
dir path	LIST path	Kataloginhalt zeigen, ausführlich
ls path	NLST path	Dateinamen zeigen
delete path	DELE path	Datei löschen
rename from to	RNFR from-path RNTO to-path	Datei umbenennen
pwd	PWD	Arbeitskatalog zeigen
cd path	CWD path	Katalog wechseln
mkdir path	MKD path	Katalog erzeugen
rmdir path	RMD path	Katalog löschen
ascii	TYPE A N	Textübertragung (Voreinstellung)
binary	TYPE I	Datenübertragung
	PORT h,h,h,h,p,p	Port des Klienten für data-Verbindung
get remote-path	RETR path	Datei zum Klienten übertragen
put local-path	STOR path	Datei zum Server übertragen
append local-path	APPE path	an Datei auf Server anfügen
interrupt	ABOR	_bertragung abbrechen
quit	QUIT	Verbindung beenden

Beispiel

ftp multimedia.ee.fhm.edu
Verbindung mit multimedia.ee.fhm.edu.
220 ProFTPD 1.2.2rc2 Server [multimedia.e-technik.fh-muenchen.de]
Benutzer (multimedia.ee.fhm.edu:(none)): plate
331 Password required for plate.
Kennwort:
230 User plate logged in.
Ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
tmp
Mail
bin
226 Transfer complete.
Ftp: 36 Bytes empfangen in 0.00Sekunden 36000.00KB/Sek.
Ftp> cd tmp
250 CWD command successful.
Ftp> lcd E:\www-netzmafia\skripten\perl
Lokales Verzeichnis jetzt E:\www-netzmafia\skripten\perl.
Ftp> cd /opt/www/skripten/perl
250 CWD command successful.
Ftp> put perl3.html
200 PORT command successful.
150 Opening ASCII mode data connection for perl3.html.
226 Transfer complete.
Ftp: 77604 Bytes gesendet in 9.17Sekunden 8.46KB/Sek.
Ftp> put perl4.html
200 PORT command successful.
150 Opening ASCII mode data connection for perl4.html.
226 Transfer complete.
Ftp: 30930 Bytes gesendet in 3.24Sekunden 9.55KB/Sek.
Ftp> quit

HTTP - Hypertext Transfer Protocol

Heutige Informationssysteme benötigen weit mehr Funktionen als das einfache Senden und Empfangen von Nachrichten. Die Entwicklung von HTTP/1.0 ist nicht abgeschlossen. Es bietet die Möglichkeit, weitere Funktionalität zu entwickeln. Die Adressierung von Ressourcen erfolgt dabei mittels URls, die zum einen Orte (URL) oder Bezeichner (URN) sein können. Diese zeigen gleichzeitig den gewünschten Übertragungsmechanismus an. Nachrichten werden in der gleichen Form übertragen, wie sie auch bei normalem Mail-Transport verwandt werden. Dabei kommt oft MIME zum Einsatz. HTTP/1.0 ist auch für den Zugriff auf Server mit anderen Protokollen geeignet. So ist es WWW-Clients möglich, mit Servern und Gateways per SMTP, NNTP, FTP, Gopher und WAIS zu kommunizieren.

Hauptfunktionen des HTTP

Direkt nach Beantwortung der Frage wird die Verbindung wieder abgebaut. So soll erreicht werden, daß die Leitungskapazitäten geschont werden. Derzeit finden HTTP-Verbindungen meist per TCP/IP statt. Das soll aber nicht heißen, daß HTTP nicht auch auf anderen Netzwerkprotokollen aufsetzen kann. Beide Seiten müssen auch dazu in der Lage sein, auf den vorzeitigen Abbruch der Kommunikation durch die andere Seite zu reagieren. Vorzeitiger Abbruch kann durch Aktionen von Benutzern, Programmfehler oder Überschreiten der Antwortzeiten ausgelöst werden. Durch den Abbruch der Verbindung durch eine der beiden Seiten wird der gesamte Vorgang abgebrochen.

Struktur der HTTP-Botschaften

Allgemeinfelder des Botschaftskopfes

Anfragen

     GET http://www.netzmafia.de/index.html

Dabei wird nur die Methode (GET) und die URL des Dokumentes angegeben. Es werden keine weiteren Felder erwartet und vom adressierten Server wird auch nur ein ganz einfacher Antwortkopf zurückgesendet. Es kann aber auch eine komplexere Anfrage erzeugt werden. Dabei muß die Zeile aus dem obigen Beispiel noch die Version des HTT-Protokolls angehängt werden. In einem Beispiel würde das folgendermaßen aussehen:

     GET http://www.netzmafia.de/index.html HTTP/1.0

Die Anfügung der HTTP-Version ist also der ganze Unterschied zwischen einer einfachen und einer komplexen HTTP-Anfrage. Der Unterschied zwischen einfacher und komplexer Anfrage wird aus Gründen der Kompatibilität gemacht. Ein Browser, der noch das alte HTTP/0.9 implementiert hat, wird nur eine einfache Anfrage losschicken können. Ein neuer Server muß dann eine Antwort, auch im Format des HTTP/0.9 zurücksenden.

Felder einer komplexen Anfrage

• Anfragezeile (Request-Line)
  Informationsanfrage wie oben geschildert. Die zugehörigen Methoden folgen im nächsten Abschnitt.
• Allgemeiner Kopf (General-Header)
  Im allgemeinen Kopf werden allgemeine Informationen über die Nachricht übermittelt.
• Anfragekopf (Request-Header)
  In diesen Feldern kann der Browser weitere Informationen über die Anfrage und über den Browser selbst absetzen. Diese Felder sind optional und müssen nicht erscheinen.
• Gegenstandskopf (Entity-Header)
  In diesem Feld werden Einträge übermittelt, welche den Inhalt der Nachricht näher beschreiben.
• Gegenstand der Nachricht (Entity-Body)
  Vor dem eigentlichen Inhalt muß definitionsgemäß eine Leerzeile stehen. Der Inhalt ist dann in dem Format codiert, das in den Gegenstandsfeldern definiert wurde (meist HTML).

Fragemethoden

• GET
  Diese Methode gibt an, daß alle Informationen, die mit der nachfolgenden URL beschrieben werden, zum rufenden Client geholt werden sollen. Zeigt die URL auf ein Programm (CGI-Script), dann soll dieses Programm gestartet werden und die produzierten Daten liefern. Handelt es sich bei dem referenzierten Datum um eine Datei, dann soll diese übertragen werden. Beispiel:

   

       GET http://www.netzmafia.de/index.html
  

   

• HEAD
  Diese Methode ist identisch zur Methode GET. Die Antworten unterscheiden sich nur darin, daß bei der Methode GET ein komplettes Dokument übertragen wird und bei HEAD nur die Meta-Informationen gesendet werden. Dies ist nützlich, um Links auszuprobieren oder um die Erreichbarkeit von Dokumenten zu testen. Bei Anwendung der Methode HEAD wird der Kopf des referenzierten HTML-Dokuments nach 'link' und 'meta' Elementen durchsucht.

   

• POST
  Diese Methode wird hauptsächlich für größere Datenmengen verwandt. Man stelle sich vor, ein HTML-Dokument enthält ein komplexes Formular. Per POST wird dem Server angezeigt, daß er auch die Daten im Körper der Botschaft bearbeiten soll.
  Verwendet, wird es hauptsächlich bei Datenblöcken, die zu einem verarbeitenden Programm übertragen werden. Die wirkliche Funktion, die durch POST auf dem adressierten Rechner angestoßen wird, wird durch die URL bestimmt. Meist, sind es CGI-Scripte, die den Inhalt der Nachricht verarbeiten.

   

• PUT
  Die mit der Methode PUT übertragenen Daten sollen unter der angegeben URL gespeichert werden. Das soll ermöglichen, daß WWW-Seiten auch ohne direkten Zugriff auf den anbietenden Rechner erstellt und angeboten werden können. Wird ein Dokument mit der Methode PUT übertragen, dann wird unter dieser Adresse ein Dokument mit dem übertragenen Inhalt angelegt. War die Aktion erfolgreich, wird die Meldung '200 created' zurückgegeben. Existiert unter dieser Adresse schon ein Dokument, dann wird dieses überschrieben. War auch diese Aktion erfolgreich, dann wird nur '200 OK' zurückgemeldet.
  Der Hauptunterschied zwischen POST und PUT besteht darin, daß bei POST die URL eine Adresse eines Programmes referenziert, das mit den Daten umgehen kann. Bei PUT hingegen wird die URL als neue Adresse des Dokumentes gesehen, das gerade übertragen wurde. Meist jedoch ist die Methode PUT ausgeschaltet, weil Server-Betreiber befürchten, daß die Sicherheit, des Systems dadurch nicht mehr gewährleistet ist.

   

• DELETE
  Mit dieser Methode kann der Inhalt einer URI gelöscht werden. Diese Methode ist neben der Methode PUT eine der gefährlichsten. Wenn Server nicht richtig konfiguriert wurden, dann kann es mitunter vorkommen, daß alle Welt die Berechtigung zum Löschen von Ressourcen hat.

   

• LINK
  Mit dieser Methode können eine oder mehrere Verbindungen zwischen verschiedenen Dokumenten erzeugt werden. Es werden dabei keine Dokumente erstellt, sondern nur schon bestehende miteinander verbunden.

   

• UNLINK
  entfernt Verbindungen zwischen verschieden Ressourcen. Dabei wird nur die Verbindung gelöscht. Die Dokumente existieren trotzdem weiter. Mit diesen Methoden kann man alle möglichen Ressourcen erreichen, welche die verschiedenen Server zur Verfügung stellen. Die folgenden Felder beschreiben nun die Fragen etwas genauer. Es kann zum Beispiel verhindert werden, daß ungewollt umfangreiche Bilder übermittelt werden, wenn dies nicht gewünscht wird.

Beispiel einer Konversation

 
plate@lx3-lbs:~ > telnet www.netzmafia.de 80
Trying 141.39.253.210...
Connected to www.netzmafia.de.
Escape character is '^]'.
GET /index.html HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 18 Sep 2000 13:59:58 GMT
Server: Apache/1.3.6 (Unix)  (SuSE/Linux)
Last-Modified: Tue, 29 Aug 2000 08:08:58 GMT
ETag: "134015-8e8-39ab6f9a"
Accept-Ranges: bytes
Content-Length: 2280
Connection: close
Content-Type: text/html

<HTML>
<HEAD>
<TITLE>Netzmafia</TITLE>
</HEAD>

<body bgcolor="#000000" text="#FFFFCC" link="#FFCC00" 
       alink="#FF0000" vlink="#FF9900">

       ...


</BODY>
</HTML>
Connection closed by foreign host.

mit freundlicher Unterstützung von Herrn Prof. Jürgen Plate