Connected: An Internet Encyclopedia
5.2.7 RCPT Command: RFC-821 Section 4.1.1

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1123
Up: 5. ELECTRONIC MAIL -- SMTP and RFC-822
Up: 5.2 PROTOCOL WALK-THROUGH
Prev: 5.2.6 Mail Relay: RFC-821 Section 3.6
Next: 5.2.8 DATA Command: RFC-821 Section 4.1.1

5.2.7 RCPT Command: RFC-821 Section 4.1.1

5.2.7 RCPT Command: RFC-821 Section 4.1.1

A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster".

The receiver-SMTP MAY verify RCPT parameters as they arrive; however, RCPT responses MUST NOT be delayed beyond a reasonable time (see Section 5.3.2).

Therefore, a "250 OK" response to a RCPT does not necessarily imply that the delivery address(es) are valid. Errors found after message acceptance will be reported by mailing a notification message to an appropriate address (see Section 5.3.3).

DISCUSSION:

The set of conditions under which a RCPT parameter can be validated immediately is an engineering design choice. Reporting destination mailbox errors to the Sender-SMTP before mail is transferred is generally desirable to save time and network bandwidth, but this advantage is lost if RCPT verification is lengthy.

For example, the receiver can verify immediately any simple local reference, such as a single locally- registered mailbox. On the other hand, the "reasonable time" limitation generally implies deferring verification of a mailing list until after the message has been transferred and accepted, since verifying a large mailing list can take a very long time. An implementation might or might not choose to defer validation of addresses that are non-local and therefore require a DNS lookup. If a DNS lookup is performed but a soft domain system error (e.g., timeout) occurs, validity must be assumed.


Next: 5.2.8 DATA Command: RFC-821 Section 4.1.1

Connected: An Internet Encyclopedia
5.2.7 RCPT Command: RFC-821 Section 4.1.1