4.3.0SMTP 4.3.0: Undefined temporary mail-system status

X.3.0 is the other-or-undefined mail-system status; 4.3.0 applies its temporary class and covers destination-system conditions that no more specific status in the class describes.

The destination system normally exists but an unnamed system condition generated this delivery status. X.3.0 is the catch-all entry of the mail-system class, so it carries no detail of its own and does not replace a more specific X.3 status when the destination system has one to return. Accepted responses recorded under 4.3.0 range from a general temporary system problem, through a temporary failure in a lookup the destination performs, to a limit the destination applied to the sending traffic or to the shape of the transaction.

Class 4 means the issue may clear; it does not prove a permanent outage or invalid address. RFC 2034 requires the enhanced class to agree with the class of the SMTP reply, and RFC 5248 records the associated basic status code as non-exclusive, which is why accepted 4.3.0 figures appear behind a 451 reply and behind a 421 reply without any change in the enhanced status. What differs is the session: 421 is the reply a system returns when it closes the transmission channel, while 451 rejects inside a session that stays open, so the same status reaches the sender at two different connection states.

Class

Temporary failure

Retry

Controlled retry

Suppression

Check the full context

Queue bounded retries with backoff, jitter, idempotency keys, and an attempt or time limit, and group attempts by destination system, connecting IP and time so one system's condition does not drive unrelated routes. Record with each attempt which basic reply carried the status, because the two do not leave the connection in the same state: 421 closes the transmission channel, so nothing further is offered on it and the next attempt has to open a new connection, while 451 rejects inside a session that stays open, where the remaining recipients and messages can still be offered. Attempts continue only while that destination still returns a temporary class and the limit is not exhausted; exhaustion ends retrying and starts escalation instead of opening a new retry cycle. Where the response text named a sending-side condition, correct that condition before the next attempt, because an unchanged transaction reproduces the same result. A different destination system is a new route, not a continuation of this sequence.

Do not suppress from 4.3.0 alone. The code reports a mail-system condition and evaluates nothing about whether the recipient address exists, is spelled correctly, or accepts mail, and the accepted figures attribute the same digits to the destination system, to a lookup it depends on, and to the sending server's own traffic. Suppress only on independent permanent evidence or on a documented policy applied after reviewing the full response history.

• A general temporary condition inside the destination mail system that the server does not name. Google's SMTP error table documents a 421 reply beginning “Temporary System Problem. Try again later.” and a 451 reply beginning “Email server has temporarily rejected this message.”, both continuing with a pointer to Google's documentation and the gsmtp tag.
• A temporary failure in a lookup the destination performs before it can accept the message. Rackspace's hosted Email bounce documentation lists a 451 4.3.0 row reading “Temporary lookup failure”, preceded by an angle-bracket address token that the server fills in at rejection time.
• A limit the destination applied to the traffic or to the transaction rather than to the recipient. Rackspace documents a 451 4.3.0 row reading “Client host rejected: Throttled - Too much spam from your mail server. Try again later.”, preceded by a server and address token the server fills in at rejection time, and Google documents a 451 4.3.0 row beginning “Multiple destination domains per transaction is unsupported. Please try again.” with a reference to RFC 5321.

1. Confirm the reply carries exact enhanced status 4.3.0 and record which basic reply it paired with. Accepted figures pair it with 451 and with 421, and RFC 5248 records the associated basic status code as non-exclusive, so the basic reply alone does not identify the condition. It does settle how the session ended, which is the reason to record it: 421 closed the transmission channel and 451 did not.
2. Identify which system returned the status and retain the evidence packet: the raw response line, the SMTP stage, the destination system, the connecting IP, the message identifier and the timestamp. Compare sender and destination logs where both are available.
3. Read the full response text to separate the candidate causes, because the digits are generic. Wording about a temporary system problem or a temporary rejection points at the destination system, wording about a lookup failure points at a dependency the destination queries, and wording about throttling or an unsupported transaction points at the sending traffic or at the shape of the transaction.
4. State the single condition that authorises a new attempt before sending it: the destination still returns a temporary class, the bounded limit is not exhausted, and any sending-side condition named in the response has been corrected.