Systemsicherheit 10: S/MIME

Systemsicherheit 10: S/MIME Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP

1. E-Mail-Format RFC 822 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: E-Mail Message Format (1982!) Umschlag (wird während des Transports gebildet) Header (definierte Felder wie TO:, FROM:,...) Rumpf (ASCII, durch Leerzeile vom Header getrennt) RFC 821: SMTP POP Mailserver@rub.de POP SMTP STMP SMTP SMTP Client Mailserver 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: E-Mail-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 2005 16:25:37 (GMT) From: joerg.schwenk@rub.de Subject: RFC 822 To: guests@nds.rub.de CC: cpaar@crypto.rub.de Hallo. Dieser Abschnitt ist der Body der Nachricht, der durch eine Leerzeile vom Header getrennt ist.

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 8859-1 (ISO Latin 1) vs. ASCII 8859-1 0? 1? 2? 3? 4? 5? 6? 7? 8? 9? A? B? C? D? E? F??0 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. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP 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 Multipart Message Plain Enriched Mixed Parallel Alternative Digest Rfc822 Partial Unformatierter Text, z.b. ASCII. Mit bestimmten Formatierungen. Unabhängige Teile, die zusammen übertragen und in der übertragenen Ordnung dargestellt werden sollen. Unterschied zu Mixed: Hier ist keine Ordnung definiert. Alternative Versionen derselben Information. Wie Mixed, aber als Default-Typ/Subtyp wird Message/rfc822 angenommen. Der Body der Nachricht ist selbst eine E-Mail. Zeigt eine Fragmentierte E-Mail an. External-body Pointer auf ein Objekt, das woanders liegt.

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 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 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 X-UIDL: VEG"!RZS"!Z9f"!%9V"! Return-Path: <hgi-news-bounces+lijun.liao=rub.de@lists.ruhr-uni-bochum.de> Delivered-To: lijun.liao@rub.de Received: (qmail 3608 invoked from network); 24 Jan 2005 05:39:37-0000 Received: from mailhost.rz.ruhr-uni-bochum.de (HELO sunu007.rz.ruhr-unibochum.de) (134.147.64.6) by mailhost.rz.ruhr-uni-bochum.de with SMTP; 24 Jan 2005 05:39:37-0000 Return-Path: <cpaar@crypto.ruhr-uni-bochum.de> Delivered-To: mailman-hgi-news@lists.ruhr-uni-bochum.de Received: (qmail 3443 invoked from network); 24 Jan 2005 05:39:32-0000 Received: from mail2.crypto.ruhr-uni-bochum.de (134.147.40.132) by mi-1.rz.ruhr-uni-bochum.de with SMTP; 24 Jan 2005 05:39:32-0000... Received: from cryptla (pd95100b6.dip.t-dialin.net [217.81.0.182]) by mail2.crypto.ruhr-uni-bochum.de (Postfix on email-server of Communication Security Group) with ESMTP id EF3737FA1A for <hgi-news@lists.ruhr-uni-bochum.de>; Mon, 24 Jan 2005 06:39:18 +0100 (CET)

MIME-Beispiel: Header To: "HGI-Liste" <hgi-news@lists.ruhr-uni-bochum.de> Date: Mon, 24 Jan 2005 06:41:02 +0100 Message-ID: <000701c501d7$4aea4270$c5c9fea9@cryptla> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_nextpart_000_0008_01c501df.acb03110" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.29.0.7; VDF: 6.29.0.63; host: mail2) From: hgi-news@lists.ruhr-uni-bochum.de Subject: [HGI-News] Phishing Semiar am 1. Februar X-BeenThere: hgi-news@lists.ruhr-uni-bochum.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@hgi.ruhr-uni-bochum.de... MIME-Beispiel: Body This is a multi-part message in MIME format. Leerzeile! ------=_NextPart_000_0008_01C501DF.ACB03110 Content-Type: multipart/related; boundary="----=_nextpart_001_0009_01c501df.acb03110" ------=_NextPart_001_0009_01C501DF.ACB03110 Content-Type: multipart/alternative; boundary="----=_nextpart_002_000a_01c501df.acb03110" ------=_NextPart_002_000A_01C501DF.ACB03110 Content-Type: text/plain; charset="windows-1258" Content-Transfer-Encoding: quoted-printable Dieser Text wird nicht dargestellt, sondern sein HTML- Äquivalent Liebe Freunde des HGI, =20 hier eine Ank=FCndigung eines hoch aktuellen Seminars der GITS AG. Die Anmeldung befindet sich im Anhang.

