> From: Kai Schaetzl [mailto:[EMAIL PROTECTED]
> Not sure how you combine that. AFAIR, greylisting is
> tempfailing the first SMTP delivery attempt, correct? Do you
> check the IP with RBLs and then tempfail it? So, you don't
> tempfail *every* connection attempt like "traditional"
> greylisting does?
>
>
Exactly -- with the addition that we do this on
several other criteria than just RBLs.
This avoids pratically all the complaints/negatives*
against "straight greylisting" (i.e., traditional
greylisting) and avoids practically all false positives
from things like RBLs.
* 1) Possible Delay of (new) legitimate email
* 2) Broken legitimate servers which don't resend
Note that these supposed problems with greylisting
are largely handled even by straight greylisting
through the use of whitelists for broken servers
and small delays (a small delay stops almost as
many spambots as will a long delay.)
Also, if for those not familiar with greylisting
the idea is you only TEMP_REJECT "new mail", that
is mail for which you don't have a fairly recent
successful "triplet":
From-IP, From-Sender, To-Recipient
Once greylisting determines that the sending server
can meet the resend requirement there isn't much point
to greylisting that server anyway (since it is going
to meet the greylist requirements in all probability.)
Greylisting lets 10% through, so it isn't the "final"
solution but it lets you use a LOT OF AGGRESSIVE
techniques that would normally be dangerous to "good
mail".
For one, you can use RBLs that would otherwise be
a terrible risk, or even (grey) block on things like
"host reverse name/helo name mismatch" (which will
LOSE a lot of email otherwise.)
Pick any "good" criteria for rejecting email and
turn it into a good but safe method by using greylisting.
Also note that having our SMTP server check RBLs and
then having SpamAssassin score them AGAIN if the mail
gets through, costs VERY LITTLE: we run a local caching
DNS server so those resolutions are only going on the
net just once.
--
Herb Martin
