[...]

Góra strony
Delete this message
Reply to this message
Autor: Nieznany
Data:  
Temat: [...]
From RFC 821

3.5. OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.


      The following two commands are used in transmission channel
      opening and closing:


         HELO <SP> <domain> <CRLF>


         QUIT <CRLF>


      In the HELO command the host sending the command identifies
      itself; the command may be interpreted as saying "Hello, I am
      <domain>".


      -------------------------------------------------------------


                     Example of Connection Opening


         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
         S: HELO USC-ISIF.ARPA
         R: 250 BBN-UNIX.ARPA


3.7. DOMAINS

      Domains are a recently introduced concept in the ARPA Internet
      mail system.  The use of domains changes the address space from a
      flat global space of simple character string host names to a
      hierarchically structured rooted tree of global addresses.  The
      host name is replaced by a domain and host designator which is a
      sequence of domain element strings separated by periods with the
      understanding that the domain elements are ordered from the most
      specific to the most general.


      For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
      "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.


      Whenever domain names are used in SMTP only the official names are
      used, the use of nicknames or aliases is not allowed.


4. THE SMTP SPECIFICATIONS

4.1. SMTP COMMANDS

      4.1.1.  COMMAND SEMANTICS


         The SMTP commands define the mail transfer or the mail system
         function requested by the user.  SMTP commands are character
         strings terminated by <CRLF>.  The command codes themselves are
         alphabetic characters terminated by <SP> if parameters follow
         and <CRLF> otherwise.  The syntax of mailboxes must conform to
         receiver site conventions.  The SMTP commands are discussed
         below.  The SMTP replies are discussed in the Section 4.2.


         A mail transaction involves several data objects which are
         communicated as arguments to different commands.  The
         reverse-path is the argument of the MAIL command, the
         forward-path is the argument of the RCPT command, and the mail
         data is the argument of the DATA command.  These arguments or
         data objects must be transmitted and held pending the
         confirmation communicated by the end of mail data indication
         which finalizes the transaction.  The model for this is that
         distinct buffers are provided to hold the types of data
         objects, that is, there is a reverse-path buffer, a
         forward-path buffer, and a mail data buffer.  Specific commands
         cause information to be appended to a specific buffer, or cause
         one or more buffers to be cleared.


         HELLO (HELO)


            This command is used to identify the sender-SMTP to the
            receiver-SMTP.  The argument field contains the host name of
            the sender-SMTP.


            The receiver-SMTP identifies itself to the sender-SMTP in
            the connection greeting reply, and in the response to this
            command.


            This command and an OK reply to it confirm that both the
            sender-SMTP and the receiver-SMTP are in the initial state,
            that is, there is no transaction in progress and all state
            tables and buffers are cleared.


      4.1.2.  COMMAND SYNTAX


         The commands consist of a command code followed by an argument
         field.  Command codes are four alphabetic characters.  Upper
         and lower case alphabetic characters are to be treated
         identically.  Thus, any of the following may represent the mail
         command:


            MAIL    Mail    mail    MaIl    mAIl


         This also applies to any symbols representing parameter values,
         such as "TO" or "to" for the forward-path.  Command codes and
         the argument fields are separated by one or more spaces.
         However, within the reverse-path and forward-path arguments
         case is important.  In particular, in some hosts the user
         "smith" is different from the user "Smith".


         The argument field consists of a variable length character
         string ending with the character sequence <CRLF>.  The receiver
         is to take no action until this sequence is received.


         Square brackets denote an optional argument field.  If the
         option is not taken, the appropriate default is implied.


         The following are the SMTP commands:


            HELO <SP> <domain> <CRLF>



4.5. DETAILS

      4.5.1.  MINIMUM IMPLEMENTATION


         In order to make SMTP workable, the following minimum
         implementation is required for all receivers:


            COMMANDS -- HELO
                        MAIL
                        RCPT
                        DATA
                        RSET
                        NOOP
                        QUIT


APPENDIX F

Scenarios

      This section presents complete scenarios of several types of SMTP
      sessions.


A Typical SMTP Transaction Scenario

      This SMTP example shows mail sent by Smith at host USC-ISIF, to
      Jones, Green, and Brown at host BBN-UNIX.  Here we assume that
      host USC-ISIF contacts host BBN-UNIX directly.  The mail is
      accepted for Jones and Brown.  Green does not have a mailbox at
      host BBN-UNIX.


      -------------------------------------------------------------


         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
         S: HELO USC-ISIF.ARPA
         R: 250 BBN-UNIX.ARPA


-----------------------------------------------------------------------
From RFC2821
2.3.4 Host

For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP
network) and supporting the SMTP protocol. Hosts are known by names
(see "domain"); identifying them by numerical address is discouraged.

2.3.5 Domain

A domain (or domain name) consists of one or more dot-separated
components. These components ("labels" in DNS terminology [22]) are
restricted for SMTP purposes to consist of a sequence of letters,
digits, and hyphens drawn from the ASCII character set [1]. Domain
names are used as names of hosts and of other entities in the domain
name hierarchy. For example, a domain may refer to an alias (label
of a CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See [22] and
section 5 of this specification.

The domain name, as described in this document and in [22], is the
entire, fully-qualified name (often referred to as an "FQDN"). A
domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.

3.6 Domains

Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:

   -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1.


   -  The reserved mailbox name "postmaster" may be used in a RCPT
      command without domain qualification (see section 4.1.1.3) and
      MUST be accepted if so used.


4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)

These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is

available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system. y The SMTP server identifies itself to the SMTP
client in the connection greeting reply and in the response to this
command.

A client SMTP SHOULD start an SMTP session by issuing the EHLO
command. If the SMTP server supports the SMTP service extensions it
will give a successful response, a failure response, or an error
response. If the SMTP server, in violation of this specification,
does not support any SMTP service extensions it will generate an
error response. Older client SMTP systems MAY, as discussed above,
use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
support the HELO command and reply properly to it. In any event, a
client MUST issue HELO or EHLO before starting a mail transaction.

These commands, and a "250 OK" reply to one of them, confirm that
both the SMTP client and the SMTP server are in the initial state,
that is, there is no transaction in progress and all state tables and
buffers are cleared.

Syntax:

      ehlo            = "EHLO" SP Domain CRLF
      helo            = "HELO" SP Domain CRLF


Normally, the response to EHLO will be a multiline reply. Each line
of the response contains a keyword and, optionally, one or more
parameters. Following the normal syntax for multiline replies, these
keyworks follow the code (250) and a hyphen for all but the last
line, and the code and a space for the last line. The syntax for a
positive response, using the ABNF notation and terminal symbols of
[8], is:

      ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
                   / (    "250-"   domain [ SP ehlo-greet ] CRLF
                       *( "250-"   ehlo-line                CRLF )
                          "250"    SP ehlo-line             CRLF  )


      ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
                   ; string of any characters other than CR or LF


      ehlo-line    = ehlo-keyword *( SP ehlo-param )


      ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
                   ; additional syntax of ehlo-params depends on
                   ; ehlo-keyword


      ehlo-param   = 1*(%d33-127)
                   ; any CHAR excluding <SP> and all
                   ; control characters (US-ASCII 0-31 inclusive)


Although EHLO keywords may be specified in upper, lower, or mixed
case, they MUST always be recognized and processed in a case-
insensitive manner. This is simply an extension of practices
specified in RFC 821 and section 2.4.1.


--EAL--