MIME-Beispiel: Darstellung Die wichtigsten Header-Zeilen Attachment HTML- Text MIME-Beispiel: Body ------=_NextPart_002_000A_01C501DF.ACB03110 Content-Type: text/html; charset="windows-1258" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html xmlns:v=3d"urn:schemas-microsoft-com:vml"...>... </html> ------=_NextPart_002_000A_01C501DF.ACB03110-- ------=_NextPart_001_0009_01C501DF.ACB03110 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <image001.jpg@01c501df.abc97a90> /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc2oH...

MIME-Beispiel: Darstellung JPEG GIF MIME-Beispiel: Body ------=_NextPart_001_0009_01C501DF.ACB03110 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: <image002.gif@01c501df.abc97a90> R0lGODlhbwIIAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAA... ------=_NextPart_001_0009_01C501DF.ACB03110-- ------=_NextPart_000_0008_01C501DF.ACB03110 Content-Type: application/pdf; name="phising_seminar_gits-ag.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="phising_seminar_gits-ag.pdf" JVBERi0xLjIgDSXi48/TDQogDTEwIDAgb2JqDTw8DS9MZW5ndGggMTEgMCBSDT4+D...

MIME-Beispiel: Struktur des MIME-Body multipart/mixed multipart/related application/pdf text/plain multipart/alternative image/jpeg image/gif text/plain text/html wird vom Client dargestellt wird als Attachment dargestellt Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP

3. S/MIME: Hybride Verschlüsselung Datei/Mail wird symmetrisch verschlüsselt (DES) Verwendeter Schlüssel wird asymmetrisch verschlüsselt (RSA) Sender Empfänger S/MIME: Neue Content-Typen 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.

PKCS#7, #10 Public Key Cryptography Standard # x www.rsasecurity.com/rsalabs/pkcs/index.html 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. S/MIME

S/MIME: Aufbau einer verschlüsselten Nachricht... From: Schwenk <schwenk@tzd.telekom.de> MIME-Version: 1.0 To: schwenk@tzd.telekom.de Subject: S/MIME Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgcwwgckCAQA wczbtmqswcqydvqqgewjertecmboga1ue ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsGA1U ECxMUVGVsZVNlYyBUcnVzdCBDZW50ZXIx ITAfBgNVBAMTGERldXRzY2hlIFRlbGVrb20gVGV zdcbdqqicaswwdqyjkozihvcnaqebbqae... GMzeyBLDhdbv9+ZsvOrW79URmz600QSOzARIWSN 6wg1Zqs2pjtTWm4fiXyMS7oOlBa76oGYX mvvnxkrw+4dhsmywizijl62yx+fsyip0qlmqrx6 6I8MC7Y3zOQsAjiSlg0GuBDBNgYif0RXY 4PMrG3gw2DqD7qCvRMqcPCyYgVugEGLokMjjx7x eu+uae7ucgbufdh4ecggfzvc7qt/paaaa S/MIME: Beispiel AAAAAAAAAA== Message-Body:... Envelope: PKCS7: Content-Type: pkcs7-envelopeddata Version: 0 RecipientInfos: RecipientInfo: Version: 0 Serial-Number: 716 Issuer:... Key-Encryption-Algorithm: Algorithm: rsaencryption Parameter: Encrypted-Key: Length: 64 Bytes 9B:56:48:73:E1:FA:5D:83:... Encrypted-Content: Content-Type: pkcs7-data Encryption-Algorithm: Algorithm: des-ede3-cbc Parameter: Octet-String: Length: 8 Bytes C4:FB:D7:05:A9:84:83:75 Encrypted-Data: Length: 3608 Bytes 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... From: To: Subject: Date:... MIME-Version: 1.0 Content-Type: multipart/signed; protocol= application/x-pks7-signature ; micalg=sha-1; boundary= -----12345------ -----12345------ Eigentliche MIME-E-Mail (ggf. mit Attachments) -----12345------ Content-Type: application/x-pks7- signature; name= smime.p7s ; Content-Transfer-Encoding: Base64 MIAGCSqGSIb3DQEH...Jx9cS9WPmbxEkAAAA== -----12345------ PKCS7: Content-Type: pkcs7-signeddata (2A:86:48:86:F7:0D:01:07:02) Version: 1 Digest-Algorithms: Digest-Algorithm: Algorithm: sha1 (2B:0E:03:02:1A) Parameter: Content: PKCS7: Content-Type: pkcs7-data (2A:86:48:86:F7:0D:01:07:01) Certificates: Certificate: CA-Zertifikat Certificate: Client-Zertifikat (549) SignerInfos: SignerInfo: Serial-Number: 549... Signature: 0F:9B:46:5B:...:99:BC:44:90

