[bug]: Greylisting returns permanent error 422 instead of temporary error 421/450

[rcfa]

What happened?

I sent a test message to my server, which was bounced with the following message:

This is a system-generated message to inform you that your email could not
be delivered to one or more recipients. Details of the email and the error are as follows:


<[[email protected]](mailto:[email protected])>: host [mail.test.net](http://mail.test.net/)[12.34.56.78] said: 422
   4.2.2 Greylisted, please try again in a few moments. (in reply to RCPT TO
   command)
Reporting-MTA: dns; [st43p00im-ztbu10073601.me.com](http://st43p00im-ztbu10073601.me.com/)
X-Postfix-Queue-ID: ABCD1234567
X-Postfix-Sender: rfc822; [[email protected]](mailto:[email protected])
Arrival-Date: Sat, 18 Jan 2025 21:29:07 +0000 (UTC)

Final-Recipient: rfc822; *************@*************
Original-Recipient: rfc822;[[email protected]](mailto:[email protected])
Action: failed
Status: 4.2.2
Remote-MTA: dns; [mail.test.net](http://mail.test.net/)
Diagnostic-Code: smtp; 422 4.2.2 Greylisted, please try again in a few moments.
[…]

When I google a 422 error code, I get:
"SMTP Error 422 is a permanent or "5xx" error code returned by a mail server, indicating the rejection of an email message due to the recipient's mailbox or account being over quota or exceeding storage limits. This error denotes that the recipient's mailbox cannot accept new messages until the storage issue is resolved."

It would seem there should be something like a 450 or 454 error code, right?

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

Version

v0.11.x

What database are you using?

RocksDB

What blob storage are you using?

Filesystem

Where is your directory located?

Internal

What operating system are you using?

Linux

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[andreymal]

If I understand RFC 3463 correctly, every error code starting with "4" is temporary

Anyway, I've tested the current implementation of greylisting and it seems to work well

[mdecimus]

Any status code starting with 4 is temporary and the remote host should try delivering the message again later. A bug in the greylist implementation would mean that Stalwart is returning a code starting with 5 (permanent failure) or accepting the message with a 2xx status code.

[rcfa]

As per RFC 821, implementations should NOT invent their own error codes. 422 is not a listed as short code in RFC 821, so while there are many extensions to these three digit short codes beyond the RFC, they are non-standard, and thus can produce allergic reactions in various mail servers. While theoretically 422 should, starting with four, just be a temporary failure, a mail server not being able to interpret it, may decide to bounce permanently not knowing the proper handling of the error.
Given that a major mailer, Apple’s, bounces my test messages specifically quoting that error message, and given that yahoo bounces without any useful comment, indicates that there’s a problem.
Less discerning mail servers are able to deliver messages, so it’s not like nothing gets through.
More detailed comments of mine, below.

[rcfa]

Well, all I can say is that both Apple’s iCloud mailer and yahoo bounce my messages. Yahoo unfortunately doesn’t send much in terms of diagnostics. Apple sends the type of error I quoted in the bug report.

Some other mail goes through.

I’m also not sure, if we’re talking about the same codes. There are the three digit short codes like 404 and then there are the detailed error codes of the form X.NNN.MMM where NNN and MMM can be between 1 and 3 digits long. The RFC you point out describes these detailed error codes, but the Apple mailer may complain about the three digit short code.

Now, as for the detailed error code, I’m not sure why 4.2.2 is used:
4.2.2 Mailbox full
which one would associate with a long term if not permanent problem.
Detailed error codes like:

4.2.1     Mailbox disabled, not accepting messages
4.3.2    System not accepting network messages
4.4.1     No answer from host
4.4.2    Bad connection
4.4.5    Mail system congestion
4.7.0    Other or undefined security status

seem to be much more aligned with the greylisting than

Looking here for the (non-authorative) definition of three digit short codes

4xx	Soft bounces codes
x1x  Informational response
x2x Connection status
x3x Mail system status (not in RFC 821!)
x4x Network and routing status (not in RFC 821!)
x5x Mail delivery protocol status
x7x Security or policy status (not in RFC 821!)

As per RFC 821:

421 <domain> Service not available,
             closing transmission channel
            [This may be a reply to any command if the service knows it
            must shut down]
450 Requested mail action not taken: mailbox unavailable
            [E.g., mailbox busy]
451 Requested action aborted: local error in processing

would seem documented short codes that could be used and should be understood by any compliant server.
In particular RFC 821 states "the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined."

422 not being listed means potentially unspecified server behavior. So picking from the well defined standard codes, 421 and 450 seem safe choices. If one were to logically construct non-standard codes, then maybe 410, 470 would be meaningful, but that would again meaning leaving the scope of RFC 821.

So I’d suggest 421 or 450 as short code, and 4.7.0 as detailed error code, along with the "Greylisted, please try again in a few moments." error text.

[andreymal]

mdecimus didn't reply, but this seems to be fixed in 4eca415, all the new codes (421, 451, 452, 455) are present in RFC 5321 (latest version of the SMTP spec)

(Still not sure about the choice of these short and detailed error codes, though)

[mdecimus]

Also there is this fix to remove IP address from the greylist keys.

BTW personally I do not recommend enabling greylisting because:

• It delays your legitimate email when it should be instantaneous.
• It is practically ineffective in modern times, spammers have adapted and retry failed deliveries.
• Most of the spam nowadays comes from Gmail, MSN and Outlook and theirs servers will obviously retry.