茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1682801 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
F09_586.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

小企鵝開談 : [轉貼]SMTP commands

發表者 討論內容
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]SMTP commands

SMTP commands

Home » SMTP commands

In this article you will find a list of the most important SMTP commands with a short explanation. Each command is used in a normal communication sequence between two servers through the SMTP protocol, in order to deliver emails.

HELO
It’s the first SMTP command: is starts the conversation identifying the sender server and is generally followed by its domain name.

EHLO
An alternative command to start the conversation, underlying that the server is using the Extended SMTP protocol.

MAIL FROM
With this SMTP command the operations begin: the sender states the source email address in the “From” field and actually starts the email transfer.

RCPT TO
It identifies the recipient of the email; if there are more than one, the command is simply repeated address by address.

SIZE
This SMTP command informs the remote server about the estimated size (in terms of bytes) of the attached email. It can also be used to report the maximum size of a message to be accepted by the server.

DATA
With the DATA command the email content begins to be transferred; it’s generally followed by a 354 reply code given by the server, giving the permission to start the actual transmission.

VRFY
The server is asked to verify whether a particular email address or username actually exists.

TURN
This command is used to invert roles between the client and the server, without the need to run a new connaction.


AUTH
With the AUTH command, the client authenticates itself to the server, giving its username and password. It’s another layer of security to guarantee a proper transmission.

RSET
It communicates the server that the ongoing email transmission is going to be terminated, though the SMTP conversation won’t be closed (like in the case of QUIT).

EXPN
This SMTP command asks for a confirmation about the identification of a mailing list.

HELP
It’s a client’s request for some information that can be useful for the a successful transfer of the email.

QUIT
It terminates the SMTP conversation.


原文出處:SMTP Commands: all you need to know
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]SMTP Commands and Sample Sessions

SMTP Commands and Sample Sessions

Last Updated on Fri, 07 Jan 2022 | Voice Gateways

The easiest way to grasp how SMTP works is to look at a basic SMTP session. Example 6-1 details how a simple e-mail is transmitted between two mail devices using SMTP.

Example 6-1 SMTP Session

220 smtp-outbound.cisco.com ESMTP Sendmail 8.12.10/8.12.6 ; Fri, 20 Oct 2006

16:01:02 -0400 (EDT) HELO cisco.com

250 smtp-outbound.cisco.com Hello [192.168.1.1], pleased to meet you

MAIL FROM:< [email protected]>

250 2.1.0 [email protected]... Sender ok

RCPT TO:<
[email protected]>

250 2.1.5 [email protected]... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself Subject: test message From: [email protected] To: [email protected]

Example 6-1 SMTP Session (Continued) Hello,

This is a test. Goodbye.

250 2.0.0 k9k1234567890 Message accepted for delivery QUIT

221 2.0.0 smtp-outbound.cisco.com closing connection


The SMTP session shown in Example 6-1 begins when the transmitting e-mail device or client initiates a TCP connection on port 25 to the receiving device, typically a mail server. The mail server answers the connection by identifying itself with a three-digit code followed by a greeting similar to the first line of Example 6-1. The three-digit codes preceding all the responses from the mail server are discussed later in this section. Notice that the e-mail client SMTP commands are shown in boldface type, whereas the e-mail server responses are shown in normal type.

The e-mail client responds to the server greeting with a HELO command and includes its domain name. The mail server then acknowledges the HELO command. Following that, the e-mail client submits the sending and receiving address to the mail server using the MAIL FROM: and RCPT TO:
SMTP commands. To make a parallel to standard mail, these two pieces of information are known as the SMTP envelope. The sender's e-mail address and the recipient's e-mail address are the only information used by the SMTP server to deliver the message.

The SMTP content is the body of the message, which also includes header information, and it is transmitted after proper acknowledgment from the e-mail server to the client's DATA command. Upon completion of the e-mail transaction, the e-mail client gracefully ends the SMTP session with a QUIT command.


Example 6-1 illustrates a basic SMTP session using the SMTP command HELO. However, an improved version of SMTP known as Extended Simple Mail Transfer Protocol (ESMTP) is an alternative that has more features and a greater versatility through added service extensions. ESMTP uses the command EHLO rather than HELO as an identification command. An example of an EHLO command and response session is shown in Example 6-2.

