Note for ECE 478 at UA
Popular in Course
Popular in Department
This 3 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at University of Arizona taught by a professor in Fall. Since its upload, it has received 11 views.
Reviews for Note for ECE 478 at UA
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 02/06/15
PD4E9p1p1 Update for Message Transfer section pp 646648 Next we look at SMTP 7 the protocol used to transfer messages from one host to another SMTP is best understood by a simple example The following is an exchange between sending host csprincetonedu and receiving host ciscocom continue with last paragraph on p 647 example and p648 with the following corrections 0 The colors in the example didn t print Instead print C at start of client lines and S at start of server lines 0 Mail gateway in second to last paragraph should be mail relay quotGatewayquot has a special meaning in email as a relay at the boundary between two dissimilar nonSMTP networks Kle08 CroOS Modern mail handling systems are much more complex than just two hosts A typical system has a network of SMTP Relaysl each performing a specialized function temporarily storing the message then passing it on using SMTP You can tell how many Relays handled a message by looking at the Received lines in the header There should be one for each Relay Attempts to model real systems at the Relay level result in diagrams of unmanageable complexity Fa104 We can construct a simpler model if we focus on Actors Users and Agents CroOS Figure 91 shows a typical system with the Relays grouped into functional blocks In this diagram we have named the blocks by the role they play in processing a message Each Actor can have multiple blocks each block can have multiple hosts and each host can have multiple Relays running as independent daemon processes A Transmitter might have a dozen Relays operating in parallel to handle a large mail ow An MDA might have a process dedicated to managing a large mailstore another running a POPIMAP server and another providing a webmail interface Mail Mail Storage amp Submission Delivery Agent Agent Internet M S A E M DA Mailstore POP HTTP SMTP IMAP Client Transmitter Receiver Client Browser Author Recipient Figure 91 Actors Users and Agents and their roles in a typical email system To understand a mail handling system including its security vulnerabilities we need to understand the roles and responsibilities of each Actor and the relationships between them Figure 91 is a simpli ed model of just one system There are many other possibilities We might add a Forwarder between the Receiver and the MDA or an Open Relay oating in the cloud We might have more than one role played by each Actor We might add another layer of 1 Don39t confuse SMTP Relays with routers or packet switches Relays use SMTPTCPIP and the functionality of routers is entirely encapsulated within the lower layers of this protocol stack We can ignore routers They are quottransparentquot to SMTP PD4E9p lpldoc 13 David MacQuigg 7172010 organization showing a group of Actors organized as an MRN Mail Receiving Network MooOS or an ADMD Administrative Management Domain CroOS A diagram like Figure 91 could get quite complex A shorthand notation Mac08 will allow us to show the relevant networks actors roles and relationships Here is a basic system with four Actors two Users and two Agents organized as two networks l Sender39s Network l l Recipient39s Network l Author gt MSATransmitter gt gt ReceiverMDA gt Recipient Border The double arrow shows a direct relationship between Actors eg a contract between the Author and his ISP The single arrow shows only the direction of mail ow There is no relationship between Agents across the Border to the open Internet The shows multiple roles being played by one Actor Using these diagrams we can model almost any system and include a lot of detail on relationships but not lose the simplicity of Figure 91 The elements of the model Actor s roles are the fundamental building blocks Here is an eXtension of the basic system adding a Forwarder role played by the same Actor as the Receiver Both the ReceiverForwarder and the MDA have a direct relationship with the Recipient so they have an indirect relationship with each other These details are important in discussions of authentication protocols l Recipient39s Network l gt gt ReceiverForwarder gt MDA gt Recipient Border If we wonder why email continues to be such an insecure system we can study this last example Authentication protocols which try to correlate the Transmitter s domain name to the connecting IP address can fail when a Forwarder is involved We cannot just dismiss Forwarding as an quotedge casequot however It is important for a user who changes jobs or ESPs Email Service Providers and would like to continue receiving mail at his old address Let s follow a message from start to nish The scenario begins with an Author composing a message using his mail client There are countless mail clients available just like there are many web browsers to choose from In fact most web browsers now include a mail client or at least a mechanism to invoke the user s preferred client when he clicks a mailto link in a webpage When the Author clicks SEND his mail client connects to an MSA at his ESP and the message is transferred using SMTP A key responsibility of the MSA is to authenticate the Author This can be done with a password by assigning the client a static IP address or by having the client on the MSA s local network not directly connected to the Internet Most large ESPs operate their own transmitter Relays but many smaller ISPs and organizations with a lot of bulk mail subcontract this specialized role to another Agent The Transmitter s responsibilities include prevention of outgoing spam and providing some means to prove their identity to unrelated Receivers It isn t enough to say quotHELO this is trustmecomquot Any spammer can do that The Transmitter must provide some quotoutofbandquot data using a service like DNS that is more trusted than email Both parties must use the same authentication method There is no standard authentication method and that is a problem with SMTP A fundamental goal of email is reliable communication with no prior relationship between sender and receiver Email authentication methods fall into two categories Methods like SPF SenderID and CSV rely on the fact that certain IP addresses are rmly under the control of a sender an individual or PD4E9p 1p 1 doc 23 David MacQuigg 7172010 organization identi ed by its domain name Methods like DKIM rely on a digital signature applied to the entire message and most of its headers Both depend on the security of DNS Only the domain owner has access to the DNS records under his name With IPbased methods the sender publishes in DNS the IP addresses authorized to use his domain name With signature based methods the sender publishes a public key IP methods can be very ef cient rejecting an entire session without transferring any messages Endtoend signature methods can be very secure even with an untrusted Forwarder in the middle The Receiver s responsibilities include a number of functions we might call quotBorder defensequot 7 blocking a DoS attack authenticating the sender and various spamblocking strategies including whitelisting blacklisting statistical analysis of message content and use of heuristic rulesets that have proven effective in separating spam from legitimate mail Border defense should be done at the Border Loss of mail due to violations of this principle is common A forwarded message can look like a forgery and then the MDA has a tough choice 7 drop the message with no notice to the alleged sender or send the notice and risk being reported for quotbounce spamquot The problems with miscon gured mailsystems can be avoided if all Actors understand how the system works When a Recipient sets up forwarding from his old ReceiverForwarder to his new MDA he should make sure that the Forwarder is whitelisted by the MDA Forwarders should make sure that Recipients unsophisticated users understand this MDAs should understand that forwarding is a common need and make it easy for Recipients to whitelist at the domain level Simple models will help reduce the confusion References Kle08 J Klensin ed quotSimple Mail Transfer Protocolquot RFC5321 2008 httptoolsietforghtmrfc5321 FaIO4 P Faltstrom mailflows04 Jan 6 2004 httpwwwripenetripemeetinqsripe 47mailflowspdf Cr008 D Crocker quotInternet Mail Architecturequot 2008 httptoolsietforghtmdraft crockeremaiIarch10 M0005 K Moore quotRecommendations for Submission of Email and Relaying of Email Between Mail Networksquot 2005 httpwwwcsutkedumooreopinionsemai submissionrecommendationshtm Mac08 D MacQuigg quotModels for Mail Handling Systemsquot 2008 httpopen mailorgMHSmodelshtm PD4E9p 1p 1 doc 33 David MacQuigg 7172010