5.5.2SMTP 5.5.2: Protocol command syntax error

Whenever the receiving host rejects a mail-transaction command as unparseable, registry pattern X.5.2 appears as code 5.5.2: either the line syntax is malformed or the verb is unknown to that peer. Permanent class 5 is what the enhanced status register records for this attempt. The status detail does not name the exact command line, distinguish syntax failure from unsupported verbs, or locate the defect on client versus server side. Narrowing cause requires the full SMTP reply and the transaction trace preceding the rejected command. The accepted examples on this page come from two products' documentation and show how those products word the condition.

A mail transaction protocol command that could not be interpreted because its syntax was wrong or the command was unrecognized is X.5.2. The registry description says this detail is useful only as a permanent error, and the concrete 5.5.2 variant carries the corresponding class 5.

The leading digit 5 denotes a permanent failure for this message in the current context. The code alone identifies neither the exact command nor its faulty part, does not determine whether the cause was invalid syntax, an unrecognized command, or an input the system could not decode, and does not establish which side has the problem. The basic reply narrows the branch only as a hint: RFC 5248 records the associated basic status code as non-exclusive, and the accepted examples for 5.5.2 arrive with 501, 504, 554, and 555.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: stop automatic and manual retries of the same command in the unchanged context, because a system that could not interpret an input will not interpret the identical input on a later attempt. The unlock condition is a demonstrated change in what the client sends or in how the receiving system handles it: corrected syntax, a replaced command, a corrected address form, or a changed parser on the receiving side. A send to a different destination is a new route and a new exchange, not a retry of this attempt; count it as a first attempt and key it for idempotency so no recipient receives the message twice.

Operational recommendation: 5.5.2 is not a basis for adding the address to a suppression list. The code reports that a system could not interpret part of the exchange and evaluates nothing about the mailbox behind the address: it does not state that the mailbox is missing, full, disabled, or refusing mail. One of the accepted examples rejects a sender address for its form rather than assessing a recipient at all. Suppression requires a separate signal about the mailbox itself, taken from the applicable policy together with the full response and the event history recorded for that address.

• A mail-transaction command line was malformed and the receiving system could not interpret it. Gmail's SMTP error messages documentation reports this with basic reply 555 as “555 5.5.2 Syntax error.” and as “555 5.5.2 Syntax error, goodbye.”
• The receiving system could not decode a response it was given during the exchange. This is a failure of a reply inside the session rather than of a command verb, and the sending client's command formatting may be entirely correct. Gmail's documentation reports it with basic reply 501 as “501 5.5.2 Syntax error, cannot decode response.”
• An address the client supplied was not in a form the receiving system accepts, for example a sender address without a fully qualified domain. Rackspace's common email bounces documentation reports this with basic reply 504 as “504 5.5.2 <user@nonqualifieddomain>: Sender address rejected: need fully-qualified address”, where the bracketed address is a placeholder the server fills in with the rejected address at rejection time.

1. Confirm from the raw SMTP response or delivery report that the enhanced code is exactly 5.5.2, and note which basic reply carried it. The accepted examples carry it on 501, 504, 554, and 555, a spread wide enough that the basic reply settles nothing on its own, since RFC 5248 records the association as non-exclusive.
2. Correlate the response with the intended message, attempt time, system that returned the code, and exact command; also retain the preceding transaction trace.
3. Separate the conditions the accepted responses describe rather than choosing between malformed and unrecognized: a command line the receiving system could not parse; a response inside the exchange it could not decode, which is not a command failure at all; and an address it was given in a form it does not accept, such as a sender address without a fully qualified domain. Some systems also return 5.5.2 for message content they could not parse. Do not attribute the defect to the client or to the server until the trace and the complete response text support that attribution.
4. Stop unchanged retries; before any new send, confirm a relevant correction or handling change and check suppression state again.