Example 6-2 EHLO Command and Response

220 smtp.cisco

com Simple

Mail Transfer Service Ready

EHLO cisco.com

250-smtp.cisco

com greets

cisco.com

250-8BITMIME

250-SIZE

250-DSN

250 HELP


In Example 6-2, you can see how the EHLO command elicits a more detailed response from the SMTP server. The server now includes its supported ESMTP extensions in the response. These extensions let the client know the features and other capabilities for this SMTP server. From a T.37 perspective, either ESMTP or SMTP with their respective EHLO and HELO identification commands may be used.

In addition to the SMTP commands highlighted in Example 6-1 and Example 6-2, there are additional SMTP commands. Table 6-2 lists the common SMTP and ESMTP commands and provides a brief description of each.

Table 6-2 Common SMTP/ESMTP Commands

SMTP/ESMTP Command

Definition

HELO domain name

Hello: Identifies the SMTP client to the SMTP server

EHLO domain name

Extended Hello: Identifies the SMTP client to the SMTP server


and requests a list of ESMTP extensions supported by the server

MAIL FROM: sender

Mail From: Identifies the sender of the e-mail message

address

RCPT TO: recipient address

Recipient To: Specifies a single recipient for the e-mail transaction

DATA

Data: Indicates to the server that the client is ready to transmit the

message content

RSET

Reset: Aborts the current mail transaction

VRFY user address

Verify: Requests that the server validate a mailbox address

EXPN mailing list

Expand: Requests that the server confirm the mailing list address

and provide a list of users

HELP [SMTP command]


Help: Requests general help from the server or command specific

help when a valid SMTP command is included

NOOP

No Operation: A null command that provides no function other

than the reception of an OK reply from the server

QUIT

QUIT: Terminates the SMTP session

Notice in Example 6-1 and Example 6-2 that the SMTP server always precedes its response with a numeric, three-digit code. These codes are referred to as SMTP response codes, and their definitions are defined by RFC 821. Table 6-3 details the SMTP response codes and their definitions.


Table 6-3 SMTP Response Codes

SMTP Response Code

Definition

211

System status, or system help reply

214

Help message

220


<domain> service ready

221

<domain> service closing session

250

Requested mail action ok, completed

251

User not local; will forward to <forward-path>

252

Cannot VRFY user but message will be accepted and delivery

attempted

354

Start mail input; end with <CRLF>.<CRLF>

421

<domain> service not available, ending session

450

Requested action not taken, mailbox unavailable (mailbox busy)

451

Requested action aborted; local error in processing

452

Requested action not taken; insufficient system storage

500

Syntax error, command unrecognized

501

Syntax error in parameters or arguments

502

Command not implemented

503

Bad sequence of commands

504

Command parameter not implemented

550

Requested action not taken; mailbox unavailable (mailbox not found,

no access, rejected for policy reasons)

551

User not local; try <forward-path>

552

Requested action aborted; exceeded storage allocation

553

Requested action not taken; mailbox name not allowed (mailbox

syntax incorrect)

554

Transaction failed

DSN and MDN


Some of the most commonly used services that are added to the basic functionality of SMTP relate to giving the sender of an e-mail message a notification about the status of the message. Two such notification methods are delivery status notification (DSN) and message disposition notification (MDN) messages. Both of these delivery and processing confirmation methods are frequently integrated with T.37 store-and-forward fax.

DSN messages provide a mechanism for the mail server to convey delivery status of an e-mail message back to the sender. Depending on the mail server configuration, a DSN message can provide positive/negative delivery status information. Negative DSN informs the sender that the message was unable to be delivered or has been delayed, whereas positive DSN updates the originator that the message was successfully delivered.


DSN messages can be requested only during an ESMTP session if the ESMTP mail server explicitly offers support for these messages. Example 6-2 shows an ESMTP mail server responding to an EHLO with DSN support as one of its service extensions. Furthermore, all mail servers in the message path must support DSN for these notifications to work correctly. This concept is important because many mail messages must be routed through more than one e-mail server.

An ESMTP mail server configured for DSN support will only generate DSNs under the conditions requested by the mail client. These conditions are signaled to the mail server by the client in the "RCPT TO:" SMTP envelope command. After the e-mail address, a NOTIFY attribute is used to request the type of delivery notification for a particular recipient required by the sender. Example 6-3 illustrates DSN notification requests during an ESMTP session.

