Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
5Activity
0 of .
Results for:
No results containing your search query
P. 1
SMTP simple mail transfer protocol

SMTP simple mail transfer protocol

Ratings: (0)|Views: 75|Likes:
Published by diwaker
SMTP(Simple Mail Transfer Protocol)
Diwaker singh
Roll-RB1803B54 Reg. No-10808015 Lovely Professional Univerity
Chhehru,Phagwara,Punjab Abstract— As it is clear from the name of the topic , the topic deals with SMTP i.e. Simple Mail Transfer Protocol, the protocol or set of rules governing the transmission of electronic mail across ip i.e. internet protocol networks.This is my attempt to provide all the information as a zest or summary. I have tried to explain each and every term associated with
SMTP(Simple Mail Transfer Protocol)
Diwaker singh
Roll-RB1803B54 Reg. No-10808015 Lovely Professional Univerity
Chhehru,Phagwara,Punjab Abstract— As it is clear from the name of the topic , the topic deals with SMTP i.e. Simple Mail Transfer Protocol, the protocol or set of rules governing the transmission of electronic mail across ip i.e. internet protocol networks.This is my attempt to provide all the information as a zest or summary. I have tried to explain each and every term associated with

More info:

Published by: diwaker on May 26, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

04/17/2011

pdf

text

original

 
SMTP(Simple Mail Transfer Protocol)
Diwaker singh
 Roll-RB1803B54 Reg. No-10808015Lovely Professional Univerity
Chhehru,Phagwara,Punjab
 Abstract 
 — As it is clear from the name of the topic , the topic deals withSMTP i.e. Simple Mail Transfer Protocol, the protocol or set of rules governing the transmission of electronic mail across ip i.e.internet protocol networks.This is my attempt to provide all theinformation as a zest or summary. I have tried to explain eachand every term associated with Simple mail Transfer Protocol asfar as possible. I hope that the reader will be able to know thefundamentals of Simple Mail Transfer Protocol after reading thisdocument.
I.I
 NTRODUCTION
This document gives all the information related to theservices provided by Simple Mail Transfer Protocol for transmission of electronic mail across networks and and itsimplementation in IP (Internet protocol). It also deals aboutthe extensions of SMTP and its detailed analysis.II.E
MAIL
(E
LECTRONIC
 
MAIL
)Before starting the discussion about Simple Mail Transfer Protocol we should have basic knowledge about an electronicmail i. e. what is an electronic mail, what does it carry andhow is it sent from one computer to another computer.Moreover sending electronic mail using Simple Mail Transfer Protocol will be of our prime concern.Electronic mail, or e-mail, as it is known to its many fans, has been around for over two decades. Before 1990, it was mostlyused in academia. During the 1990s, it became known to the public at large and grew exponentially to the point where thenumber of e-mails sent per day now is vastly more than thenumber of snail mail (i.e., paper) letters.E-mail, like most other forms of communication, has its ownconventions and styles. In particular, it is very informal andhas a low threshold of use. People who would never dream of calling up or even writing a letter to a Very Important Persondo
 
not hesitate for a second to send a sloppily-written e-mail.The first e-mail systems simply consisted of file transfer  protocols, with the convention that the first line of eachmessage (i.e., file) contained the recipient's address. As timewent on, the limitations of this approach became moreobvious.Some of the complaints were as follows:1.Sending a message to a group of people wasinconvenient. Managers often need this facility tosend memos to all their subordinates.2.Messages had no internal structure, making compute processing difficult. For example, if a forwardedmessage was included in the body of another message, extracting the forwarded part from thereceived message was difficult.3.The originator (sender) never knew if a messagearrived or not.4.If someone was planning to be away on business for several weeks and wanted all incoming e-mail to behandled by his secretary, this was not easy toarrange.5.The user interface was poorly integrated with thetransmission system requiring users first to edit a file,then leave the editor and invoke the file transfer  program.6.It was not possible to create and send messagescontaining a mixture of text, drawings, facsimile, andvoice.As experience was gained, more elaborate e-mail systemswere proposed. In 1982, the ARPANET e-mail proposals were published as RFC 821 (transmission protocol) and RFC 822(message format). Minor revisions, RFC 2821 and RFC 2822,have become Internet standards, but everyone still refers toInternet e-mail as RFC 822.In 1984, CCITT drafted its X.400 recommendation. After twodecades of competition, e-mail systems based on RFC 822 arewidely used, whereas those based on X.400 have disappeared.How a system hacked together by a handful of computer science graduate students beat an official internationalstandard strongly backed by all the PTTs in the world, manygovernments, and a substantial part of the computer industry brings to mind the Biblical story of David and Goliath.
 
The reason for RFC 822's success is not that it is so good, butthat X.400 was so poorly designed and so complex thatnobody could implement it well. Given a choice between asimple-minded, but working, RFC 822-based e-mail systemand a supposedly truly wonderful, but nonworking, X.400 e-mail system, most organizations chose the former. Perhapsthere is a lesson lurking in there somewhere. Consequently,our discussion of e-mail will focus on the Internet e-mailsystem.III.A
RCHITECTURE
 
AND
 
SERVICES
 
PROVIDED
 
BY
E
LECTRONIC
 
