Systemsicherheit 10: S/MIME

Transkript

1 Gliederung 1. -Format RFC 822 Systemsicherheit 10: S/MIME 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 1. -Format RFC 822 RFC 821: SMTP RFC (2)821: Simple Mail Transfer Protocol (SMTP) TCP Port 25 Client-Kommandos als Zeichen: HELO, MAIL FROM, Server-Antworten als Zahlen und Text: 220 (service ready), 250 (other party OK), 354 (send mail), RFC (2)822: Message Format (1982!) Umschlag (wird während des Transports gebildet) Header (definierte Felder wie TO:, FROM:, ) Rumpf (ASCII, durch Leerzeile vom Header getrennt) Client Mailserver POP SMTP STMP Mailserver@rub.de SMTP POP SMTP 220 rub.de SMTP server ready HELO uni.de 250 rub.de says hello MAIL FROM: <student@uni.de> 250 sender OK RCPT TO: <service@rub.de> 250 recipient OK DATA 354 send mail; end with. -line Daten Daten Daten. 250 message accepted QUIT 221 rub.de closing connection RFC 822: -Datenformat Header: Umschlag (Envelope): Wird vom Mailsystem mit Hilfe der Header-Information erzeugt. Kopfzeilen: Jede Zeile besteht aus Schlüsselwort, Doppelpunkt, und Argumenten. Body: ASCII-Text, vom Header durch Leerzeile getrennt. RFC 822 Received:. Date: Tue, 20 April :25:37 (GMT) From: joerg.schwenk@rub.de Subject: RFC 822 To: guests@swt.rub.de CC: hb@w3l.de Hallo. Dieser Abschnitt ist der Body der Nachricht, der durch eine Leerzeile vom Header getrennt ist.