Example 6-3 ESMTP Session with DSN NOTIFY Parameters


220 smtp.cisco.com Simple Mail Transfer Service Ready EHLO cisco.com

250-smtp.cisco.com greets cisco.com

250-8BITMIME

250-SIZE

250-DSN

250 HELP

MAIL FROM:< [email protected]> RET=HDRS ENVID=124567 250 < [email protected]> sender ok

RCPT TO:< [email protected]> NOTIFY=SUCCESS,DELAY ORCPT=rfc822; [email protected] 250 < [email protected]> recipient ok

RCPT TO:<
[email protected]> NOTIFY=FAILURE ORCPT=rfc822; [email protected] 250 < [email protected]> recipient ok RCPT TO:< [email protected]> NOTIFY=NEVER R: 250 < [email protected]> recipient ok


The receivers of the mail message (specified by "RCPT TO:") in Example 6-3 each have the NOTIFY parameter after their respective e-mail addresses. This NOTIFY parameter specifies the delivery conditions under which the DSNs are requested by the sender for that particular recipient. The possible settings for the DSN NOTIFY parameter are specified in Table 6-4.


Table 6-4 DSN NOTIFY Parameter Settings

DSN NOTIFY

Definition

SUCCESS

Requests a DSN when the mail message has been successfully delivered to the

recipient's inbox. This DSN does not reflect that the message has been opened

by the recipient.

FAILURE

Requests a DSN when the mail message cannot be delivered.

DELAY

Requests a DSN when the mail message delivery has been delayed.

NEVER

Requests that a DSN is never sent back to the sender.

Taking into account the DSN NOTIFY parameters defined in Table 6-4, let's analyze the DSN notification for user1 in Example 6-3. The "RCPT TO:" command for user1 requests DSNs for SUCCESS and DELAY as specified in the NOTIFY extension. This means that the sender of this mail message will receive DSN messages only when the mail message is successfully delivered to user1's inbox or if it is delayed in its path to user1's inbox.

Following the NOTIFY parameter and its values, there is another parameter in the "RCPT TO:" SMTP command for user1. This parameter is the ORCPT (Original Recipient Address), and it specifies an address corresponding to the actual recipient of the delivered message.


As part of the ORCPT, an "addr-type" is specified that defines the type of mail address appearing in the ORCPT. In the case of Example 6-3, the "addr-type" for the ORCPT parameters is shown to conform to the format specified in RFC 822.

The last DSN related parameters in Example 6-3 are RET (Return) and ENVID (Envelope ID). These parameters are part of the sender's mail address that is specified in the "MAIL FROM:" SMTP envelope command.

In Example 6-3, RET=HDRS informs the mail server that the client only wants to have the e-mail headers "returned" in any DSN corresponding to a failed message delivery. The other option is RET=FULL, and this parameter requests that the full e-mail be returned for a failed message delivery DSN.


The ENVID parameter allows the client to attach an identifier that will be transmitted along with the message. This ENVID is also included in any DSNs issued for any of the recipients in the SMTP transaction. The purpose of the ENVID is to allow the sender of a message to correlate the original message with any DSNs that are received for that particular message. For a detailed explanation of DSN as a service extension to the SMTP protocol and a definition of all its associated parameters (NOTIFY, ORCPT, RET, ENVID), refer to RFC 3461.

DSN messages are used within T.37 to indicate successful delivery of a fax mail. For instance, if a fax is converted to an e-mail by the onramp gateway and it is configured for DSN, the delivery status of the mail message containing the TIFF attachment of the fax is sent to the user specified in the gateway configuration.


Example 6-4 shows an actual DSN message indicating successful delivery of a fax-mail sent by the mail server to the user specified in the configuration of the onramp gateway. For more information on configuring DSNs on a Cisco onramp gateway, see the section " Dial-Peer Configuration for Onramp Fax" in Chapter 11, "Configuring T.37 Store-and-Forward Fax." Example 6-4 T.37 DSN Success Message

From: Subject: Date: To:

[email protected] Delivery Status Notification (Success) May 22, 2007 7:24:42 PM EDT
[email protected]

