Solved

E-mail, How does it work?

Posted on 2000-02-16
8
239 Views
Last Modified: 2010-04-26
How does e-mail work and how does it get from one computer to another?
0
Comment
Question by:Mike149
  • 4
  • 3
8 Comments
 
LVL 3

Accepted Solution

by:
BudVVeezer earned 100 total points
ID: 2529655
It works like this: ((answer coming in a second))

~Aaron
0
 
LVL 3

Expert Comment

by:BudVVeezer
ID: 2529663
The reason I answered it is because I've been robbed from typing too much before.  Here's how it works.  =)

You write up an email message on your computer, and when you send it, it gets sent through a server.  It could be a server at work, or a server through an ISP(internet service provider) like AOL.  The server take a look at the address of the message(the part after the @) and it transfers it via a hard line(telephone) to that address's server.  From that server, it takes the part before the @ symbol and finds the specific mailbox to place the message in.  When you log in to your email server(like AOL, or Eudora, etc), and you ask it to give you your new messages, it queries the server for all the messages for you(the part before the @) and allows you to read them remotely.  If you have any more questions, feel free to ask!

~Aaron
0
 
LVL 84

Expert Comment

by:ozo
ID: 2529768
RFC1123
0
 
LVL 3

Expert Comment

by:BudVVeezer
ID: 2529884
Hey ozo, ya lost me with that comment...mind explaining?  Thx!

~Aaron
0
Scale it in WD Gold

With up to ten times the workload capacity of desktop drives, WD Gold hard drives employ advanced technology to deliver among the best in reliability, capacity, power efficiency and performance.

 
LVL 12

Expert Comment

by:mark2150
ID: 2533526
RFC1123 is the IETF (Internet Engineering Task Force) document that define internet email protocol.

M
0
 
LVL 3

Expert Comment

by:BudVVeezer
ID: 2533554
ah, i get it.  Learn something new every day...I just went at it from a simple point of view(I hope)...  ;-)

~Aaron
0
 
LVL 12

Expert Comment

by:mark2150
ID: 2533576
There are hundreds of RFC's (Request For Comment's) that apply to most every aspect of the internet. Some are adopted/ratified and become defacto standards since the IETF has no legislative or enforcement authority. If you go to Yahoo and search on RFC1123 you should find exactly what you're looking for.

M
0
 
LVL 12

Expert Comment

by:mark2150
ID: 2533580
Ask and ye shall receive:

This is the first eight pages or so from RFC1123. I'd have posted more but E-E would only accept this much...

The source link is:

http://www.normos.org/ietf/rfc/rfc1123.txt

M


Network Working Group                    Internet Engineering Task Force
Request for Comments: 1123                             R. Braden, Editor
                                                            October 1989


       Requirements for Internet Hosts -- Application and Support

Status of This Memo

   This RFC is an official specification for the Internet community.  It
   incorporates by reference, amends, corrects, and supplements the
   primary protocol standards documents relating to hosts.  Distribution
   of this document is unlimited.

Summary

   This RFC is one of a pair that defines and discusses the requirements
   for Internet host software.  This RFC covers the application and
   support protocols; its companion RFC-1122 covers the communication
   protocol layers: link layer, IP layer, and transport layer.



                           Table of Contents




   1.  INTRODUCTION ...............................................    5
      1.1  The Internet Architecture ..............................    6
      1.2  General Considerations .................................    6
         1.2.1  Continuing Internet Evolution .....................    6
         1.2.2  Robustness Principle ..............................    7
         1.2.3  Error Logging .....................................    8
         1.2.4  Configuration .....................................    8
      1.3  Reading this Document ..................................   10
         1.3.1  Organization ......................................   10
         1.3.2  Requirements ......................................   10
         1.3.3  Terminology .......................................   11
      1.4  Acknowledgments ........................................   12

   2.  GENERAL ISSUES .............................................   13
      2.1  Host Names and Numbers .................................   13
      2.2  Using Domain Name Service ..............................   13
      2.3  Applications on Multihomed hosts .......................   14
      2.4  Type-of-Service ........................................   14
      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15




Internet Engineering Task Force                                 [Page 1]




