Apply exceptions without calling them proof of safety

A bypass means no greylisting interference, not no security checks.

• Exceptions can be configured for individual IPs, CIDR blocks, host names or domains. Known non-abusive systems that retry unusually or send rarely can be candidates; a known-good reputation list is another possible input. This requires a basis for the exception, not a claim by the sender that it is good (§2.7).
• Section5 item6 recommends a manual override for IPs/blocks and says known high-profile services certain to retry SHOULD bypass the filter. The guide’s manual-known-good example skips only the greylisting gate; it does not skip authentication, abuse checks or SMTP acceptance requirements.
• Greylisting SHOULD NOT be applied to an ADMD submission service for authenticated clients. It also SHOULD not be applied against any authenticated ADMD session. Here submission means handing new mail to one’s service, distinct from an unfamiliar Internet relay. The ADMD determines appropriate authentication mechanisms (§5 item7; RFC6409 context). The drawing states the chosen recommended behavior without changing SHOULD NOT into MUST NOT.
• A temporary4yz reply is not a permanent5yz failure. Non-retrying clients or clients treating all failures as fatal can lose legitimate mail. Excessively aggressive retries can also hit separate rate limits; passing the greylisting interval does not disable such limits (§§3,4.2).
• The security trade-off includes time-critical financial, transactional or security mail. Exceptions confer increased access to mailboxes, which attackers may exploit. An allowlist is not cryptographic verification, and an unfamiliar sender is not necessarily abusive (§§3,8.1).