Your message

: Incoming Fax[DNIS=9913170][ANI=9194724118] Tue, 22 May 2007 12:23:04 -0400

was delivered to the following recipient(s):

Gonzalo Salgueiro on Tue, 22 May 2007 19:24:42 -0400 <RTP-ESC-T37. faxmail.com #2.0.0>

! Output

omitted for brevity


Another notification to the sender that can prove useful is message disposition notification (MDN) messages. The difference between DSN and MDN is that DSN messages notify the sender of message delivery status by the mail server, whereas MDN messages notify the sender about how the already delivered message is processed by the recipient. For example, although a DSN will notify the sender that the mail message has been successfully deposited in a user's mailbox, it does not mean that the user has viewed the message. An MDN takes the process a step further and informs the sender when the recipient has actually opened the message.


An MDN is often referred to as a "read receipt" or a "return receipt" because it informs the sender that the mail message that was sent was opened by the recipient. A sender requests an MDN by including a "Disposition-Notification-To:" field in the header of the e-mail message. The address in the "Disposition-Notification-To:" field identifies where the disposition notification should be sent.

Example 6-5 illustrates the header for an e-mail that was delivered to the recipient [email protected]. This header requests that an MDN be sent to the sender [email protected]
. Note that the Disposition-Notification-To: field is found in the header information of the SMTP content portion of an SMTP message, unlike a DSN, which makes its notification request in the SMTP envelope.

Example 6-5 E-mail Message Header with an MDN Request


From:

[email protected]

Subject:

Incoming Fax[DNIS=9913170][ANI=9194724118]

Date:

May 22, 2007 2:05:26 PM EDT

To:

[email protected]

Received:

from fax 2811 ([14.80.32.200]) by RTP-ESC-T37.
faxmail.com with

Microsoft SMTPSVC(5.0.2172.1); Tue, 22 May 2007 21:06:43 -0400

Received:

(This is an incoming fax message from the PSTN) by fax_2811 for

< [email protected]> (with Cisco Networks); Tue, 22 May 2007 18:05:26 +0000

Message-Id:

< [email protected]_2811>

X-Mailer:

Technical Support: http://www.cisco

Disposition-

Notification-To: [email protected]

Mime-Version

: 1.0

Content-Type

: multipart/fax-message; boundary="yradnuoB=_00692007180523847.fax

_2811"

X-Account-Id

: 0

Return-Path:

[email protected]

X-Originalarrivaltime: 23 May 2007 01:07:04.0671 (UTC)

FILETIME=[AD3C8EF0:01C79CD6]


Because an MDN reveals to the sender whether and when a recipient has opened the mail message, it is sometimes considered an invasion of privacy. Because of these privacy considerations, MDN support is not available in several mail clients. If it is supported, it is typically implemented in such a fashion that the recipient is explicitly asked whether to acquiesce to the MDN request by the sender.

For instance, when the recipient of the e-mail in Example 6-5 opened that mail message, his mail reader requested for him to accept or deny the sender's request for a read receipt to be sent back. The recipient agreed to the request, and the MDN shown in Example 6-6 was sent.

Example 6-6 T.37 MDN Message

From: [email protected]

Subject: Read: Incoming Fax[DNIS=9913170][ANI=9194724118]

Date: March 31, 2007 3:58:20 PM EDT

To:
[email protected]

! Output omitted for brevity

This is a receipt for the mail you sent to "gsalguei" < [email protected]> at 5/22/2007 1:05 PM

This receipt verifies that the message has been displayed on the recipient's computer at 3/31/2007 2:58 PM

Example 6-6 T.37 MDN Message (Continued)

<MIME Attachment Information Follows:>

Final-Recipient: rfc822; [email protected] Original-Message-ID: < [email protected]_2811> Disposition: manual-action/MDN-sent-manually; displayed


Let's take a look at how the actual MDN message is actually formatted. Note that the MDN in Example 6-6 indicates in the Subject: that the recipient Read: the original message. Of course, there is no way of knowing whether the message was actually read or not, but the MDN does indicate in a human-readable explanation that the recipient did in fact open the message and even provides a timestamp for when it occurred.

The MDN also contains a MIME attachment with the information shown in Example 6-6. The Original-Message-ID: field is used to easily correlate the MDN receipt with the original e-mail. Note that the Original-Message-ID: field in the MDN in Example 6-6 matches up exactly with the Message-Id: field in the header of the original e-mail in Example 6-5.

The most important information in the MDN is found in the Disposition: field. The Disposition: field is a mandatory field for an MDN, and it is used to indicate what actions the recipient performed while processing the mail message.


Several attributes make up the information in the Disposition: field. The two most important parameters are the disposition-mode and the disposition-type. Table 6-5 defines the disposition-mode parameter settings.

Table 6-5 Disposition-Mode Parameter Settings

Disposition-Mode

Definition

manual-action

The message disposition described by the disposition-type

parameter was an explicit instruction by the recipient.

automatic-action

The message disposition described by the disposition-type

parameter was an automatic action not explicitly indicated by

the recipient.

Note: manual-action and automatic-action are mutually exclusive.

One or the other must be specified.


MDN-sent-manually

The MDN was sent because the recipient explicitly gave

permission.

MDN-sent-automatically The MDN was sent because the mail client is configured to do it automatically.

MDN-sent-automatically The MDN was sent because the mail client is configured to do it automatically.

Note: MDN-sent-manually and MDN-sent-automatically are mutually exclusive. One or the other must be specified.

The MDN in Example 6-6 clearly specifies in the Notification: header that the "dispositionmode" is manual-action/MDN-sent-manually. This indicates to the sender that the recipient explicitly and manually acknowledged the request for an MDN to be sent. Table 6-6 defines all the disposition-type parameter settings.

Table 6-6 Disposition-Type Parameter Settings

Disposition-type

Definition

displayed


The e-mail message has been displayed by the mail client.

dispatched

The e-mail message has been dispatched somewhere (for example,

forwarded, printed, faxed, and so on) without necessarily having

been previously displayed.

processed

The e-mail message has been processed in some other way and has

not been displayed by the mail client.

deleted

The e-mail message has been deleted.

denied

The recipient does not want to provide any information to the

sender about how the e-mail message was processed.

failed

A failure prevented a proper MDN from being sent.


The Notification: field for the MDN shown in Example 6-6 has a "disposition-type" with a value of displayed. Referencing Table 6-6, this means that the recipient's mail client displayed the e-mail in Example 6-5. You can get further information on the operation of MDN and all its related parameters in RFC 2298.


原文出處:SMTP Commands and Sample Sessions - Voice Gateways
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]SMTP Commands Reference

SMTP Commands Reference



A client computer communicates with an SMTP server (e-mail server) by using SMTP commands. There is a core list of SMTP commands that all SMTP servers supports and these are referred to as basic SMTP commands in this document. All basic SMTP commands that are specified by the SMTP protocol are described below.
 
To allow more flexibility and additional features most SMTP servers also support extended SMTP commands (also called ESMTP commands). In official documentation these ESMTP commands are also referred to as SMTP service extensions. Some common and often used ESMTP commands (SMTP service extensions) are described in this document also.
 

In the SMTP communication examples listed below the letters C and S are used to refer to the client and the server (C = Client, S = Server).
 
 
Part 1:
 
Basic SMTP Commands
 
Below are the basic SMTP commands described. All SMTP servers that follows the SMTP protocol specification must support these basic commands.
 
HELO (Hello)

The client sends this command to the SMTP server to identify itself and initiate the SMTP conversation. The domain name or IP address of the SMTP client is usually sent as an argument together with the command (e.g. “HELO client.example.com”). If a domain name is used as an argument with the HELO command, it must be a fully qualified domain name (also called FQDN).
 
MAIL FROM
Specifies the e-mail address of the sender. This command also tells the SMTP server that a new mail transaction is starting and makes the server to reset all its state tables and buffers etc. This command is usually sent as the first command after the identifying and login process. If the senders e-mail address is accepted the server will reply with a 250 OK reply code. Example:
 
C: MAIL FROM:<mail@samlogic.com>
S: 250 OK
 
RCPT TO (Recipient To)
Specifies the e-mail address of the recipient. This command can be repeated multiple times for a given e-mail message in order to deliver a single e-mail message to multiple recipients. The example below shows how this command can be used to send same e-mail message to two recipients:
 