RFC1123                       INTRODUCTION                  October 1989


   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
      3.1  INTRODUCTION ...........................................   16
      3.2  PROTOCOL WALK-THROUGH ..................................   16
         3.2.1  Option Negotiation ................................   16
         3.2.2  Telnet Go-Ahead Function ..........................   16
         3.2.3  Control Functions .................................   17
         3.2.4  Telnet "Synch" Signal .............................   18
         3.2.5  NVT Printer and Keyboard ..........................   19
         3.2.6  Telnet Command Structure ..........................   20
         3.2.7  Telnet Binary Option ..............................   20
         3.2.8  Telnet Terminal-Type Option .......................   20
      3.3  SPECIFIC ISSUES ........................................   21
         3.3.1  Telnet End-of-Line Convention .....................   21
         3.3.2  Data Entry Terminals ..............................   23
         3.3.3  Option Requirements ...............................   24
         3.3.4  Option Initiation .................................   24
         3.3.5  Telnet Linemode Option ............................   25
      3.4  TELNET/USER INTERFACE ..................................   25
         3.4.1  Character Set Transparency ........................   25
         3.4.2  Telnet Commands ...................................   26
         3.4.3  TCP Connection Errors .............................   26
         3.4.4  Non-Default Telnet Contact Port ...................   26
         3.4.5  Flushing Output ...................................   26
      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27

   4.  FILE TRANSFER ..............................................   29
      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
         4.1.1  INTRODUCTION ......................................   29
         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
            4.1.2.1  LOCAL Type ...................................   29
            4.1.2.2  Telnet Format Control ........................   30
            4.1.2.3  Page Structure ...............................   30
            4.1.2.4  Data Structure Transformations ...............   30
            4.1.2.5  Data Connection Management ...................   31
            4.1.2.6  PASV Command .................................   31
            4.1.2.7  LIST and NLST Commands .......................   31
            4.1.2.8  SITE Command .................................   32
            4.1.2.9  STOU Command .................................   32
            4.1.2.10  Telnet End-of-line Code .....................   32
            4.1.2.11  FTP Replies .................................   33
            4.1.2.12  Connections .................................   34
            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
         4.1.3  SPECIFIC ISSUES ...................................   35
            4.1.3.1  Non-standard Command Verbs ...................   35
            4.1.3.2  Idle Timeout .................................   36
            4.1.3.3  Concurrency of Data and Control ..............   36
            4.1.3.4  FTP Restart Mechanism ........................   36
         4.1.4  FTP/USER INTERFACE ................................   39



Internet Engineering Task Force                                 [Page 2]




RFC1123                       INTRODUCTION                  October 1989


            4.1.4.1  Pathname Specification .......................   39
            4.1.4.2  "QUOTE" Command ..............................   40
            4.1.4.3  Displaying Replies to User ...................   40
            4.1.4.4  Maintaining Synchronization ..................   40
         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
         4.2.1  INTRODUCTION ......................................   44
         4.2.2  PROTOCOL WALK-THROUGH .............................   44
            4.2.2.1  Transfer Modes ...............................   44
            4.2.2.2  UDP Header ...................................   44
         4.2.3  SPECIFIC ISSUES ...................................   44
            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
            4.2.3.2  Timeout Algorithms ...........................   46
            4.2.3.3  Extensions ...................................   46
            4.2.3.4  Access Control ...............................   46
            4.2.3.5  Broadcast Request ............................   46
         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47

   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
      5.1  INTRODUCTION ...........................................   48
      5.2  PROTOCOL WALK-THROUGH ..................................   48
         5.2.1  The SMTP Model ....................................   48
         5.2.2  Canonicalization ..................................   49
         5.2.3  VRFY and EXPN Commands ............................   50
         5.2.4  SEND, SOML, and SAML Commands .....................   50
         5.2.5  HELO Command ......................................   50
         5.2.6  Mail Relay ........................................   51
         5.2.7  RCPT Command ......................................   52
         5.2.8  DATA Command ......................................   53
         5.2.9  Command Syntax ....................................   54
         5.2.10  SMTP Replies .....................................   54
         5.2.11  Transparency .....................................   55
         5.2.12  WKS Use in MX Processing .........................   55
         5.2.13  RFC-822 Message Specification ....................   55
         5.2.14  RFC-822 Date and Time Specification ..............   55
         5.2.15  RFC-822 Syntax Change ............................   56
         5.2.16  RFC-822  Local-part ..............................   56
         5.2.17  Domain Literals ..................................   57
         5.2.18  Common Address Formatting Errors .................   58
         5.2.19  Explicit Source Routes ...........................   58
      5.3  SPECIFIC ISSUES ........................................   59
         5.3.1  SMTP Queueing Strategies ..........................   59
            5.3.1.1 Sending Strategy ..............................   59
            5.3.1.2  Receiving strategy ...........................   61
         5.3.2  Timeouts in SMTP ..................................   61
         5.3.3  Reliable Mail Receipt .............................   63
         5.3.4  Reliable Mail Transmission ........................   63
         5.3.5  Domain Name Support ...............................   65



