It appears that Steffen Nurpmeso <steffen(_at_)sdaoden(_dot_)eu> said:
These rotations surely have an impact on RFC 6647, 5.,
1. Implement greylisting based on a tuple consisting of (IP address,
RFC5321.MailFrom, and the first RFC5321.RcptTo).
that was not forseeable to this extent in 2012?
Item 5 in section 5 says:
To accommodate those senders that have clusters of outgoing mail
servers, greylisting servers MAY track CIDR blocks of a size of
its own choosing, such as /24, rather than the full IPv4 address.
(Note, however, that this heuristic will not work for clusters
having machines on different networks.) A similar grouping
capability MAY be established based on the domain name of the
mail server if one can be determined.
Is this the problem you are encountering or something else?
In my experience, allowing matches within a /24 in IPv4 or a /64
in IPv6 largely addresses this problem.
How useful is greylisting on
overall and/or on this scale today, and tomorrow?
My small system recently greylisted 21238 sending hosts of which 12745
retried and 8770 didn't. Once a host retries, it isn't greylisted
again unless it hasn't sent any mail for over a month. Spot checks
show that the 40% of hosts that don't retry are almost all spambots,
so it's useful, but not so much we'd change the protocol.
Apropos jck's question, while we might consider revising 6447, this has nothing
to do with 5321 so replies are directed to the ietf-smtp list.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp