邮件服务器响应分析

1.登陆邮件服务器 telnet smtp.xxx.com 25

2.EHLO smtp.xxx.com

回显：

250-mtaout-mb01.r1000.mx.xxx.com
250-PIPELINING
250-SIZE 36700160
250-ETRN
250-STARTTLS
250-AUTH XAOL-UAS-MB LOGIN PLAIN
250-AUTH=XAOL-UAS-MB LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

PIPELINING

--The PIPELINING extension means that, during this connection, the client does not always need to wait for a response before sending the next request.

Specifically, the client does not need to wait for the response to RSET, MAIL, RCPT, or an encoded message.

Furthermore, the server is permitted to defer such responses as long as it is continuing to receive new requests from the client. (Of course, this situation does not occur unless the client knows about PIPELINING.) The server must never wait for client input unless it has first ``flushed'' all pending responses; and it must send responses in the correct order.

It is the client's responsibility to avoid deadlock.

8BITMIME

--

Users send billions of 8-bit messages every year. As far as I know, all servers can handle 8-bit messages. A few years ago I was able to find a few hosts running ancient 7-bit versions of sendmail, but I don't see any now.

Most clients will send 8-bit messages upon request. This is the behavior of qmail, for example, and exim, and sendmail, starting from version 6.57 in 1993.

Exception: sendmail, starting from version 8.7 in 1995, applies Q-P conversion to an 8-bit message if the message contains MIME header fields, the 8 flag (popular in Europe but not the default) is not set, and the SMTP server has not taken the protective measures described below.

Q-P conversion has mixed results. It eliminates message corruption in the rare case that the server is a 7-bit server and the recipient's mailer supports MIME. However, it creates new message corruption in the much more common case that the server is an 8-bit server and the recipient's mailer does not support MIME.

The 8BITMIME extension has two effects in practice:

• The client will avoid Q-P conversion.
• The client may add extra information at the end of a MAIL request: a space followed by either "BODY=7BIT" or "BODY=8BITMIME".

Recommendations for 8-bit support

7-bit mailers are obsolete. Do not attempt to deploy a 7-bit mailer on the Internet. The fact that you are complying with IETF standards is irrelevant; users will not tolerate a 7-bit mailer.

Do not implement Q-P conversion in an SMTP client. You will find that simply sending an 8-bit message is much more successful than attempting Q-P conversion, whether or not the server announces 8BITMIME.

Announce 8BITMIME in your server, to prevent Q-P conversion from sendmail without the 8 flag. Ignore the BODY information.

SIZE

--The SIZE extension has two purposes:

• To give the server an estimate of the size of a message before the message is transmitted.
• To warn the client that messages above a certain size will not be accepted.

The claimed benefit is an occasional large reduction in SMTP traffic. Beware, however, that using SIZE also means a persistent small expansion in SMTP traffic. Measurements at several hosts have found that the expansion outweighs the reduction.

The SIZE extension has at most one argument. If the argument is supplied, it consists entirely of ASCII digits, giving a number n. If n is nonzero, the server is indicating that it will reject messages containing more than n bytes (counting two bytes per line for \015\012).

Whether or not an argument is supplied, the SIZE extension has the following meaning. During this connection, the client may send the following string, between 7 and 26 characters, as extra information at the end of a MAIL request:

1. a space;
2. the word SIZE;
3. an equals sign;
4. between 1 and 20 ASCII digits, giving a number.

The number is an estimate, usually but not necessarily an overestimate, of the total number of bytes in the message.

ETRN

--The parameter to an ETRN request is normally a domain name.

If the server accepts the request, it will schedule deliveries to that domain for the next convenient moment. Note that this does not guarantee any particular time. The server can use code 250, 251, 252, or 253. 251 guarantees that there are no deliveries waiting for the domain. 252 and 253 guarantee that there are deliveries waiting.

The parameter may instead be a domain name preceded by an @; this refers to the domain and all its subdomains. Or the parameter may start with an #; in this case the interpretation is server-defined.

There is an ETRN extension, with no arguments allowed, that promises support for the ETRN verb. I don't know whether ETRN-using clients pay attention to this extension.

ENHANCEDSTATUSCODES

--The Enhanced-Status-Codes service extension Servers supporting the Enhanced-Status-Codes extension must preface the text part of almost all response lines with a status code. As in RFC 1893, the syntax of these status codes is given by the ABNF: status-code ::= class "." subject "." detail class ::= "2" / "4" / "5" subject ::= 1*3digit detail ::= 1*3digit These codes must appear in all 2xx, 4xx, and 5xx response lines other than initial greeting and any response to HELO or EHLO. Note that 3xx responses are NOT included in this list. All status codes returned by the server must agree with the primary response code, that is, a 2xx response must incorporate a 2.X.X code, a 4xx response must incorporate a 4.X.X code, and a 5xx response must incorporate a 5.X.X code.