/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
>
>