Internet Engineering Task Force                                 [Page 3]




RFC1123                       INTRODUCTION                  October 1989


         5.3.6  Mailing Lists and Aliases .........................   65
         5.3.7  Mail Gatewaying ...................................   66
         5.3.8  Maximum Message Size ..............................   68
      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69

   6. SUPPORT SERVICES ............................................   72
      6.1 DOMAIN NAME TRANSLATION .................................   72
         6.1.1 INTRODUCTION .......................................   72
         6.1.2  PROTOCOL WALK-THROUGH .............................   72
            6.1.2.1  Resource Records with Zero TTL ...............   73
            6.1.2.2  QCLASS Values ................................   73
            6.1.2.3  Unused Fields ................................   73
            6.1.2.4  Compression ..................................   73
            6.1.2.5  Misusing Configuration Info ..................   73
         6.1.3  SPECIFIC ISSUES ...................................   74
            6.1.3.1  Resolver Implementation ......................   74
            6.1.3.2  Transport Protocols ..........................   75
            6.1.3.3  Efficient Resource Usage .....................   77
            6.1.3.4  Multihomed Hosts .............................   78
            6.1.3.5  Extensibility ................................   79
            6.1.3.6  Status of RR Types ...........................   79
            6.1.3.7  Robustness ...................................   80
            6.1.3.8  Local Host Table .............................   80
         6.1.4  DNS USER INTERFACE ................................   81
            6.1.4.1  DNS Administration ...........................   81
            6.1.4.2  DNS User Interface ...........................   81
            6.1.4.3 Interface Abbreviation Facilities .............   82
         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
      6.2  HOST INITIALIZATION ....................................   87
         6.2.1  INTRODUCTION ......................................   87
         6.2.2  REQUIREMENTS ......................................   87
            6.2.2.1  Dynamic Configuration ........................   87
            6.2.2.2  Loading Phase ................................   89
      6.3  REMOTE MANAGEMENT ......................................   90
         6.3.1  INTRODUCTION ......................................   90
         6.3.2  PROTOCOL WALK-THROUGH .............................   90
         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92

   7.  REFERENCES .................................................   93












Internet Engineering Task Force                                 [Page 4]




RFC1123                       INTRODUCTION                  October 1989


1.  INTRODUCTION

   This document is one of a pair that defines and discusses the
   requirements for host system implementations of the Internet protocol
   suite.  This RFC covers the applications layer and support protocols.
   Its companion RFC, "Requirements for Internet Hosts -- Communications
   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
   IP layer, and link layer.

   These documents are intended to provide guidance for vendors,
   implementors, and users of Internet communication software.  They
   represent the consensus of a large body of technical experience and
   wisdom, contributed by members of the Internet research and vendor
   communities.

   This RFC enumerates standard protocols that a host connected to the
   Internet must use, and it incorporates by reference the RFCs and
   other documents describing the current specifications for these
   protocols.  It corrects errors in the referenced documents and adds
   additional discussion and guidance for an implementor.

   For each protocol, this document also contains an explicit set of
   requirements, recommendations, and options.  The reader must
   understand that the list of requirements in this document is
   incomplete by itself; the complete set of requirements for an
   Internet host is primarily defined in the standard protocol
   specification documents, with the corrections, amendments, and
   supplements contained in this RFC.

   A good-faith implementation of the protocols that was produced after
   careful reading of the RFC's and with some interaction with the
   Internet technical community, and that followed good communications
   software engineering practices, should differ from the requirements
   of this document in only minor ways.  Thus, in many cases, the
   "requirements" in this RFC are already stated or implied in the
   standard protocol documents, so that their inclusion here is, in a
   sense, redundant.  However, they were included because some past
   implementation has made the wrong choice, causing problems of
   interoperability, performance, and/or robustness.

   This document includes discussion and explanation of many of the
   requirements and recommendations.  A simple list of requirements
   would be dangerous, because:

   o    Some required features are more important than others, and some
        features are optional.

   o    There may be valid reasons why particular vendor products that



