Network Applications Electronic Mail

Transcription

1 Network Applications Electronic Mail The OSI way to do this is specified in X.400 (84 & 88) Overall Architecture UA P3 UA MS P7 P1 MTS At the core of the X.400 Message Handling System (MHS) is the Message Transfer System Messages of any sort, are transported in a store-and-forward fashion between Message Transfer Agents (s) User Agents (UA) are used by users to send and receive s Message Stores (MS) store received mail is UA not available 1 X.400 s handled Messages, Delivery Reports and PROBES Messages are routed based on their O/R Address - a collection of attributes e.g. C=IE ADMD=Eirmail400 PRMD=NRN O=TCD OU=CS SN=O Mahony GN=Donal The address could also contain routing info e.g. ISDN addresses postal addresses could also be specified Messages are composed at User Agent s using some agreed Content Protocol..P c UAs communicate with the MTS using P3 To allow UA s to contact the system periodically, a Message Store (MS) can take delivery of a message at any time - P7 defined to manage this MSs can be intelligent: route, file or return messages 2 Page 1

2 The Interpersonal Message Service (IPMS) The most common application of an MTS is to carry from one human to another IPMS defined a content protocol called P2 or P22 - multimedia and security capabilities available from the start To: From: Subj: Bcc: Urgency: Body Part IA5Text Voice Heading Body Fax Interworking with other MTS s was also defined MTS Access Unit Physical Delivery Access Unit Telex, Teletex, Fax Postal Service 3 Internet Mail More of an Evolution that a Design: Similar architecture UA, messages are composed using a program - the content is defined in RFC-822 to:president@aras.park.ie from:donal.omahony@cs.tcd.ie Subj:Blah Blah..Blah...Blah Only 7-bit ascii could be transported - no security facilities Later, Multipurpose Internet Mail Extensions (MIME) defined to allow a variety of body parts 4 Page 2

3 Internet Mail Transfer Mail is transported between two systems using the Simple Mail Transfer Protocol (SMTP) across a TCP connection to well-known port # 25 Example: S: MAIL FROM: <Donal.OMahony@cs.tcd.ie> R: 250 OK S: RCPT TO:<President@aras.park.ie> R: 250 OK S: DATA R: 354 Start Mail input; end with <CRLF>.<CRLF> S: Date: 1 Apr 1996 S: to:... S: Blah Blah Blah S: S:. S: Extremely poor security - improved using S/MIME 5 SMTP Message Transfer Agents can be SMTP server and SMTP receiver Ingress put copy of mail for each recipient into an envelop Aims to pass directly to Mail Server hosting recipient account Uses DNS to resolve mail address to server IP address Can also pass to other s Relay : used when DNS resolution of recipient mailbox fails Mail Gateway : Use to convert SMTP mail format to mail conforming to a different standard, e.g. X.400, or to a completely different delivery mechanism, e.g. fax or voice Mail Proxy: Often present in an enterprise firewalls, checking for mail or other malicious or unallowed content and quarantining them 6 Page 3

4 More Complex Body Types In order to allow arbitrary mail attachments to be sent, the Multi-Purpose Internet Mail Extensions (MIME) were developed in RFCs 1341 and 1521 ( 93) Allows Typed message parts to be carried in basic RFC-822 message From:fred@go.com to:joan@there.net MIME-Version: 1.0 Content-Type: image/gid Content-Transfer-Encoding:base64 data for image 7 MIME Types 7 Basic Types + sub-types text - different character sets can be specified, directory image - subtypes gif/jpeg etc audio video application - e.g. to send Word Documents multipart - allows many mime attachments message - an entire Encoding many possible e.g. 7-bit, 8-bit, quoted-printable Base64 often used for arbitrary binary» encodes into 64 possible chars (2 6 ) none of which upset ers» 3 8-bit chars encoded as 4 base64 symbols 8 Page 4

5 Delivering and Picking Up Historically UNIX mailers dumped arriving messages into a file in a system-wide area e.g. /var/spool/mail/byrne lots of utilities to check, notify etc Message Pick-up Protocol - The Post Office Protocol (POP3) developed (RFC May 96) The POP3 Server listens on Port 110 for clients to pickup their E- mail Client e.g. Eudora/Outlook POP3 Server POP3 Commands USER name valid in the AUTHORIZATION PASS string QUIT STAT valid in the TRANSACTION LIST [msg] RETR msg DELE msg NOOP RSET QUIT 9 POP3 Operation OFFLINE Open AUTHORIZATION Server Locks mailbox Client sets up TCP conn on port 110. POP3 server returns greeting Client identifies & authenticates itself to server server locks Mailbox to prevent further modifications Fails (returns negative status indicator) Close UPDATE Client issues QUIT TRANSACTION Server or client closes the connection Downloaded files deleted from server Client end transactions using QUIT Maildrop download undertaken 10 Page 5

6 Remote Message Stores - IMAP POP3 downloads to local machine - hassle if user moves from one machine to another Internet Message Access Protocol (ver 4) issued as RFC in Dec 94 - Adoption began 1999/2000 Mail remains on the central server IMAP client contacts server on port 143 More sophisticated Protocol than POP3 mailboxes can be» created» searched» deleted Sophisticated Authentication capabilities Allows new messages to be downloaded, worked on offline and then a re-sync to take place 11 IMAP Operation LOGOUT Open Client sets up TCP conn on port 143. IMAP server returns greeting succeeds NON- AUTHENTICATED Client identifies & authenticates itself to server Client supplies Authentication details succeeds Fails (returns status indicator) terminated on Request of client or unilaterally By server SELECTED Mailbox can be accessed and manipulated succeeds Client must select mailbox Initially fails AUTHENTICATED 12 Page 6

7 Sample IMAP4 Session : * OK IMAP4 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 C: a003 fetch 12 full S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul :44: " RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul :23: (PDT)" "IMAP4 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 : C: a004 fetch 12 rfc822.header S: * 12 FETCH (RFC822.HEADER {346} S: Date: Wed, 14 Jul :23: (PDT) S: From: Terry Gray <gray@cac.washington.edu> S: Subject: IMAP4 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 C: a005 store 12 +flags \deleted S: * 12 FETCH (FLAGS (\Seen \Deleted)) S: a005 OK +FLAGS completed C: a006 logout S: * BYE IMAP4 server terminating connection S: a006 OK LOGOUT completed 13 Page 7