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. Der 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 bezü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übergänge 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.

Der Vorgang "Lease erneuen" kann beliebig oft wiederholt werden, solange der Client die Adresse noch braucht und der Server nichts dagegen hat. Unter Umständen verweigert der DHCP-Server die Erneuerung. Falls die gewünschte Adresse für den DHCP-Server inakzeptabel ist, schickt er dem Client ein ablehnendes DHCPNAK. Der Client beginnt dann von Neuem.

Was passiert, wenn der Client den DHCP-Server nicht mehr erreichen kann, der ihm seine IP-Adresse zugeteilt hat? Bevor sein Lease verfällt, soll der Client den DHCPREQUEST nicht mehr direkt an den DHCP-Server schicken, sondern es broadcasten. Somit hören alle DHCP-Server wieder mit. Wenn Failover richtig funktioniert, wird der Backup-Server jetzt das Lease erneuen. Kommt hingegen keine Antwort oder nur ein DHCPNAK, muß der Client wieder von vorne beginnen, und ein DHCPDISCOVER broadcasten usw. Das ist insofern schlecht, als er nun höchstwahrscheinlich eine ganz andere IP-Adresse bekommt. Bestehende Verbindungen, die noch die alte IP-Adresse verwenden, müssen abgebaut werden.

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

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

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:

Der Server führt das Kommando DELE nicht unmittelbar aus. Die entsprechenden E-Mails werden als gelöscht markiert 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:

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:

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:

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