Keep retry identity consistent across mail servers

A distributed mail service needs a consistent view of history.

• MX records identify mail exchangers for a domain. If the first attempt goes to MX-A but the retry goes to MX-B with an independent database, MX-B can see a new tuple and defer it again. Section5 item4 says all inbound border MTAs in one Administrative Management Domain (ADMD: one mail administration) SHOULD share history and policy (§§4.1–4.2,5).
• Alternate MX servers SHOULD share the greylisting database; a primary SHOULD permit alternate-MX relay without greylisting it again. These are recommendations, not a promise that unrelated administrations already share data or a reason to trust every relay (§4.2).
• A shared outbound queue can retry via another MTA with a different IP; DHCP address changes have a similar effect. An exact-IP key changes even if the message is the same. Section5 item5 permits chosen CIDR blocks, such as IPv4/24, or domain grouping, but these MAY heuristics fail for clusters on different networks. The guide does not prescribe/24 as a universal setting (§§4.1,5).
• Network Address Translation (NAT) can cause different MTAs to appear under one IP. After a successful retry from one, the chosen IP-wide exemption also covers others behind that address. Thus a known source IP is not a unique sender identity or proof of good mail (§§4.1,4.3).
• Changing envelope return paths or post-DATA content can likewise change a key and repeatedly defer legitimate mail; infrequent senders can age out. Outcomes include long delays, reordered related messages, or eventual return to sender (§§4.1–4.2).