Track the retry window separately from record expiry

A retry too soon is not the same as a stale record.

• Section5 item2 recommends a configurable range in which a retry qualifies. Its default SHOULD be one minute to24hours. A retry after the end SHOULD count as new for greylisting evaluation, resetting first seen. The model chooses inclusive endpoints at60 and86400seconds; this boundary convention and five-minute example are local illustration choices, not new RFC MUSTs.
• In this chosen policy a first sighting at time0 creates a pending tuple and defers. A retry at30seconds is too early: retain first seen0. A retry at300seconds falls in the range and passes the greylisting test (§5 item2). This is elapsed time, not a prescribed wall-clock date or SMTP retry schedule.
• After a successful retry, section5 item1 recommends allowing all further SMTP traffic from that IP regardless of envelope information. The model promotes the IP to known-source history; another envelope from it bypasses this greylisting test, not all other mail filters. A mere first attempt or too-early retry must not make that promotion in this selected policy.
• Section5 item3 recommends a separate inactivity timeout deleting history of IPs with no recent traffic; its default SHOULD be at least one week. The model chooses seven days and deletes at an age greater than or equal to that chosen timeout. Successful known-source traffic refreshes its last-seen time. These selected implementation details do not define universal expiration semantics.
• A late retry at86401seconds is shown as a separate branch from successful promotion: it resets first seen rather than retrospectively proving an earlier success. A site can configure other ranges; retry-range expiry and inactivity expiry must not be presented as one timer (§§3,5).