Measure the trade-off and bound the claims

Retry behavior is evidence about behavior, not an authentication method.

• Section6 suggests logging independent spam/legitimate determinations alongside what greylisting would decide, then checking their correlation and legitimate-mail impact. Querying relevant reputation lists can add another comparison. The four-message picture is fictional, not site telemetry or evidence of effectiveness.
• In the chosen observation sample, two independently classified spam examples and two legitimate examples are compared with whether the gate would defer them. One delayed legitimate message and one spam message that passes illustrate that deferral is not a perfect abuse classifier. Counts are illustrative; no universal success percentage is claimed (§§3,4.3,6).
• Section7 explicitly bases the descriptions and recommendations on IPv4 operational experience. IPv6’s larger address space may require different variables or negate benefits; database scale is a concern. Do not carry the chosen IPv4/24 heuristic or the depicted database behavior into a claimed proven IPv6 deployment.
• Database size grows with distinct clients and tuple choices. An attacker can rotate parameters to inflate history; an unavailable database needs a locally acceptable failure policy. Section8.2 does not mandate fail-open or fail-closed. The diagram branches to two named local choices without selecting one as an RFC requirement.
• Greylisting provides no message-content encryption, signature, sender authentication or guarantee against retrying spamware. The specification’s June2012 applicability statement describes a tool among anti-abuse measures, not measured present-day effectiveness or a complete secure-mail recipe (§§1,4.3,6–8).