Re: [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue)
"John Levine" <[email protected]> 6 Jan 2022 17:06:59 -0500
| Newsgroups | gmane.ietf.smtp,gmane.ietf.emailcore |
|---|---|
| Organization | Taughannock Networks |
| Message-ID | <[email protected]> |
It appears that Steffen Nurpmeso <[email protected]> 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