TODO r SMTP POP IMAP NNTP FTP RTP
- Slides: 38
TODO r SMTP, POP, IMAP, NNTP, FTP, RTP maybe r Telnet examples r spam 2: Application Layer 1
Electronic Mail outgoing message queue user mailbox user agent Three major components: r user agents r mail servers mail server r simple mail transfer SMTP protocol: smtp User Agent r a. k. a. “mail reader” r composing, editing, reading mail messages r e. g. , Eudora, Outlook, elm, Netscape Messenger r outgoing, incoming messages stored on server SMTP mail server user agent SMTP user agent mail server user agent 2: Application Layer 2
Electronic Mail: mail servers Mail Servers r mailbox contains incoming messages (yet to be read) for user r message queue of outgoing (to be sent) mail messages (if message cannot be delivered will stay in queue) r smtp protocol between mail servers to send email messages m Mail server is an SMTP client when sending mail m Mail server is an SMTP server” when receiving mail user agent mail server SMTP mail server user agent SMTP user agent mail server user agent 2: Application Layer 3
Electronic Mail: smtp [RFC 821] r Uses tcp to reliably transfer email msg from client to server, port 25 r direct transfer: sending server to receiving server r three phases of transfer m handshaking (greeting) m transfer of messages m closure r command/response interaction m commands: ASCII text m response: status code and phrase 2: Application Layer 4
SMTP History r SMTP has been around a long time m RFC done in 1982 m In use well before that r Messages must be in 7 -bit ASCII (made sense in text-based early days) r Requires encoding for binary data (jpegs, etc. ) in 7 -bit ASCII (yuck!) 2: Application Layer 5
try smtp interaction for yourself: r telnet servername 25 r see 220 reply from server r enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send email without using email client (reader) Trace it – does your mail data go in the clear? 2: Application Layer 6
Sample smtp interaction S: C: S: C: C: C: S: 220 hamburger. edu HELO crepes. fr 250 Hello crepes. fr, pleased to meet you MAIL FROM: <alice@crepes. fr> 250 alice@crepes. fr. . . Sender ok RCPT TO: <bob@hamburger. edu> 250 bob@hamburger. edu. . . Recipient ok DATA 354 Enter mail, end with ". " on a line by itself Do you like ketchup? How about pickles? . 250 Message accepted for delivery QUIT 221 hamburger. edu closing connection 2: Application Layer 7
What is missing? r Some commands processed by SMTP protocol mirror mail headers we are used to seeing in our email messages (To, From, …), but are not the same things r Email headers (To, From, CC, Subject, Date, . . ) are considered part of the data by SMTP and are not processed SMTP server at all! r Email headers are processed by the mail reader software r Example of protocol layering 2: Application Layer 8
Mail message format smtp: protocol for exchanging email msgs RFC 822: standard for text message format (format of data from smtp perspective) r header lines, e. g. , To: m CC: m Subject: different from SMTP commands! SMTP Data Message headers blank line Message body m r body m the “message”, ASCII characters only 2: Application Layer 9
Sample smtp interaction S: 220 hamburger. edu C: HELO crepes. fr S: 250 Hello crepes. fr, pleased to meet you C: MAIL FROM: <alice@crepes. fr> S: 250 alice@crepes. fr. . . Sender ok C: RCPT TO: <bob@hamburger. edu> S: 250 bob@hamburger. edu. . . Recipient ok C: DATA S: 354 Enter mail, end with ". " on a line by itself C: To: bob@hamburger. edu C: Subject: dinner preferences C: From: alice@crepes. fr C: C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger. edu closing connection 2: Application Layer 10
Spam/forged mail r “Received: ” and “Message. ID” headers are part of the data m Accurate and helpful from legitimate servers and user agents r Start with a legitimate server you trust m Don’t relay messages from a site outside your domain to another host outside your domain m Verify the Mail From field (resolvable domain and matching IP address) m Refuse traffic from known spammers 2: Application Layer 11
Tracking and Reporting Spam r Record IP address of sender and time and date of message transfer r Spamcop uses a combination of tools like dig, nslookup and finger to cross-check all the information in an email header and find the email address of the system administrator responsible for the network from which the mail was sent r postmaster@domain or abuse@domain 2: Application Layer 12
What about sending pictures and other binary data? r Don’t try this by hand r MIME: multimedia mail extension, RFC 2045, 2056 r additional lines in msg header declare MIME content type MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data 2: Application Layer 13
MIME types: Extensible Content-Type: type/subtype; parameters Text r example subtypes: plain, html Image r example subtypes: jpeg, gif Audio r exampe subtypes: basic (8 -bit mu-law encoded), 32 kadpcm (32 kbps coding) Video r example subtypes: mpeg, quicktime Application r other data that must be processed by reader before “viewable” r example subtypes: msword, octet-stream 2: Application Layer 14
Multipart Type From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --98766789 -- 2: Application Layer 15
Email viruses r Often attachments which once opened run with the users full privileges and corrupt the system on which mail is read r Viruses tend to target Windows as it is the platform used by the majority of people 2: Application Layer 16
smtp: final words r smtp uses persistent connections r smtp requires that message (header & body) be in 7 -bit ascii r certain character strings are not permitted in message (e. g. , CRLF). Thus message has to be encoded (usually into either base-64 or quoted printable) r smtp server uses CRLF to determine end of message Comparison with http r http: pull r email: push r both have ASCII command/response interaction, status codes r http: each object is encapsulated in its own response message r smtp: multiple objects message sent in a multipart message 2: Application Layer 17
Other Mail access protocols? user agent SMTP sender’s mail server POP 3 or IMAP user agent receiver’s mail server r SMTP: delivery/storage to receiver’s server r Mail access protocol: retrieval from server m People used to always log onto server to read mail, now read from their own PC. m Why not just SMTP server on local machine? Push not pull means your PC must be constantly on to accept “push” m Others? 2: Application Layer 18
Pull-style Mail access Protocols r POP: Post Office Protocol [RFC 1939] authorization (agent <-->server) and download r IMAP: Internet Mail Access Protocol [RFC 1730] more features (more complex) manipulation of stored msgs on server r HTTP: Hotmail , Yahoo! Mail, etc. m Somebody asked about using HTTP to transfer random things? m Convenient – don’t need mail reader just the ubiquitous web browser 2: Application Layer 19
POP 3 protocol authorization phase r client commands: user: declare username m pass: password r server responses m +OK m -ERR m transaction phase, client: r list: list message numbers r retr: retrieve message by number r dele: delete r Quit S: C: S: +OK POP 3 server ready user alice +OK pass hungry +OK user successfully logged C: S: S: S: C: C: S: list 1 498 2 912. retr 1 <message 1 contents>. dele 1 retr 2 <message 1 contents>. dele 2 quit +OK POP 3 server signing off 2: Application Layer 20 on
try POP interaction for yourself: r telnet servername 110 r see “OK POP 3 server ready” reply from server r enter user, pass, list, retr, dele commands above lets you send get you own email without using email client (reader) Trace it – do your password and mail data go in the clear? 2: Application Layer 21
IMAP r Allows user to set up and maintain multiple folders (for sorting mail) on the remote server r Can get headers for and manipulate messages without downloading them m Don’t leave them on insecure computers m Don’t pay cost to download over slow link r Must store per user information across sessions = stateful protocol m Folder information, actual messages m Seen, Deleted, Answered flags per message 2: Application Layer 22
IMAP con’t r During an IMAP connection, the server transitions between multiple states m Initially non-authenticated m Authenticated (once username/password provided) m Selected – folder selected and operations on messages permitted m Finally, Logout state 2: Application Layer 23
Pop vs IMAP r Similarities m Mail delivered to a shared, constanly connected server m New mail accessible anywhere in network on a variety of platforms m For access only, Need SMTP to send mail r Differences m POP simpler and more established (more clients and servers that support it) m IMAP is stateful protocol with more features 2: Application Layer 24
NNTP r Network News Transfer Protocol r Jeff Vinocur here 2: Application Layer 25
ftp: the file transfer protocol user at host FTP user client interface file transfer local file system FTP server remote file system r transfer file to/from remote host r client/server model client: side that initiates transfer (either to/from remote) m server: remote host r ftp: RFC 959 r ftp server: port 21 m 2: Application Layer 26
ftp: separate control, data connections r ftp client contacts ftp server at port 21, specifying TCP as transport protocol r two parallel TCP connections opened (both full duplex): m control: exchange commands, responses between client, server. “out of band control” m data: file data to/from server, can be used in either direction, need not always exist r ftp server maintains “state”: current directory, earlier authentication TCP control connection port 21 FTP client TCP data connection port 20 FTP server 2: Application Layer 27
ftp commands, responses Sample commands: r sent as ASCII text over control channel r USER username r PASS password (sent in clear text!) r LIST return list of file in Sample return codes r status code and phrase (as r r current directory r RETR filename retrieves r r STOR filename stores r (gets) file (puts) file onto remote host in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file 2: Application Layer 28
FTP Connection r Client connects to port 21 on server; this r r established the control channel Over the control channel, the client specifies the characteristics including IP address and port number for data connection (note: needn’t be on the same machine as the client ) Can ask server to set up a passive connection for the data port as well (good for getting around firewalls) Server tries to connect to data port as specified by client Once established data connection can be used in both directions 2: Application Layer 29
FTP Model Ftp client FTP server User Interface Server Protocol Interpreter User Protocol Interpreter Server Data Transfer Process File System FTP Commands/ Replies Data Connection User Data Transfer Process File System 2: Application Layer 30
Multimedia Applications r Audio/video conferencing, streaming audio, etc. m On-demand (streaming): one way transfer, then playback; usually broadcast from one source like TV or radio; start-up time and RTT not very important m Conferencing: interactive, start-up time and RTT matter alot r Examples: vic, (video conferencing), vat (audio conferencing), Real. Audio (streaming audio) 2: Application Layer 31
Requirements of multimedia r Several methods for compressing and encoding voice/video; sender and receiver negotiate r Ability to specify the timing requirements between packets of related data (smooth playback); frame boundary indication r Synchronization of related audio and video streams r Ability to display stream (at degraded quality) with lost packets 2: Application Layer 32
Real-time Transport Protocol (RTP) r TCP overhead to high; UDP not good enough r Initially, each application had its own protocol, implementing only those parts of TCP it really needed on top of UDP r RTP offers generalized real time transport services m Thin protocol; Runs on top of UDP m Implements functionality commonly needed by multimedia applications - timing reconstruction, loss detection, security and content identification 2: Application Layer 33
RTCP and RTSP r RTCP (Real Time Control Protocol) m Real-time conferencing of groups of any size within an internet. m Provides source identification, quality-of-service feedback from receivers to the multicast group, synchronization of different media streams r RTSP (Real-time Streaming Protocol) m Industry consortium announced in 1996 – since then? m Proprietary versions: Real Network’s (orginally Progressive Networks) Real. Media, Real. Audio and Real. Player , Quicktime, Windows. Media? ? ? 2: Application Layer 34
Realtime Transport (? ) Protocol r Is this an application level protocol or a transport protocol? m Done at application level m If TCP implemented at application level (like we will do), does that make it an application level protocol or a transport level protocol? r Where is the right place to put these features? 2: Application Layer 35
Real. Network’s Real. Server r Uses 2 channels (like FTP) to client – one control channel(TCP) and one data channel (UDP) r Control channel handles authentication (passwords) and actions like fast forward, pause and stop r Uses 2 main protocols: RTSP and PNA (Progressive Networks Audio) r Modes: streaming, live or simulated live (no fast forward/rewind) 2: Application Layer 36
More Application Level Protocols? r Telnet, Rlogin, SNMP (Simple Network Management Protocol), Instant Messenger (AIM), DHCP (BOOTP) , RPC, NFS, X, Finger, Whois, IDENT…………………. . r You now know how to investigate any of these on your own m RFCs for open protocols, Run apps and trace them, Get client/server source, … r It would be a lot more fun to learn more than application level protocols though, right? 2: Application Layer 37
Roadmap r We’ve looked at a bunch of application level protocols (HTTP, DNS, SMTP, POP, IMAP, NNTP, RTP, . . ) – Lessons? m m m Many were human readable – why? High level examples of protocol layering (SMTP, HTTP) Some ran on TCP, some on UDP, one on both – why? Used telnet/nslookup to interact with these protocols more directly Traced them (What went in clear text? !) r Next. . How would we implement an application level protocol ourselves? m Socket API r After that down to transport layer 2: Application Layer 38
- Protocolo nntp
- Ftp and smtp
- Ftp://ftp.ufv.br/dbg/biodata/
- Wildland fire ftp
- Todo tiene su tiempo y todo lo que se quiere
- Todo lo que pasa es relativo
- Que es eso que anda todo el dia y nunca sale de su sitio
- What does the pop in pop art stand for?
- Scalable imap
- Lern saxx
- Imap quota
- Hispeed imap einstellungen
- Atlas mail nastavení imap
- Imap terra outlook 2016
- Www.webmail.com correo
- Akomail
- Imap diagram
- Annette logineo
- Imap hku
- Http response format
- Rtp 76
- Rtp packet format
- A transport protocol for real time applications
- Ts over ip
- Csulb calendar
- Picture framing rtp
- Rtp 42mwiggersventurebeat
- Rtp
- Protocolo rtp
- Rtp
- Rtp crystal
- Rtp uses a temporary even-numbered
- Rtp
- Rtp midi
- Retreat at rtp
- Rtp
- Rtptools
- Rtp multiplexing
- Rtp