Greet with LHLO and check the envelope
02LHLO replaces the SMTP greetings. A recipient enters this transaction’s successful set only after its RCPT command receives a 2xx positive completion.
Separate valid transaction after LHLO: MAIL is accepted, RCPT for Ana gets 250, then DATA gets 354. Only now may content and the final dot line follow; final delivery responsibility has not yet transferred.
Source for this drawing: RFC 2033 · Read RFC section 4.1 ↗
New to this? Start hereA quick picture + helpful background
The envelope and the letter do different jobs.
Mail transport moves a message between servers. The message format describes its contents. Authentication adds checks; it does not make every message safe.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An accepted recipient command permits DATA; it is not final message acceptance.
- LHLO has EHLO semantics, but HELO and EHLO are absent from LMTP. A server MUST NOT return a positive completion to either; 500 is recommended.
- If no RCPT command has succeeded in the transaction, DATA MUST fail with 503. A successful RCPT has a reply code beginning with 2.
- A server MUST implement PIPELINING and ENHANCEDSTATUSCODES, and SHOULD implement 8BITMIME. The examples show command/reply roles; they are not complete pipelining or enhanced-status transcripts.
The rejected greeting and empty-envelope DATA examples are separate cases, not commands sent after a valid LHLO in the same conversation. In the successful branch, MAIL and RCPT precede DATA;354 permits content, while final recipient results follow the terminating dot line.
Read the RFC section ↗