Internet Engineering Task Force                                 [Page 5]




RFC1123                       INTRODUCTION                  October 1989


        are designed for restricted contexts might choose to use
        different specifications.

   However, the specifications of this document must be followed to meet
   the general goal of arbitrary host interoperation across the
   diversity and complexity of the Internet system.  Although most
   current implementations fail to meet these requirements in various
   ways, some minor and some major, this specification is the ideal
   towards which we need to move.

   These requirements are based on the current level of Internet
   architecture.  This document will be updated as required to provide
   additional clarifications or to include additional information in
   those areas in which specifications are still evolving.

   This introductory section begins with general advice to host software
   vendors, and then gives some guidance on reading the rest of the
   document.  Section 2 contains general requirements that may be
   applicable to all application and support protocols.  Sections 3, 4,
   and 5 contain the requirements on protocols for the three major
   applications: Telnet, file transfer, and electronic mail,
   respectively. Section 6 covers the support applications: the domain
   name system, system initialization, and management.  Finally, all
   references will be found in Section 7.

   1.1  The Internet Architecture

      For a brief introduction to the Internet architecture from a host
      viewpoint, see Section 1.1 of [INTRO:1].  That section also
      contains recommended references for general background on the
      Internet architecture.

   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.

      1.2.1  Continuing Internet Evolution

         The enormous growth of the Internet has revealed problems of
         management and scaling in a large datagram-based packet
         communication system.  These problems are being addressed, and
         as a result there will be continuing evolution of the
         specifications described in this document.  These changes will
         be carefully planned and controlled, since there is extensive
         participation in this planning by the vendors and by the
         organizations responsible for operations of the networks.



Internet Engineering Task Force                                 [Page 6]




RFC1123                       INTRODUCTION                  October 1989


         Development, evolution, and revision are characteristic of
         computer network protocols today, and this situation will
         persist for some years.  A vendor who develops computer
         communication software for the Internet protocol suite (or any
         other protocol suite!) and then fails to maintain and update
         that software for changing specifications is going to leave a
         trail of unhappy customers.  The Internet is a large
         communication network, and the users are in constant contact
         through it.  Experience has shown that knowledge of
         deficiencies in vendor software propagates quickly through the
         Internet technical community.

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.

         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out



Internet Engineering Task Force                                 [Page 7]




RFC1123                       INTRODUCTION                  October 1989


         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

      1.2.3  Error Logging

         The Internet includes a great variety of host and gateway
         systems, each implementing many protocols and protocol layers,
         and some of these contain bugs and mis-features in their
         Internet protocol software.  As a result of complexity,
         diversity, and distribution of function, the diagnosis of user
         problems is often very difficult.

         Problem diagnosis will be aided if host implementations include
         a carefully designed facility for logging erroneous or
         "strange" protocol events.  It is important to include as much
         diagnostic information as possible when an error is logged.  In
         particular, it is often useful to record the header(s) of a
         packet that caused an error.  However, care must be taken to
         ensure that error logging does not consume prohibitive amounts
         of resources or otherwise interfere with the operation of the
         host.

         There is a tendency for abnormal but harmless protocol events
         to overflow error logging files; this can be avoided by using a
         "circular" log, or by enabling logging only while diagnosing a
         known failure.  It may be useful to filter and count duplicate
         successive messages.  One strategy that seems to work well is:
         (1) always count abnormalities and make such counts accessible
         through the management protocol (see Section 6.3); and (2)
         allow the logging of a great variety of events to be
         selectively enabled.  For example, it might useful to be able
         to "log everything" or to "log everything for host X".

         Note that different managements may have differing policies
         about the amount of error logging that they want normally
         enabled in a host.  Some will say, "if it doesn't hurt me, I
         don't want to know about it", while others will want to take a
         more watchful and aggressive attitude about detecting and
         removing protocol abnormalities.

      1.2.4  Configuration

         It would be ideal if a host implementation of the Internet
         protocol suite could be entirely self-configuring.  This would
         allow the whole suite to be implemented in ROM or cast into
         silicon, it would simplify diskless workstations, and it would



