Defer an unfamiliar sender, then recognize a retry

A retry can pass one policy gate without proving that the message is safe or delivered.

• SMTP, the Simple Mail Transfer Protocol, moves mail between servers. An MTA is a Mail Transfer Agent: the sending MTA queues mail and the receiving MTA decides whether to accept it. Greylisting temporarily degrades service for unknown or suspect sources; it is not the name for every temporary SMTP error (§§1–1.2).
• The narrow technique returns a transient 4yz reply, where yz are the last two digits. A fully capable SMTP sender needs retry behavior; some simplistic spamware does not retry. A reply alone cannot tell the sender whether the cause was greylisting or an ordinary resource problem (§§1.1,3; RFC5321 §§4.2.1,4.5.4.1).
• The chosen RCPT-stage example uses 450 and stops before DATA: the receiver records the first attempt, sends the temporary reply back to the sender, and the sender retains the message in its outgoing queue. The sender later makes another attempt, rather than treating 4yz as a permanent 5yz failure (§§2.4,4.2,5). RFC5321 §4.5.4.1 requires queuing and periodic retry (MUST), a delay after failure (MUST), and configurable retry parameters (MUST); in general the interval SHOULD be at least thirty minutes. The first chapter selects thirty minutes, while the later five-minute calculation tests only the receiving policy window, not a recommended sender schedule.
• After a qualifying retry, the selected policy permits further SMTP processing. This is not the final positive reply after DATA, not delivery into a mailbox, and not authentication. Other filters and SMTP outcomes still apply. A spam sender that retries can also pass (§§4.3,5).
• RFC6647 does not specify a new EHLO capability or a Greylist header. Section5 gives no specific code/text recommendation, while explaining that 421 reasonably terminates the connection and 450 reasonably continues it. The 450 example is not mandatory; the separate connection-level example uses421 (§§2.1,5).