MAILS
In this section we will provide an overview of what e-mailsystems can do and how they are organized. They normallyconsist of two subsystems: the user agents, which allow people to read and send e-mail, and the message transfer agents, which move the messages from the source to thedestination. The user agents are local programs that provide acommand-based, menu-based, or graphical method for interacting with the e-mail system. The message transfer agents are typically system daemons, that is, processes thatrun in the background. Their job is to move e-mail through thesystem.Typically, e-mail systems support five basic functions. Let ustake a look at them.
Composition
refers to the process of creating messages andanswers. Although any text editor can be used for the body of the message, the system itself can provide assistance withaddressing and the numerous header fields attached to eachmessage. For example, when answering a message, the e-mailsystem can extract the originator's address from the incominge-mail and automatically insert it into the proper place in thereply.
Transfer
refers to moving messages from the originator to therecipient. In large part, this requires establishing a connectionto the destination or some intermediate machine, outputtingthe message, and releasing the connection. The e-mail systemshould do this automatically, without bothering the user.
Reporting
has to do with telling the originator what happenedto the message. Was it delivered? Was it rejected? Was it lost? Numerous applications exist in which confirmation of delivery is important and may even have legal significance(''Well, Your Honor, my e-mail system is not very reliable, soI guess the electronic subpoena just got lost somewhere'').
Displaying
incoming messages is needed so people can readtheir e-mail. Sometimes conversion is
 
required or a specialviewer must be invoked, for example, if the message is aPostScript file or digitized voice. Simple conversions andformatting are sometimes attempted as well.
Disposition
is the final step and concerns what the recipientdoes with the message after receiving it. Possibilities includethrowing it away before reading, throwing it away after reading, saving it, and so on. It should also be possible toretrieve and reread saved messages, forward them, or processthem in other ways.In addition to these basic services, some e-mail systems,especially internal corporate ones, provide a variety of advanced features. Let us just briefly mention a few of these.When people move or when they are away for some period of time, they may want their e-mail forwarded, so the systemshould be able to do this automatically.A key idea in e-mail systems is the distinction between theenvelope and its contents. The envelope encapsulates themessage. It contains all the information needed for transporting the message, such as the destination address, priority, and security level, all of which are distinct from themessage itself. The message transport agents use the envelopefor routing, just as the post office does.The message inside the envelope consists of two parts: theheader and the body. The header contains control informationfor the user agents. The body is entirely for the humanrecipient. Envelopes and messages are illustrated in followingFig.Fig.1.-Envelopes and messages. (a) Paper mail. (b) Electronicmail.IV. RFC882Messages consist of a primitive envelope, some number of header fields, a blank line, and then the message body. Each
 
header field (logically) consists of a single line of ASCII textcontaining the field name, a colon, and, for most fields, avalue. RFC 822 was designed decades ago and does notclearly distinguish the envelope fields from the header fields.Although it was revised in RFC 2822, completely redoing itwas not possible due to its widespread usage. In normal usage,the user agent builds a message and passes it to the messagetransfer agent, which then uses some of the header fields toconstruct the actual envelope, a somewhat old-fashionedmixing of message and envelope.The principal header fields related to message transport arelisted in fig 2. The
To:
field gives the DNS address of the primary recipient. Having multiple recipients is also allowed.The
Cc:
field gives the addresses of any secondary recipients.In terms of delivery, there is no distinction between the primary and secondary recipients. It is entirely a psychological difference that may be important to the peopleinvolved but is not important to the mail system. The term
Cc:
(Carbon copy) is a bit dated, since computers do not usecarbon paper, but it is well established. The
Bcc:
(Blindcarbon copy) field is like the
Cc:
field, except that this line isdeleted from all the copies sent to the primary and secondaryrecipients. This feature allows people to send copies to third parties without the primary and secondary recipients knowingthis.Fig.2.-RFC 822 header fields related to message transport.The next two fields,
From:
and
Sender:
tell who wrote andsent the message, respectively. These need not be the same.For example, a business executive may write a message, buther secretary may be the one who actually transmits it. In thiscase, the executive would be listed in the
From:
field and thesecretary in the Sender: field. The
From:
field is required, butthe Sender: field may be omitted if it is the same as the From:field. These fields are needed in case the message isundeliverable and must be returned to the sender 
.
A line containing
Received:
is added by each messagetransfer agent along the way. The line contains the agent'sidentity, the date and time the message was received, andother information that can be used for finding bugs in therouting system.
The Return-Path:
field is added by the final message transfer agent and was intended to tell how to get back to the sender.In theory, this information can be gathered from all theReceived: headers (except for the name of the sender'smailbox), but it is rarely filled in as such and typically justcontains the sender's address.In addition to the fields of Fig.2 RFC 822 messages may alsocontain a variety of header fields used by the user agents or human recipients. The most common ones are listed in Fig.3.Most of these are self-explanatory, so we will not go into allof them in detail.Fig.3.-
 
Some fields used in the RFC 822 message header.This was an overview of an electronic mail. Now we come toour main topic I. e. Simple Mail Transfer Protocol.V. S
IMPLE
M
AIL
T
RANSFER 
P
ROTOCOL
SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most casesverified to exist) and then the message text is transferred. It isa client-server protocol, where the client transmits an emailmessage to the server. Either an end-user's email client, a.k.a.MUA (Mail User Agent), or a relaying server's MTA (MailTransfer Agents) can act as an SMTP client.An email client knows the outgoing mail SMTP server fromits configuration. A relaying server typically determines whichSMTP server to connect to by looking up the MX (MaileXchange) DNS record for each recipient's domain name, the part of the email address to the right of the at sign (@).Conformant MTAs (not all) fall back to a simple A record inthe case of no MX. Some current mail transfer agents will alsouse SRV records, a more general form of MX, though theseare not widely adopted. (Relaying servers can also beconfigured to use a smart host.)The SMTP client initiates a TCP connection to server's port25(unless overridden by configuration.) It is quite easy to test an

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->