2 RFC 822: Probleme Binärdaten mussten vor dem Versenden in ASCII umgewandelt werden (uuencode). Dazu fehlte ein Standard. Umlaute und andere Schriftarten (z.b. Kyrillisch) konnten nicht dargestellt werden. Übersetzung in Gateways von ASCII in EBDIC und zurück ergab Übersetzungsfehler. Fehlerhafte Implementierungen von Gateways: Löschen oder Hinzufügen von Carriage Return oder Linefeed Abschneiden oder Umbrechen von Zeilen länger als 76 Zeichen Entfernung von mehrfachen Leerzeichen Umwandlung von TAB in Leerzeichen RFC 822: Probleme 8 Bit vs. 7 Bit: ISO (ISO Latin 1) vs. ASCII ? 1? 2? 3? 4? 5? 6? 7? 8? 9? A? B? C? D? E? F??0 P ` p À Ð à ð?1! 1 A Q a q ± Á Ñ á ñ?2 " 2 B R b r ² Â Ò â ò?3 # 3 C S c s ƒ ³ Ã Ó ã ó?4 $ 4 D T d t Ä Ô ä ô?5 % 5 E U e u µ Å Õ å õ?6 & 6 F V f v Æ Ö æ ö?7 ' 7 G W g w Ç ç?8 ( 8 H X h x ˆ È Ø è ø?9 ) 9 I Y i y ¹ É Ù é ù?a * : J Z j z Š š ª º Ê Ú ê ú?b + ; K [ k { Ë Û ë û?c, < L \ l Œ œ ¼ Ì Ü ì ü?d - = M ] m } - ½ Í Ý í ý?e. > N ^ n ~ Ž ž ¾ Î Þ î þ?f /? O _ o Ÿ Ï ß ï ÿ Gliederung 1. -Format RFC Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 2. MIME MIME = Multipurpose Internet Mail Extensions RFC 2045 bis 2049 Fünf neue Headerfelder Vordefinierte Contentformate, um ihre Darstellung auf MIME-konformen Clients zu ermöglichen Mehrere Übertragungscodierungen, die robust gegen Fehler der Mailgateways sind MIME: Neue Header-Felder MIME-Version: 1.0 Content-Type: beschreibt den angefügten Content und ermöglicht es so, das passende Anzeigemodul zu starten Content-Transfer-Encoding: beschreibt die Transportcodierung Content-ID: eindeutige Bezeichnung des Contents Content-Description: Beschreibung des Content zur Fehlersuche MIME: Content-Typen Typ Subtyp Beschreibung Text Plain Unformatierter Text, z.b. ASCII. Enriched Mit bestimmten Formatierungen. Multipart Mixed Unabhängige Teile, die zusammen übertragen und in der übertragenen Ordnung dargestellt werden sollen. Parallel Unterschied zu Mixed: Hier ist keine Ordnung definiert. Alternative Alternative Versionen derselben Information. Message Digest Rfc822 Partial Wie Mixed, aber als Default-Typ/Subtyp wird Message/rfc822 angenommen. Der Body der Nachricht ist selbst eine . Zeigt eine Fragmentierte an. External-body Pointer auf ein Objekt, das woanders liegt.

3 MIME: Content-Typen Typ Subtyp Beschreibung Image Jpeg JPEG-Format, JFIF-Encodierung Gif GIF-Format Video Mpeg Video im MPEG-Format Audio Basic Einkanal 8 Bit ISDN, 8kHz Application Postscript Adobe Postscript Octet-stream Binärdaten aus 8-bit-Bytes MIME: Transfer-Encoding 7 Bit: ASCII 8 Bit: kurze Zeilen, aber mit nicht-ascii-zeichen Binary: lange Zeilen mit nicht-ascii-zeichen Quoted-printable: Jedes nicht-druckbare Zeichen z wird durch die Kombination =hex(z) ersetzt. Falls der Text viele ASCII-Zecihen beinhaltet, bleibt er lesbar. Base64: 3*8 Bit wird zu 4*6 Bit, jedem der 64 verschiedenen 6-Bit-Werte wird ein ASCII-Zeichen gemäß der Tabelle auf der folgenden Folie zugeordnet. MIME: Transfer-Encoding: Base64 Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j C 19 T 36 k D 20 U 37 l E 21 V 38 m F 22 W 39 n G 23 X 40 o H 24 Y 41 p I 25 Z 42 q J 26 a 43 r K 27 b 44 s L 28 c 45 t M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y MIME-Beispiel: Envelope und Header Return-Path: <hallo@t-online.de> Received: from sal9000 ( @[ ]) by fwd11.sul.t-online.com with smtp id 18xxtK-20XEGmx; Wed, 26 Mar :31: From: hallo@t-online.de (=?iso ?q?au-pair-vermittlung?=) To: <hallo@t-online.de> Subject: =?iso ?q?newsletter_april_/_mai_und_anmeldung_f=fcr_amsterdam_f=fcr?= =?iso ?q?_ ?= Date: Wed, 26 Mar :35: Message-ID: <NHBBJDGIIMMIJDNBADBOMEJPDFAA.hallo@t-online.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_nextpart_000_0011_01c2f32f.a43d79e0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build ( ) X-MimeOLE: Produced By Microsoft MimeOLE V Importance: Normal X-Sender: @t-dialin.net X-Mozilla-Status: 8001 X-Mozilla-Status2: X-UIDL: 726f8c4d65bb1bb3 MIME-Beispiel: Body MIME-Beispiel: Body This is a multi-part message in MIME format =_NextPart_000_0011_01C2F32F.A43D79E0 Content-Type: multipart/related; boundary="----=_nextpart_001_0012_01c2f32f.a43d79e =_NextPart_001_0012_01C2F32F.A43D79E0 Content-Type: multipart/alternative; boundary="----=_nextpart_002_0013_01c2f32f.a43d79e =_NextPart_002_0013_01C2F32F.A43D79E0 Content-Type: text/plain; charset="iso " Content-Transfer-Encoding: 8bit Sehr geehrte Gastfamilien, Mit freundlichen Grüssen =_NextPart_002_0013_01C2F32F.A43D79E0 Content-Type: text/html; charset="iso " Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><head> <META http-equiv=3dcontent-type content=3d"text/html; = charset=3diso "> <STYLE>BODY {BACKGROUND-POSITION: left top; MARGIN-TOP: 90px; FONT-SIZE: 10pt; = MARGIN-LEFT: 8px; COLOR: #000000; BACKGROUND-REPEAT: no-repeat; = FONT-FAMILY: Arial} </STYLE> <META content=3d"mshtml " name=3dgenerator></head> <BODY background=3dcid: @ > <SPAN=20 style=3d"font-family: 'Comic Sans MS'"> <o:p></o:p></span>=20 <P class=3dmsofooter><span style=3d"font-family: 'Comic Sans MS'"><FONT=20 face=3darial>s</font><strong>ehr geehrte=20 Gastfamilien,<o:p></o:p></STRONG></SPAN></P>

4 MIME-Beispiel: Body MIME-Beispiel: Darstellung =_NextPart_002_0013_01C2F32F.A43D79E =_NextPart_001_0012_01C2F32F.A43D79E0 Content-Type: image/jpeg; name="ohne_bil.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy =_NextPart_001_0012_01C2F32F.A43D79E =_NextPart_000_0011_01C2F32F.A43D79E0 Content-Type: application/msword; name="newsletter.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="newsletter.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAGQAAAAAAAAAA =_NextPart_000_0011_01C2F32F.A43D79E0-- hallo hallo ) Gliederung 1. -Format RFC Multipurpose Internet Mail Extensions (MIME) 3. S/MIME: Hybride Verschlüsselung Datei/Mail wird symmetrisch verschlüsselt (DES) Verwendeter Schlüssel wird asymmetrisch verschlüsselt (RSA) Sender Empfänger 3. S/MIME S/MIME: Neue Content-Typen PKCS#7, #10 Typ Subtyp S/MIME Parameter Beschreibung Multipart Signed Eine signierte Nachricht in zwei Teilen: Der erste Teil ist die unveränderte Originalnachricht, der zweite die Signatur ( Clear-signed ). Application pkcs7-mime signeddata Ein signierter S/MIME-Datensatz. pkcs7-mime envelopeddata Ein verschlüsselter S/MIME-Datensatz. pkcs7-mime degenerate signeddata Der Datensatz enthält nur X.509-Zertifikate. pkcs7- signature - Der Content-Typ des Signaturteils der Multipart/Signed- Nachricht. pkcs10-mime - Ein Request zur Generierung eines Zertifikats nach PKCS#10. Public Key Cryptography Standard # x Datenformate und Schnittstellen für Public-Key- Kryptographie werden beschrieben. PKCS#7: Datenformat für verschlüsselte und/oder signierte Datensätze PKCS#10: Datenformat zur Benatragung eines X.509-Zertifikats.

5 S/MIME S/MIME: Aufbau einer verschlüsselten Nachricht Message-Body: From: Schwenk Envelope: MIME-Version: 1.0 PKCS7: To: Content-Type: Subject: S/MIME pkcs7-envelopeddata Content-Type: application/x-pkcs7-mime; Version: 0 name="smime.p7m" RecipientInfos: Content-Transfer-Encoding: base64 RecipientInfo: Content-Disposition: attachment; Version: 0 filename="smime.p7m" Serial-Number: 716 Content-Description: S/MIME Encrypted Issuer: Message Key-Encryption-Algorithm: Algorithm: rsaencryption Parameter: MIAGCSqGSIb3DQEHA6CAMIACAQAxgcwwgckCAQA Encrypted-Key: wczbtmqswcqydvqqgewjertecmboga1ue Length: 64 Bytes ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsGA1U 9B:56:48:73:E1:FA:5D:83: ECxMUVGVsZVNlYyBUcnVzdCBDZW50ZXIx Encrypted-Content: ITAfBgNVBAMTGERldXRzY2hlIFRlbGVrb20gVGV Content-Type: pkcs7-data zdcbdqqicaswwdqyjkozihvcnaqebbqae Encryption-Algorithm: Algorithm: des-ede3-cbc GMzeyBLDhdbv9+ZsvOrW79URmz600QSOzARIWSN Parameter: 6wg1Zqs2pjtTWm4fiXyMS7oOlBa76oGYX Octet-String: mvvnxkrw+4dhsmywizijl62yx+fsyip0qlmqrx6 Length: 8 Bytes 6I8MC7Y3zOQsAjiSlg0GuBDBNgYif0RXY C4:FB:D7:05:A9:84:83:75 4PMrG3gw2DqD7qCvRMqcPCyYgVugEGLokMjjx7x Encrypted-Data: eu+uae7ucgbufdh4ecggfzvc7qt/paaaa S/MIME: Beispiel Length: 3608 Bytes AAAAAAAAAA== Lehrstuhl für Netz- 3A:DB:98:08:1C:2E:C0:6B:41:A3:15:19:C2:1E: und Datensicherheit S/MIME: Aufbau einer signierten Nachricht PKCS7: From: Content-Type: To: pkcs7-signeddata Subject: (2A:86:48:86:F7:0D:01:07:02) Date: Version: 1 Digest-Algorithms: Digest-Algorithm: MIME-Version: 1.0 Algorithm: Content-Type: multipart/signed; sha1 (2B:0E:03:02:1A) protocol= application/x-pks7-signature ; Parameter: Content: micalg=sha-1; PKCS7: boundary= Content-Type: pkcs7-data (2A:86:48:86:F7:0D:01:07:01) Eigentliche MIME- (ggf. mit Certificates: Certificate: Attachments) CA-Zertifikat Certificate: Client-Zertifikat (549) Content-Type: application/x-pks7- SignerInfos: signature; name= smime.p7s ; SignerInfo: Serial-Number: 549 Content-Transfer-Encoding: Base64 MIAGCSqGSIb3DQEH..Jx9cS9WPmbxEkAAAA== Signature: F:9B:46:5B:.:99:BC:44:90 Bilanz: Datenformate einer RFC 822: Grundlegende Unterteilung in Header und Body, ASCII-basiert MIME: Baumstruktur zum Verwalten von Multimedia- Anhängen HTML: Nur noch wenige s werden als reiner Text versendet S/MIME: Neue Datenstrukturen, komplexe Auswertungsregeln PKCS#7: ASN.1-basiert X.509: ASN.1-basiert, zur korrekten Darstellung muss eine PKI vorhanden sein Kann man das vereinheitlichen? Gliederung 1. -Format RFC Multipurpose Internet Mail Extensions (MIME) S/MIME: Schlüsselmanagement LDAP-Server mit X.509-Zertifikaten X.509-Zertifikat als Attachment im PKCS#7-Teil einer signierten Nachricht 3. S/MIME Hallo A PKCS#7: A s Zertifikat B X5Rvd4Z PKCS#7: B s Zertifikat Hz67Fd PKCS#7: A s Zertifikat

6 S/MIME: Probleme in der Praxis S/MIME: Probleme in der Praxis (2) Signaturvarianten: Opaque und Clear Opaque: Nicht S/MIME-fähige Clients können auch unverschlüsselte Mails nicht darstellen. Clear: Mailserver können beim Transport der Mail minimale Änderungen vornehmen, die die Signatur ungültig machen. Einbindung von Chipkarten über PKCS#11 oder Microsoft CSP Schlüsselmanagement Zum Verschlüsseln sollte immer das aktuellste Zertifikat des Empfängers verwendet werden. Netscape Messenger: OK Microsoft Outlook Express: Unter Optionen/Sicherheit/Digitale IDs/Andere Personen können zu einer -adresse mehrere Zertifikate abgelegt sein. Nutzer muß aber über Adressbuch/ -Adresse/ Eigenschaften/Digitale IDs eines der Zertifikate als Standard auswählen. S/MIME: Probleme in der Praxis (3) S/MIME: Probleme in der Praxis (4) Reply: Verschlüsselte sollte auch verschlüsselt beantwortet werden (meist OK). Forward: Verschlüsselte kann nicht immer verschlüsselt geforwarded werden. Ist Verschlüsselung möglich, so muß diese auch angewendet werden. Wenn nicht, muß der Nutzer entscheiden. Gültigkeit eines Zertifikats Certificate Revocation Lists (CRLs) werden von den Clients oft nicht ausgewertet. Es gibt noch keine Erfahrungen, ob dieses Konzept in der Praxis (bei Millionen von Kunden) einsetzbar ist. Online-Überprüfung Vor jedem Versenden einer wird eine LDAP-Anfrage generiert: Enorme Lastprobleme Lösungsmöglichkeit: Online-Überprüfung der gespeicherten Zertifikate in festen Zeitintervallen. Die XML-Standards enthalten bis auf X.509 alles RFC 822 <XML><HEADER/><BODY/></XML> MIME <MultipartMixed> HTML XHTML S/MIME XML Signatur und XML Verschlüsselung X.509 Kann mit XML nachgebildet werden RFC 2822 XMaiL From: John Doe To: Mary Smith Subject: Saying Hello Date: Fri, 21 Nov :55: Message-ID: 4. Lösung: XMaiL This is a message just to say hello. So, "Hello". <?xml version="1.0"?> <XMaiL xmlns=" <Header> <From> <Name>John Doe</Name> <Address> jdoe@machine.example </Address> </From> <To> <Name>Mary Smith</Name> <Address> mary@example.net </Address> </To> <Subject> Saying Hello </Subject> <Date> Fri, 21 Nov :55: </Date> <Message-ID> 1234@local.machine.example </Message-ID> </Header> <Body> <Text> <Plain> This is a message just to say hello. So, "Hello". </Plain> </Text> </Body> </XMaiL>

7 XMaiL.xml XMaiL_Schema.xsd Vorteile Standardsoftware für -Clients: Zur Darstellung werden ausschließlich XML-Technologien verwendent; großes Optimierungspotenzial wegen Verzicht auf ASN.1 Archivierung von s: Jede XML-Datenbank ist geeignet Sicherheit/SPAM: <FROM>- und <TO>-Elemente können mit in die digitale Signatur einbezogen werden Übergangsszenarien Problem: Anzahl der -Clients ist ungefähr proportional zur Anzahl der Internetnutzer Phase 1: Gateway zur Konvertierung von s in XMaiLs, Archivierung in XML-Datenbank Phase 2: XMaiL verbessert den Workflow in den Intranets, Gateway zum Internet Phase 3: Alle -Clients unterstützen XML 1.0 und diverse Begleitstandards zur Darstellung von XMLformatierten s Phase 3 (Forts.): XMaiLs werden in s verpackt versendet: To: From: Content-Type: Multipart/Mixed Content-Type: MIME-Body Content-Type: XMaiL : Zusammenfassung nach RFC 2822 Header {Leerzeile} Body MIME-Struktur 1 MIME-Struktur 2 PKCS#7-Struktur X.509-Struktur XMaiL RFC 2822-Parser <Header> <Body> MIME-Parser <MIME-Struktur 1> PKCS#7-Parser <MIME-Struktur 2> <PKCS#7> Gateway X.509-Parser <X.509> SMTP liefert Nachrichten an einen Server, der immer Online sein muss (sonst kann die Nachricht nicht zugestellt werden). Für PC-Arbeitsplätze, die nur einige Stunden am Tag eingeschaltet sind, ist dieses verfahren nicht praktikabel POP3: Internet Service Provider betreibt den SMTP-Server, der E- Mails in einem Postfach speichert, und der Nutzer lädt die Nachrichten in diesem Postfach mit dem Post Office Protocol (Version 3) auf seinen lokalen Rechner. IMAP: Das Postfach eines Nutzers auf dem Server kann strukturiert sein, und man kann seine anschauen, bevor man sie auf seinen Rechner lädt.

8 POP3 Protokoll für den Zugriff auf ein Postfach; download-anddelete Modell ASCII basiertes Protokoll; einfach zu implementieren durch Telnet-NVT Weit verbreitet und in jedem Client vorhanden; aktueller Standard im RFC 1939 von Mai 1996; Port 110 Drei Zustände 1. Autorisierung 2. Transaktion 3. Update 1. Autorisierung Minimale Kommandos USER name (Mailboxname) PASS password (Passwort) QUIT Optionale Kommandos APOP name hashwert (Alternative Autorisierung zur Vermeidung der Übertragung von Klartextpasswörtern) Einfaches Challenge-and-Response-Protokoll Benötigt gemeinsames Geheimnis k von Client und Server Server sendet in seiner +OK-Nachricht die Challenge-Zahl RAND Client antwortet mit hashwert=md5(rand,k) 2. Transaction Minimale Kommandos Nachrichtenanzahl und Größe: STAT Liste der Nachrichten: LIST [msg] Nachricht abfragen: RETR msg Nachricht löschen: DELE msg No operation: NOOP Reset: RSET Session beenden: QUIT Optionale Kommandos Nur Header und die ersten n Zeilen abfragen: Einheitliche ID für Nachrichten abfragen TOP msg n UIDL [msg] 3. Update Wenn der Client das QUIT-Kommando aus demtransaktions- Zustand heraus sendet, wechselt die POP3-Sitzung in den UPDATE- Zustand. QUIT Arguments: none Restrictions: none Discussion: The POP3 server removes all messages marked as deleted from the maildrop and replies as to the status of this operation. If there is an error, such as a resource shortage, encountered while removing messages, the maildrop may result in having some or none of the messages marked as deleted be removed. In no case may the server remove any messages not marked as deleted. Whether the removal was successful or not, the server then releases any exclusive-access lock on the maildrop and closes the TCP connection. Possible Responses: +OK -ERR some deleted messages not removed POP3-Antworten Eine Response kann 512 Zeichen lang sein (inklusive dem abschließenden CRLF ) Sie besteht aus einem Status Indikator und einer Nachricht in Klartext Es gibt positive ( +OK ) und negative ( -ERR ) +OK und -ERR müssen in Großbuchstaben gesendet werden Manche Antworten enthalten weitere Informationen, wie z.b. die Zahl der Nachrichten oder dessen Größe <Warte auf eine Verbindung auf TCP Port 110> <Öffne TCP-Verbindung> +OK POP3 server ready @fh-nuernberg.de APOP mrose c4c9334bac560ecc979e58001b3e22fb +OK mrose's maildrop has 2 messages (320 octets) STAT +OK LIST +OK 2 messages (320 octets) RETR 1 +OK 120 octets <Der POP3-Server sendet 1>. DELE 1 +OK message 1 deleted RETR 2 +OK 200 octets <Der POP3-Server sendet 2>. DELE 2 +OK message 2 deleted QUIT +OK dewey POP3 server signing off (maildrop empty) <Schließe TCP-Verbindung> <Warte auf nächste Verbindung> Eine POP3- Sitzung Client Server

9 IMAP Es gibt drei unterschiedliche Modelle: Offline Online Disconnected Definiert in RFC 1733 IMAP4 (Port 143) unterstützt alle drei Modelle POP3 ist ein Offline Modell ( download-delete ) IMAP Protokoll zum Zugriff und Bearbeiten von Nachrichten auf dem Mail Server Unterstützung von Ordnern auf dem Server Ein Ordner wird Mailbox genannt Möglichkeit der Re-Synchronisation Jede Nachricht hat eine eindeutige Nummer auf dem IMAP Server (UID bzw. MSN) Der Server hat einen Autologout Timer Es können neue Befehle abgesendet werden, obwohl andere noch in Bearbeitung sind Ein Server kann auch von sich aus Antworten an den Client übertragen Das Herunterladen eines Attachments geschieht erst wenn es benötigt wird IMAP: Operationen Erstellen, Löschen und Umbenennen von Mailboxes Kontrolle ob neue Nachrichten vorhanden sind Endgültiges Löschen von Nachrichten Setzen und Entfernen von Flags Auswerten von Nachrichten im RFC822 oder MIME-Format für mehr Kontrolle und Informationen Selektives und Partielles Herunterladen von Nachrichten oder auch Header Einträgen Durchsuchen des Servers IMAP: Befehle und Antworten Jedem Kommando wird ein ASCII-String (ein Tag) vorangestellt (z.b. A001, A002 etc.) Die Antwort enthält auch den entsprechenden Tag gefolgt von einem Server Status einem optionalen Response Code und einem Text zur Weitergabe an den MUA Ein * Tag kennzeichnet eine untagged response Mit dem Tag + signalisiert der Server, das weitere Eingaben für das Kommando notwendig sind IMAP: Beispiel S: * OK IMAP4rev1 Service Ready C: a001 login mrc secret S: a001 OK LOGIN completed C: a002 select inbox S: * 18 EXISTS S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * 2 RECENT S: * OK [UNSEEN 17] Message 17 is the first unseen message S: * OK [UIDVALIDITY ] UIDs valid S: a002 OK [READ-WRITE] SELECT completed IMAP: Beispiel The SELECT command selects a mailbox so that messages in the mailbox can be accessed. Before returning an OK to the client, the server MUST send the following untagged data to the client: FLAGS Defined flags in the mailbox. <n> EXISTS The number of messages in the mailbox. <n> RECENT The number of messages with the \Recent flag set. OK [UIDVALIDITY <n>] The unique identifier validity value. to define the initial state of the mailbox at the client. The server SHOULD also send an UNSEEN response code in an OK untagged response, indicating the message sequence number of the first unseen message in the mailbox.

10 IMAP: Beispiel (2) C: a003 fetch 12 full S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul :44: " RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul :23: (PDT)" "IMAP4rev1 WG mtg summary and minutes" (("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu")) ((NIL NIL "imap" "cac.washington.edu")) ((NIL NIL "minutes" "CNRI.Reston.VA.US") ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL "<B @cac.washington.edu>") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" )) S: a003 OK FETCH completed IMAP: Beispiel (2) The FETCH command retrieves data associated with a message in the mailbox. The data items to be fetched can be either a single atom or a parenthesized list. The currently defined data items that can be fetched are: BODY Non-extensible form of BODYSTRUCTURE. ENVELOPE The envelope structure of the message. This is computed by the server by parsing the [RFC-822] header into the component parts, defaulting various fields as necessary. FLAGS The flags that are set for this message. FULL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) INTERNALDATE The internal date of the message. RFC822.SIZE The [RFC-822] size of the message. IMAP: Beispiel (3) C: a004 fetch 12 body[header] S: * 12 FETCH (BODY[HEADER] {350} S: Date: Wed, 17 Jul :23: (PDT) S: From: Terry Gray <gray@cac.washington.edu> S: Subject: IMAP4rev1 WG mtg summary and minutes S: To: imap@cac.washington.edu S: cc: minutes@cnri.reston.va.us, John Klensin <KLENSIN@INFOODS.MIT.EDU> S: Message-Id: <B @cac.washington.edu> S: MIME-Version: 1.0 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII S: S: ) S: a004 OK FETCH completed IMAP: Beispiel (3) The FETCH command : BODY[<section>]<<partial>> The text of a particular body section. The section specification is a set of zero or more part specifiers delimited by periods. A part specifier is either a part number or one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. An empty section specification refers to the entire message, including the header. IMAP: Beispiel (4) C: a005 store 12 +flags \deleted S: * 12 FETCH (FLAGS (\Seen \Deleted)) S: a005 OK +FLAGS completed C: a006 logout S: * BYE IMAP4rev1 server terminating connection S: a006 OK LOGOUT completed IMAP: Beispiel (4) The STORE command alters data associated with a message in the mailbox. Normally, STORE will return the updated value of the data with an untagged FETCH response. A suffix of ".SILENT" in the data item name prevents the untagged FETCH, and the server SHOULD assume that the client has determined the updated value itself or does not care about the updated value. The currently defined data items that can be stored are: FLAGS <flag list>: Replace the flags for the message with the argument. The new value of the flags are returned as if a FETCH of those flags was done. +FLAGS <flag list> Add the argument to the flags for the message. The new value of the flags are returned as if a FETCH of those flags was done. -FLAGS <flag list>

11 IMAP: Weitere Befehle SELECT: Auswählen einer Mailbox EXAMINE: Auswählen einer Mailbox (read-only) CREATE: Erzeugen einer neuen Mailbox LIST: Liste der Mailboxen zurückgeben LSUB: Liste der aktiven ( subscribed ) Mailboxen zurückgeben SUBSCRIBE: Mailbox zur Liste der aktiven MB hinzufügen UNSUBSCRIBE: Mailbox aus der Liste der aktiven MB entfernen DELETE: Löschen einer Mailbox (nicht-rekursiv) RENAME: Umbenennen einer Mailbox STATUS: Status der MB APPEND: Hinzufügen einer Nachricht zur Mailbox EXPUNGE: Alle Nachrichten mit dem deleted -Flag werden vom Server entfernt COPY: Eine Menge von Nachrichten wird kopiert SEARCH:Die Nachrichten werden nach bestimmten Kriterien durchsucht Client IMAP: Authenticate Server <Warte auf eine Verbindung auf TCP Port 143> <Öffne TCP-Verbindung> * OK IMAP4 Server A001 AUTHENTICATE KERBEROS_V4 + AmFYig== BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/ IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfH EcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6Ies KvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + or//eoaadzi= DiAF5A4gA+oOIALuBkAAmw== A001 OK Kerberos V4 authentication successful IMAP: Authenticate