Check failure paths before sending any body

Clients MUST check all statuses, including DATA, even when no recipient was accepted. If DATA is rejected, the client can issue RSET after accounting for the group’s replies; no body should be sent.

• Clients MUST check all statuses, including DATA, even when no recipient was accepted. If DATA is rejected, the client can issue RSET after accounting for the group’s replies; no body should be sent.
• RFC 2920 says a server SHOULD accept DATA if and only if at least one valid recipient exists. A client cannot assume that recommendation was followed. If DATA was accepted with no valid recipients, the client should send a single-dot empty terminator.
• After accepting DATA with no valid recipients and receiving that empty message, the server MUST NOT send any message whatsoever to anybody. This exceptional empty recovery is not an ordinary valid RFC 5321 message or permission to omit required headers.
• Separate successful case: 354 permits content; a final 250 after the terminator accepts server responsibility, not proof the mailbox already received it. A final 4xx/5xx is failure with client responsibility retained (RFC 5321 section 4.2.5).
• PIPELINING provides neither authentication nor encryption and does not authorize recipients or guarantee delivery. TLS and other SMTP extensions have their own rules; their commands cannot be inserted mid-group merely because PIPELINING is offered.