Replies & later changes
06Reply classes tell the client whether to proceed, send more information, retry later, or treat an attempt as permanently rejected.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.2 ↗
RFC 5321 · § 4.2EXAMPLE
4 / 4
04
Handle a permanent rejection.
The client reports failure or otherwise changes the request rather than treating it as a transient outage.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 5321 §§4.2.2–4.3.2RFC 7504 §5.1
RFC 7504 adds 521 at connection opening for a host that never accepts mail, and 556 for a destination domain known not to accept mail.
Read the updated RFC section ↗A temporary failure is different from a permanent refusal.
- 2xx reports successful completion; 3xx requests continuation data.
- 4xx reports transient failure, suitable for later retry under queue policy.
- 5xx reports permanent negative completion for the command; do not blindly repeat the unchanged attempt.
A reply applies to the command and context that produced it. Human-readable text can explain, but the three-digit code drives protocol decisions.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
Privacy