S/MIME: Schlüsselmanagement Server-basiert: Webinterface LDAP-Server mit X.509-Zertifikaten E-Mail-basiert: X.509-Zertifikat als Attachment im PKCS#7-Teil einer signierten Nachricht A B Hallo PKCS#7: A s Zertifikat X5Rvd4Z PKCS#7: B s Zertifikat Hz67Fd PKCS#7: A s Zertifikat S/MIME: Probleme in der Praxis Signaturvarianten: Opaque und Clear Opaque (application/pkcs-7-mime): Nicht S/MIME-fähige Clients können auch unverschlüsselte Mails nicht darstellen. Clear (multipart/signed): Mailserver können beim Transport der Mail minimale Änderungen vornehmen, die die Signatur ungültig machen. Einbindung von Chipkarten über PKCS#11 oder Microsoft Cryptographic Service Provider

S/MIME: Probleme in der Praxis (2) Schlüsselmanagement (E-Mail) Zum Verschlüsseln sollte immer das aktuellste Zertifikat des Empfängers verwendet werden. Beim Empfang einer signierten E- Mail mit einem neuen gültigen Zertifikat müsste also dieses als Default übernommen werden. Bei manchen E-Mail-Clients ist jedoch eine manuelle Konfiguration erforderlich. Schlüsselmanagement (Server) Bei welcher der vielen Certification Authorities hat der Empfänger sein Zertifikat beantragt? Die E-Mail-Adresse gibt darüber keinen Aufschluss. (Mögliche Lösung: DNSSEC.) S/MIME: Probleme in der Praxis (3) Reply: Verschlüsselte E-Mail sollte auch verschlüsselt beantwortet werden (meist OK). Forward: Verschlüsselte E-Mail kann nicht immer verschlüsselt geforwarded werden. Ist Verschlüsselung möglich, so muß diese auch angewendet werden. Wenn nicht, muß der Nutzer entscheiden.

S/MIME: Probleme in der Praxis (4) 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 E-Mail wird eine LDAP-Anfrage generiert: Enorme Lastprobleme Lösungsmöglichkeit: Online-Überprüfung der gespeicherten Zertifikate in festen Zeitintervallen. Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP

Bilanz: Datenformate einer E-Mail RFC 822: Grundlegende Unterteilung in Header und Body, ASCII-basiert MIME: Baumstruktur zum Verwalten von Multimedia- Anhängen HTML: Nur noch wenige E-Mails 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? 4. XMaiL Die XML-Standards enthalten bis auf eine funktionierende PKI 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 Schnellster Weg zur PKI: Ausgabe von XML-formatierten Zertifikaten nach X.509 von den bestehenden PKIs.

RFC 2822 XMaiL From: John Doe <jdoe@machine.example> <?xml version="1.0"...?> To: Mary Smith <mary@example.net> <XMaiL xmlns="http://..."> Subject: Saying Hello <Header> Date: Fri, 4. 21 Lösung: Nov 1997 09:55:06-0600 XMaiL <From> Message-ID: 1234@local.machine.example <Name>John Doe</Name> <Address> This is a message just to say hello. jdoe@machine.example So, "Hello". </Address> </From> <To> <Name>Mary Smith</Name> <Address> mary@example.net </Address> </To> <Subject> Saying Hello </Subject> <Date> Fri, 21 Nov 1997 09:55:06-0600 </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> 4. XMaiL Vorteile Standardsoftware für E-Mail-Clients: Zur Darstellung werden ausschließlich XML-Technologien verwendent; großes Optimierungspotenzial wegen Verzicht auf ASN.1 Archivierung von E-Mails: Jede XML-Datenbank ist geeignet Sicherheit/SPAM: <FROM>- und <TO>-Elemente können mit in die digitale Signatur einbezogen werden

4. XMaiL Übergangsszenarien Problem: Anzahl der E-Mail-Clients ist ungefähr proportional zur Anzahl der Internetnutzer Phase 1: Gateway zur Konvertierung von E-Mails in XMaiLs, Archivierung in XML-Datenbank Phase 2: XMaiL verbessert den Workflow in den Intranets, Gateway zum Internet Phase 3: Viele E-Mail-Clients unterstützen XML 1.0 und diverse Begleitstandards zur Darstellung von XMLformatierten E-Mails 4. XMaiL Phase 3 (Forts.): XMaiLs werden in E-Mails verpackt versendet:... To: From:... Content-Type: multipart/alternative... Content-Type: message/rfc822... Content-Type: application/xmail...

