When systems disagree

Exquisite-gmail red (Photo credit: Wikipedia)

A co-worker recently brought to my attention an interesting problem which involves differing ideas concerning precedence between RFC5321 and RFC3463. The result of the issue is that mail systems may experience unneeded delay in delivering mail.

What’s going on? Gmail is returning the following error for over quota accounts: “452 4.2.2 The email account that you tried to reach is over quota.”

If you have a look at [acp author=”John Klensin” id=”klensin-01″ title=”RFC5321 – Simple Mail Transfer Protocol” year=”2008″ month=”October” year_access=”2015″ month_access=”July” day_access=”15″ url=”http://tools.ietf.org/html/rfc5321″]{title}[/acp], you’ll find that response code 452 has the following definition: “452 Requested action not taken: insufficient system storage.” This should generally be taken to indicate a system issue outside of the hands of the individual recipient/user.

However, if you have a look at the enhanced status code (4.2.2), you’ll find it defined in [acp author=”Gregory Vaudreuil” id=”vaudreuil-01″ title=”RFC3463 – Enhanced Mail System Status Codes” year=”2003″ month=”January” year_access=”2015″ month_access=”July” day_access=”15″ url=”https://www.ietf.org/rfc/rfc3463.txt”]{title}[/acp]’s section 3.3:

X.2.2 Mailbox full

The mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity. The general semantics implies that the recipient can delete messages to make more space available. This code should be used as a persistent transient failure.

This is indicative of a condition that is within the user’s control. In fact, RFC3463 Section 3.4 defines the X.3.1 status code to be the indication of a system storage issue that is outside of the user’s control.

So, we have an response code that indicates a system issue outside of the user’s control (the RFC5321 error) followed by an enhanced status code (the RFC3463 error) that indicates an issue that is within the user’s control. What’s a mail system to do?

In our case, our MTA software chooses to follow the RFC5321 response code. The result of this is that enqueued mail to users with @gmail.com will halt for a timeout period because a 4xy error indicates a temporary system issue and that mail should be retried (“Each reply in this category might have a different time value, but the SMTP client SHOULD try again”).

What would be the best outcome? That would probably be for Gmail to align its RFC5321 response code with its RFC3463 enhanced status code. The [acp author=”Internet Assigned Numbers Authority” url=”http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml” id=”IANA-01″ title=”Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry” year=”2008″ month=”May” day=”29″ year_access=”2015″ month_access=”July” day_access=”15″]{title}[/acp] suggests that RFC5321 response code “521” be associated with RFC3463 status code X.2.2.

On the other hand, what do I think will happen? I think that MTA vendors are going to have to take a look at what Google is doing and special case this particular code set or re-evaluate their decision(s) to follow the RFC5321 response code over the RFC3463 status code.