C: MAIL FROM:<mail@samlogic.com>
S: 250 OK
C: RCPT TO:<john@mail.com>
S: 250 OK
C: RCPT TO:<peggy@mail.com>
S: 250 OK
 
DATA

The DATA command starts the transfer of the message contents (body text, attachments etc). After that the DATA command has been sent to the server from the client, the server will respond with a 354 reply code. After that, the message contents can be transferred to the server. When all message contents have been sent, a single dot (“.”) must be sent in a line by itself. If the message is accepted for delivery, the SMTP server will response with a 250 reply code. Example (the message contents is set to italic in the example below):
 
C: DATA
S: 354 Send message content; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 2008 05:33:29 -0700
C: From: SamLogic <mail@samlogic.com>
C: Subject: The Next Meeting
C: To: john@mail.com
C:
C: Hi John,

C: The next meeting will be on Friday.
C: /Anna.
C: .
S: 250 OK
 
RSET (Reset)
If the RSET command is sent to the e-mail server the current mail transaction will be aborted. The connection will not be closed (this is reserved for the QUIT command, see below) but all information about the sender, recipients and e-mail data will be removed and buffers and state tables will be cleared.
 
VRFY (Verify)

This command asks the server to confirm that a specified user name or mailbox is valid (exists). If the user name is asked, the full name of the user and the fully specified mailbox are returned. In some e-mail servers the VRFY command is ignored because it can be a security hole. The command can be used to probe for login names on servers. Servers that ignore the VRFY command will usually send some kind of reply, but they will not send the information that the client asked for.
 
NOOP (No operation)
The NOOP command does nothing else than makes the receiver to send an OK reply. The main purpose is to check that the server is still connected and is able to communicate with the client.
 
QUIT

Asks the server to close the connection. If the connection can be closed the servers replies with a 221 numerical code and then is the session closed.
 
 
Example - How To Use Basic SMTP Commands
 
The example below shows how some of the basic SMTP commands described in this page can be used to send an e-mail message trough an SMTP server to a recipient.
 
S: 220 smtp.server.com Simple Mail Transfer Service Ready
C: HELO client.example.com
S: 250 Hello client.example.com
C: MAIL FROM:<mail@samlogic.com>
S: 250 OK
C: RCPT TO:<john@mail.com>
S: 250 OK
C: DATA
S: 354 Send message content; end with <CRLF>.<CRLF>

C: <The message data (body text, subject, e-mail header, attachments etc) is sent>
C: .
S: 250 OK, message accepted for delivery: queued as 12345
C: QUIT
S: 221 Bye
 
In the example above an e-mail message is sent from mail@samlogic.com to john@mail.com. The senders e-mail address is specified by the MAIL FROM command and the recipients e-mail address is specified by the RCPT TO command. The DATA command informs the server that now will the message data be sent (e-mail header, body text etc). The single dot below the message contents informs the SMTP server when the message data ends. After a single dot has been sent to the server and the server has responded, a QUIT command is sent to terminate the session.
 
 

Part 2:
 
Extended SMTP (ESMTP) Commands
 
If a client initiates the SMTP communication using an EHLO (Extended Hello) command instead of the HELO command some additional SMTP commands are often available. They are often referred to as Extended SMTP (ESMTP) commands or SMTP service extensions. Every server can have its own set of extended SMTP commands. After the client has sent the EHLO command to the server, the server often sends a list of available ESMTP commands back to the client.
 
EHLO (Extended Hello)

Same as HELO but tells the server that the client may want to use the Extended SMTP (ESMTP) protocol instead. EHLO can be used although you will not use any ESMTP command. And servers that do not offer any additional ESMTP commands will normally at least recognize the EHLO command and reply in a proper way.
 
AUTH (Authentication)
The AUTH command is used to authenticate the client to the server. The AUTH command sends the clients username and password to the e-mail server. AUTH can be combined with some other keywords as PLAIN, LOGIN and CRAM-MD5 (e.g. AUTH LOGIN) to use different login methods and different levels of security.
 
The example below shows how AUTH LOGIN can be used to make an authenticated login:
 

S: 220 smtp.server.com Simple Mail Transfer Service Ready
C: EHLO client.example.com
S: 250-smtp.server.com Hello client.example.com
S: 250-SIZE 1000000
S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: adlxdkej
S: 334 UGFzc3dvcmQ6
C: lkujsefxlj
S: 235 2.7.0 Authentication successful
 

