5.7.7Message rejected for duplicate authentication-results headers

RFC 3463 defines registry pattern X.7.7 as "Message integrity failure" and states outright that the pattern can usefully appear as a permanent, transient-persistent, or successful-delivery code, depending on context. Still, this catalog's IANA registry mirror lists X.7.7 as unresolved for every class: neither class 4 nor class 5 has a confirmed registry entry here. Code 5.7.7 maps that pattern onto class 5 and is published solely from exact corpus evidence (the relay's 554 5.7.7 response below), not from any IANA registry confirmation for this class.

In one accepted example, concrete code 5.7.7 applies the X.7.7 pattern as a permanent failure: a spam-filtering relay not attributed to any catalogued provider rejects the message at the end of the DATA command because it carries more than one copy of the same X-Original-Authentication-Results header, a condition this particular relay treats as evidence of corruption or tampering rather than an ordinary side effect of repeated forwarding. The pattern signals a message-integrity failure: a transport system authorized to validate a message could not, because the message was corrupted or altered. RFC 3463 (Section 3.8) frames the pattern generically and notes it may serve as a permanent, transient-persistent, or successful-delivery code; it never settles which class holds a confirmed IANA registry entry, and in this catalog neither class does for X.7.7.

The leading digit 5 denotes a permanent failure for this specific message in the observed example: do not repeat the exact same send unchanged. This does not mean the X.7.7 pattern is inherently permanent by definition — RFC 3463 itself allows it to be used as a transient-persistent or successful-delivery code too, depending on how a given system applies it. Treat class 5 here as a property of this particular relay's observed behavior in this example, not as a universal trait of the X.7.7 pattern itself.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: do not retry the same unchanged message to this address — a repeat send carrying the same duplicated header will fail the same way. Find and fix whichever step in the sending or forwarding chain is adding the second copy of the X-Original-Authentication-Results header, then send a new, deduplicated message.

Do not suppress the recipient address based on code 5.7.7: this is a signal about the integrity of one specific message and header hygiene along the sending chain, not a signal about the validity or activity of the recipient address. Suppression decisions should rest on independent, durable signals about the address itself, not on a single message's header-formatting defect.

• A forwarding step, mailing-list hop, or downstream relay in the chain re-adds an X-Original-Authentication-Results header without stripping the copy already attached at an earlier hop, so the message arrives carrying two identical copies of that header.
• The sending platform or an internal relay chain resends or re-injects a message without deduplicating headers a prior internal step already attached.
• In the one accepted example, the destination relay (spamrelay.zxcs.nl) treats this specific duplication as a spam signal (the corpus library's own parsed data flags it spam: true, not a blocklist hit) rather than a generic formatting complaint — documented behavior of this one relay, not a general rule enforced by all providers.

1. Confirm the enhanced code is exactly 5.7.7, the basic reply is 554 (in the accepted example), and read the relay's literal wording — the "too many equal X-headers" phrase names the exact header that repeated.
2. Inspect the outgoing message's raw headers for any header appearing more than once, especially X-Original-Authentication-Results, and trace which step (forwarding, a relay, resend logic) added the extra copy.
3. Correlate the response with the recipient or domain and the attempt time; retain the full "host ... said: ..." diagnostic line, since it names both the intermediate relay and the exact duplicated header.
4. Fix the duplication at its source (forwarding, relay, or resend logic) and send a fresh, deduplicated message rather than retrying the identical one.