SMTP Error 420

Is SMTP Error 420 a real SMTP reply code?

Not in the way the number suggests. RFC 5321 §4.2.3 defines SMTP reply codes in three-digit ranges, and the transient ("try again later") connection code is 421 ("Service not available, closing transmission channel"), not 420. There is no 420 reply code in the SMTP standard.

In practice, "420" almost always originates from a Novell / Micro Focus (now OpenText) GroupWise GWIA (GroupWise Internet Agent), which logs a "420 TCP Read Error" or "420 TCP Write Error" when the underlying TCP connection to the remote mail server stalls or breaks mid-transfer. So "SMTP Error 420" is best read as a transport-layer timeout surfaced by GroupWise, not a message a standards-compliant SMTP server returns to your client.

A small number of servers also emit 420 as an ad-hoc transient code, such as Microsoft Exchange's 420 4.2.0 Recipient deferred because there is no Mdb. These are vendor-specific transient deferrals — treat them like any 4xx: retry later.

What causes SMTP Error 420?

For the dominant GroupWise GWIA case, the connection times out during read or write. The most-documented root cause is a Path MTU Discovery (PMTUD) black hole: GWIA sends full-size TCP segments with the "Don't Fragment" bit set, an intermediate router on a smaller-MTU link silently drops them, and the required ICMP type 3 code 4 ("Fragmentation Needed and DF Set") message never reaches the server. The connection stalls and GWIA reports the 420 read/write error.

Other contributing causes:

• A firewall (yours or the recipient's) silently dropping ICMP type 3/4 or the SMTP stream.
• Network instability, packet loss, or an overloaded/congested destination server.
• A vendor-specific transient deferral on the receiving side, such as the Exchange 420 4.2.0 mailbox-routing example above. (Note: greylisting is a separate mechanism and standardly uses codes 450/451, not 420.)

How do I fix SMTP Error 420?

1. Retry first. 420 is transient. A transient deferral typically clears on its own within minutes; a well-behaved mailer (or Courier) will retry automatically.

2. Fix Path MTU Discovery on the GroupWise/Linux host if the GWIA log shows 420 TCP Read/Write Error. Disable PMTUD so the kernel stops setting the DF bit:

# 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

Then reload with sysctl -p. As an alternative to disabling PMTUD globally, allow ICMP type 3, code 4 through your firewall so PMTUD can work correctly.

3. Check firewalls and routing. Confirm outbound TCP/25 (or 587) is open and that ICMP fragmentation-needed messages are not being filtered. A packet trace of the full send is often the fastest way to localize where the connection dies.

4. Contact the destination administrator if the failure is consistent and isolated to one recipient domain — only they can confirm a server-side deferral, hardware fault, or filter blocking your IP.

If you are sending through an API instead of running your own MTA, Courier handles SMTP-level transient failures and retries for you, so a single 420/421 deferral does not require manual intervention.