After that the AUTH LOGIN command has been sent to the server, the server asks for username and password by sending BASE64 encoded text (questions) to the client. “VXNlcm5hbWU6” is the BASE64 encoded text for the word "Username" and “UGFzc3dvcmQ6” is the BASE64 encoded text for the word "Password" in the example above. The client sends username and password also using BASE64 encoding. "adlxdkej", in the example above, is a BASE64 encoded username and "lkujsefxlj" is a BASE64 encoded password.
 
More detailed information about the AUTH command is available on this reference page: The AUTH Command.
 
STARTTLS (Start Transport Layer Security)

E-mail servers and clients that uses the SMTP protocol normally communicate using plain text over the Internet. The communication often goes through one or more routers that is not controlled or trusted by the server and client. This communication can be monitored and it is also possible to alter the messages that are sent via the routers.
 

To improve security, an encrypted TLS (Transport Layer Security) connection can be used when communicating between the e-mail server and the client. TLS is most useful when a login username and password (sent by the AUTH command) needs to be encrypted. TLS can be used to encrypt the whole e-mail message, but the command does not guarantee that the whole message will stay encrypted the whole way to the receiver; some e-mail servers can decide to send the e-mail message with no encryption. But at least the username and password used with the AUTH command will stay encrypted. Using the STARTTLS command together with the AUTH command is a very secure way to authenticate users.
 
The example below shows how to combine the STARTTLS and AUTH LOGIN command to make a secure login to an e-mail server (S = Server, C = Client):
 

S: 220 smtp.server.com Simple Mail Transfer Service Ready
C: EHLO client.example.com
S: 250-smtp.server.com Hello client.example.com
S: 250-SIZE 1000000
S: 250-AUTH LOGIN PLAIN CRAM-MD5
S: 250-STARTTLS
S: 250 HELP
C: STARTTLS
S: 220 TLS go ahead
C: EHLO client.example.com *
S: 250-smtp.server.com Hello client.example.com
S: 250-SIZE 1000000
S: 250-AUTH LOGIN PLAIN CRAM-MD5
S: 250 HELP
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: adlxdkej
S: 334 UGFzc3dvcmQ6
C: lkujsefxlj
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<mail@samlogic.com>
S: 250 OK
C: RCPT TO:<john@mail.com>
S: 250 OK
C: DATA
S: 354 Send message, end with a "." on a line by itself

C: <The message data (body text, subject, e-mail header, attachments etc) is sent>
S .
S: 250 OK, message accepted for delivery: queued as 12345
C: QUIT
S: 221 Bye
 
*) The client sends the EHLO command again to the e-mail server and starts the communication from the beginning, but this time the communication will be encrypted until the QUIT command is sent.
 
SIZE

The SIZE command has two purposes. The SMTP server can inform the client what is the maximum message size and the client can inform the SMTP server the (estimated) size of the e-mail message that will be sent. The client should not send an e-mail message that is larger than the size reported by the server, but normally it is no problem if the message is somewhat larger than the size informed by the client to the server.
 
The example below shows how a server (S) and client (C) reports size to each other:
 
S: 250 SIZE 1000000
C: MAIL FROM:<mail@samlogic.com> SIZE=500000
 
The client sends the SIZE command, and size information, together with the MAIL FROM command. The server sends the command and size information alone. The size is always specified in bytes.

 
HELP
This command causes the server to send helpful information to the client, for example a list of commands that are supported by the SMTP server.
 
 
 
 
References:
RFC 5321 - Simple Mail Transfer Protocol (2008 specification)
RFC 1869 - SMTP Service Extensions
RFC 1870 - SMTP Service Extension for Message Size Declaration
RFC 3207 - SMTP Service Extension for Secure SMTP over TLS

RFC 4954 - SMTP Service Extension for Authentication

Related products:
SamLogic MultiMailer
SamLogic Internet Components

Other articles
More articles are available from the article index page.


原文出處:SMTP Commands Reference (covers HELO/EHLO, MAIL, RCPT, DATA, RSET, VRFY, AUTH, STARTTLS etc)
前一個主題 | 下一個主題 | 頁首 | | |



Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|