4. XMaiL: Zusammenfassung E-Mail nach RFC 2822 Header {Leerzeile} Body MIME-Struktur 1 RFC 2822-Parser MIME-Parser XMaiL <Header> <Body> <MIME-Struktur 1> MIME-Struktur 2 PKCS#7-Struktur X.509-Struktur PKCS#7-Parser Gateway X.509-Parser <MIME-Struktur 2> <PKCS#7> <X.509> Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP

5 POP3 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 E-Mail anschauen, bevor man sie auf seinen Rechner lädt. 5 POP3 Protokoll für den Zugriff auf ein Postfach; download-anddelete Modell ASCII basiertes Protokoll 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

5 POP3 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) Client Server 5 POP3 und IMAP Eine POP3- Sitzung <Warte auf eine Verbindung auf TCP Port 110> <Öffne TCP-Verbindung> +OK POP3 server ready 1896.697170952@rub.de APOP schwenk c4c9334bac560ecc979e58001b3e22fb +OK schwenk's maildrop has 2 messages (320 octets) STAT +OK 2 320 LIST +OK 2 messages (320 octets) 1 120 2 200. RETR 1 +OK 120 octets <Der POP3-Server sendet E-Mail 1>. DELE 1 +OK message 1 deleted RETR 2 +OK 200 octets <Der POP3-Server sendet E-Mail 2>. DELE 2 +OK message 2 deleted QUIT +OK rub POP3 server signing off (maildrop empty) <Schließe TCP-Verbindung> <Warte auf nächste Verbindung>

5 POP3 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] 5 POP3 3. Update Wenn der Client das QUIT-Kommando aus dem TRANSAKTIONS-Zustand heraus sendet, wechselt die POP3-Sitzung in den UPDATE-Zustand. QUIT Erst jetzt löscht der POP3-Server die Nachrichten, die als gelöscht markiert wurden und meldet den Status dieser Aktion zurück. Mögliche Stati: +OK -ERR some deleted messages not removed

5 POP3 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 Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP

6 IMAP Es gibt drei unterschiedliche E-Mail Modelle: Offline Online Disconnected Definiert in RFC 1733 IMAP4 (Port 143) unterstützt alle drei Modelle POP3 ist ein Offline Modell ( download-delete ) 6 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) 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

6 IMAP 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 6 IMAP 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

6 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 first unseen message S: * OK [UIDVALIDITY 3857529045] UIDs valid S: a002 OK [READ-WRITE] SELECT completed 6 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.

6 IMAP: Beispiel C: a003 fetch 12 full S: * 12 FETCH ( FLAGS (\Seen) INTERNALDATE "17-Jul-96 02:44:25" RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 96 02:23:25 (PDT)" "IMAP4rev1 WG mtg summary and minutes" (("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 "<B27397-0100000@cac.washington.edu>") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) a003 OK FETCH completed 6 IMAP: Beispiel 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.

6 IMAP: Beispiel C: a004 fetch 12 body[header] S: * 12 FETCH (BODY[HEADER] {350} Date: Wed, 17 Jul 1996 02:23:25-0700 (PDT) From: Terry Gray <gray@cac.washington.edu> Subject: IMAP4rev1 WG mtg summary and minutes To: imap@cac.washington.edu cc: minutes@cnri.reston.va.us, John Klensin <KLENSIN@INFOODS.MIT.EDU> Message-Id: <B27397-0100000@cac.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII ) a004 OK FETCH completed 6 IMAP: Beispiel 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.

6 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 6 IMAP: Authenticate S: * OK IMAP4 Server C: A001 AUTHENTICATE KERBEROS_V4 S: + AmFYig== 32-Bit-Nonce, base64 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/ IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfH EcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6Ies KvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: + or//eoaadzi= C: DiAF5A4gA+oOIALuBkAAmw== S: A001 OK Kerberos V4 authentication successful... Kerberos-Ticket und Kerberos-Authentikator der Mailadresse und der Nonce

6 IMAP: Authenticate S: * OK IMAP4 Server C: A001 AUTHENTICATE KERBEROS_V4 S: + AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/ IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfH EcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6Ies 32-Bit-Nonce+1, KvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh weitere Vorschläge S: + or//eoaadzi= für Schutzmechanimen C: DiAF5A4gA+oOIALuBkAAmw== S: A001 OK Kerberos V4 authentication successful... 32-Bit-Nonce, akzeptierte Vorschläge für Schutzmechanimen, Padding, das Ganze verschlüsselt 6 IMAP: Authenticate The AUTHENTICATE command indicates an authentication mechanism, such as described in [RFC 1731], to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the client.... The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client answer consists of a line consisting of a BASE64 encoded string.... RFC 1731 beschreibt Kerberos GSS-API S/KEY