Internet Engineering Task Force                                 [Page 8]




RFC1123                       INTRODUCTION                  October 1989


         be an immense boon to harried LAN administrators as well as
         system vendors.  We have not reached this ideal; in fact, we
         are not even close.

         At many points in this document, you will find a requirement
         that a parameter be a configurable option.  There are several
         different reasons behind such requirements.  In a few cases,
         there is current uncertainty or disagreement about the best
         value, and it may be necessary to update the recommended value
         in the future.  In other cases, the value really depends on
         external factors -- e.g., the size of the host and the
         distribution of its communication load, or the speeds and
         topology of nearby networks -- and self-tuning algorithms are
         unavailable and may be insufficient.  In some cases,
         configurability is needed because of administrative
         requirements.

         Finally, some configuration options are required to communicate
         with obsolete or incorrect implementations of the protocols,
         distributed without sources, that unfortunately persist in many
         parts of the Internet.  To make correct systems coexist with
         these faulty systems, administrators often have to "mis-
         configure" the correct systems.  This problem will correct
         itself gradually as the faulty systems are retired, but it
         cannot be ignored by vendors.

         When we say that a parameter must be configurable, we do not
         intend to require that its value be explicitly read from a
         configuration file at every boot time.  We recommend that
         implementors set up a default for each parameter, so a
         configuration file is only necessary to override those defaults
         that are inappropriate in a particular installation.  Thus, the
         configurability requirement is an assurance that it will be
         POSSIBLE to override the default when necessary, even in a
         binary-only or ROM-based product.

         This document requires a particular value for such defaults in
         some cases.  The choice of default is a sensitive issue when
         the configuration item controls the accommodation to existing
         faulty systems.  If the Internet is to converge successfully to
         complete interoperability, the default values built into
         implementations must implement the official protocol, not
         "mis-configurations" to accommodate faulty implementations.
         Although marketing considerations have led some vendors to
         choose mis-configuration defaults, we urge vendors to choose
         defaults that will conform to the standard.

         Finally, we note that a vendor needs to provide adequate



Internet Engineering Task Force                                 [Page 9]




RFC1123                       INTRODUCTION                  October 1989


         documentation on all configuration parameters, their limits and
         effects.


   1.3  Reading this Document

      1.3.1  Organization

         In general, each major section is organized into the following
         subsections:

         (1)  Introduction

         (2)  Protocol Walk-Through -- considers the protocol
              specification documents section-by-section, correcting
              errors, stating requirements that may be ambiguous or
              ill-defined, and providing further clarification or
              explanation.

         (3)  Specific Issues -- discusses protocol design and
              implementation issues that were not included in the walk-
              through.

         (4)  Interfaces -- discusses the service interface to the next
              higher layer.

         (5)  Summary -- contains a summary of the requirements of the
              section.

         Under many of the individual topics in this document, there is
         parenthetical material labeled "DISCUSSION" or
         "IMPLEMENTATION".  This material is intended to give
         clarification and explanation of the preceding requirements
         text.  It also includes some suggestions on possible future
         directions or developments.  The implementation material
         contains suggested approaches that an implementor may want to
         consider.

         The summary sections are intended to be guides and indexes to
         the text, but are necessarily cryptic and incomplete.  The
         summaries should never be used or referenced separately from
         the complete RFC.

      1.3.2  Requirements

         In this document, the words that are used to define the
         significance of each particular requirement are capitalized.
         These words are:



Internet Engineering Task Force                                [Page 10]




RFC1123                       INTRODUCTION                  October 1989


         *    "MUST"

              This word or the adjective "REQUIRED" means that the item
              is an absolute requirement of the specification.

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

         *    "MAY"

              This word or the adjective "OPTIONAL" means that this item
              is truly optional.  One vendor may choose to include the
              item because a particular marketplace requires it or
              because it enhances the product, for example; another
              vendor may omit the same item.

0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

What do we know about Legacy Video Conferencing? - Full IT support needed! - Complicated systems at outrageous prices! - Intense training required! Highfive believes we need to embrace a new alternative.
This paper addresses the security of Sennheiser DECT Contact Center and Office (CC&O) headsets. It describes the DECT security chain comprised of “Pairing”, “Per Call Authentication” and “Encryption”, which are all part of the standard DECT protocol.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
This tutorial demonstrates a quick way of adding group price to multiple Magento products.

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now