SMTP error 420
TCP read/write timeout — non-standard, mostly GroupWise.
Updated Jul 1, 2026
SMTP 420 is not a standard reply code — the real transient connection code is 421. In practice 420 almost always comes from a Novell/Micro Focus (now OpenText) GroupWise gateway logging a "TCP Read/Write Error": the connection to the remote server stalled mid-transfer. It is temporary — usually a Path MTU or firewall issue — so fix the network and retry.
Retry, then fix Path MTU Discovery or firewall/ICMP filtering on the sending host.
What it means
RFC 5321 has no 420 reply code; the standard "try again later" code is 421. When you see "420" it is nearly always GroupWise's Internet Agent (GWIA) reporting a "420 TCP Read Error" or "420 TCP Write Error" — a transport-layer timeout, not a message from a compliant SMTP server. A few servers also emit ad-hoc 420 transient deferrals (for example Microsoft Exchange's "420 4.2.0 Recipient deferred"). Either way it is a 4xx-style temporary condition: retry.
Common causes
GWIA sends full-size TCP segments with "Don't Fragment" set, a router on a smaller-MTU link silently drops them, and the ICMP "fragmentation needed" reply never gets back. The connection stalls and GWIA logs the 420.
Yours or the recipient's firewall silently discarding ICMP type 3/4 or the connection itself.
Packet loss, congestion, or a busy destination server.
For example Exchange's 420 4.2.0. Note greylisting is a separate mechanism and uses 450/451, not 420.
How to fix it
- Retry first
420 is transient and often clears within minutes on its own; a well-behaved mailer retries automatically.
- Fix Path MTU Discovery on the sending host
If the GWIA log shows a TCP read/write error, stop the kernel setting the DF bit. Reload with "sysctl -p". As an alternative, allow ICMP type 3 code 4 through your firewall so PMTUD works.
# temporary (current boot) sysctl -w net.ipv4.ip_no_pmtu_disc=1 # permanent — add to /etc/sysctl.conf net.ipv4.ip_no_pmtu_disc = 1 - Check firewalls and routing
Confirm outbound 25/587 is open and ICMP fragmentation-needed messages are not filtered. A packet capture is often the fastest way to find where the connection dies.
- Contact the destination admin
If the failure is consistent and isolated to one recipient domain, only they can confirm a server-side deferral or a filter on your IP.
Common questions
Is 420 a permanent failure?
No — it is transient (4xx-class), so the message should be retried. The common GroupWise form is a TCP timeout, not a hard bounce.
What is the difference between 420 and 421?
421 is the standard RFC transient "service not available" reply. 420 is non-standard — usually a GroupWise TCP read/write timeout — but you handle both the same way: retry.