/dev/rob0: > On Thu, Feb 03, 2011 at 03:01:56PM -0500, Wietse Venema wrote: > > Benny Pedersen: > > > super that its is supported, still missing rhsbl in postscreen ? > > > > There is not yet a user interface design for rhsbl in postscreen. > > Suggestions are welcome. > > I don't see how it would be useful. The only thing available to > lookup at this stage is the client PTR (and verify that), right? > Since the design goal is to keep it fast and minimal, I'd say, no > need for RHSBL in postscreen.
When the "after 220 greeting" tests are enabled, also known as "deep protocol" tests, then the client can be rhsbl blocked based on their helo/sender/recipient information. This would be a "late" check of the client intentions. These "after 220 greeting" tests are not as painful as some greylisting implementations, because positive results have a long TTL of 30 days by default. I remember some greylisters have pretty narrow time windows. Otherwise, postscreen's "after 220 greeting" tests add just one more step to the greylisting delays. If a client is not willing to connect three times, that may be a problem for some, but it is not a problem for me. Wietse > smtpd gets to look up the HELO and sender and recipient, as well as > the client PTR. That's where RHSBL makes most sense, in smtpd. > -- > Offlist mail to this address is discarded unless > "/dev/rob0" or "not-spam" is in Subject: header > >