Re: Hotmail on sorbs?!? (and eliminating false positives)
On Dienstag, 27. September 2005 07:51 email builder wrote: > The above can probably be done in Postfix with one or two restriction > classes. > > http://www.postfix.org/postconf.5.html#smtpd_restriction_classes > http://www.postfix.org/RESTRICTION_CLASS_README.html > > I'd be curious to hear if anyone else is using this kind of strategy. I could also imagine this: http://www.postfix.org/SMTPD_POLICY_README.html But I'm missing something like smtpd_sender_restrictions = mark_rbl_client ... client_marked = greylist currently, we can only smtpd_sender_restrictions = reject_rbl_client ... But that reject we want to NOT do. mfg zmi -- // Michael Monnerie, Ing.BSc --- it-management Michael Monnerie // http://zmi.at Tel: 0660/4156531 Linux 2.6.11 // PGP Key: "lynx -source http://zmi.at/zmi2.asc | gpg --import" // Fingerprint: EB93 ED8A 1DCD BB6C F952 F7F4 3911 B933 7054 5879 // Keyserver: www.keyserver.net Key-ID: 0x70545879 pgp38dHvDW37U.pgp Description: PGP signature
RE: Hotmail on sorbs?!? (and eliminating false positives)
--- Herb Martin <[EMAIL PROTECTED]> wrote: > > I am new to postfix and spamassassin, but we are already > > using greylist, and I liked a lot what you said here. > > > > How can I greylist messages by means of RBL checking? How > > should I setup Postfix to do that? > > > > Regards, > > Carlos. > > I am not a Postfix expert, and cannot really call myself > an Exim expert either but the strategy goes something like > this: > > During (various) SMTP ACL (Access Control Lists) run the > checks for things like RBL etc (this is easy in Exim) and > mark the results (in either an ACL variable or by adding > a header.*) > > * Header had the disadvantage of requiring the Greylist > check to wait until "SMTP DATA" time where the headers > are available when all we really need is > SenderIP-FromName-RCPT which are all available by > RCPT ACL time. > > When you have made all of your checks, and before checking > SpamAssassin, run the Greylist on any message that was > "flagged" above -- if the greylist returns true this is > where we tempfail (Defer in Exim) the message. The above can probably be done in Postfix with one or two restriction classes. http://www.postfix.org/postconf.5.html#smtpd_restriction_classes http://www.postfix.org/RESTRICTION_CLASS_README.html I'd be curious to hear if anyone else is using this kind of strategy. Thanks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Hotmail on sorbs?!? (and eliminating false positives)
> I am new to postfix and spamassassin, but we are already > using greylist, and I liked a lot what you said here. > > How can I greylist messages by means of RBL checking? How > should I setup Postfix to do that? > > Regards, > Carlos. I am not a Postfix expert, and cannot really call myself an Exim expert either but the strategy goes something like this: During (various) SMTP ACL (Access Control Lists) run the checks for things like RBL etc (this is easy in Exim) and mark the results (in either an ACL variable or by adding a header.*) * Header had the disadvantage of requiring the Greylist check to wait until "SMTP DATA" time where the headers are available when all we really need is SenderIP-FromName-RCPT which are all available by RCPT ACL time. When you have made all of your checks, and before checking SpamAssassin, run the Greylist on any message that was "flagged" above -- if the greylist returns true this is where we tempfail (Defer in Exim) the message. Presuming that nothing flags the message as needing greylisting or it passes greylisting, run SA. -- if SPAM (or perhaps some special threshold higher or lower than 'normal' spam threshold) AND there is NO greylist flag (it hasn't been greylisted yet) then RUN the greylist check now, after the SA check. The idea is that there is no point in SA checking something that will be greylisted anyway -- and there is no point in greylisting something "twice". -- Herb Martin
Re: Hotmail on sorbs?!? (and eliminating false positives)
Hi !! I am new to postfix and spamassassin, but we are already using greylist, and I liked a lot what you said here. How can I greylist messages by means of RBL checking? How should I setup Postfix to do that? Regards, Carlos. 2005/9/24, Herb Martin <[EMAIL PROTECTED]>: > > 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 > > >
RE: Hotmail on sorbs?!? (and eliminating false positives)
> 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
Re: Hotmail on sorbs?!? (and eliminating false positives)
Herb Martin wrote on Sat, 24 Sep 2005 07:17:06 -0500: > You RISK getting false positives with ANY RBL Of course, yes. One better speaks of a "cost-value ratio" (with cost being "false positives" for your clients and value being the rejected spam and viruses). In this respect the combined Spamhaus list is probably the best. Only a few other RBLs can substantially add to that and still come close to the "cost". It should also be clear that most of the "false positives" aren't FP's by the RBLs definition but by the effect they have on your mail/users. > If you use Greylisting which offers virtually zero false > positives IN CONJUNCTION with quality RBLs like Spamhaus > rbl+xbl then you can eliminate false positives and still > benefit from blocking on such RBLs -- even less reliable > RBLs will work for this. 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? Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de & http://msie.winware.org
RE: Hotmail on sorbs?!? (and eliminating false positives)
> From: Kai Schaetzl [mailto:[EMAIL PROTECTED] > If you want to be safe, then use rbl+xbl.Spamhaus only. It is > safe *and* effective. If you add any other you risk getting > false positives. That is in the nature of RBLs and there is > no reason to complain about that fact or any of these RBLs. You RISK getting false positives with ANY RBL -- while I generally agree about rbl-xbl, they are quite good for me, they both on rare occasions give me false positives. If you get enough email, virtually any RBL will give a false positive sooner or later. Of course if the context is scoring in SA they are among the best choices. If you use Greylisting which offers virtually zero false positives IN CONJUNCTION with quality RBLs like Spamhaus rbl+xbl then you can eliminate false positives and still benefit from blocking on such RBLs -- even less reliable RBLs will work for this. Roughly 90% of those items greylisted will never return. And you will lose nothing (*Note: "nothing" cannot be guaranteed even here, but in practice it is true.) We never reject on a single criteria except obvious things like using our server name or IP in the HELO, or a HELO that claims to be from a known ISP but is an obvious lie on reverse lookup, or things like bad recipients/attempts to relay. Most everything else is used to drive greylisting -- even SpamAssassin-likely-Spam-scores drive greylisting (if the mail has not been previously greylisted). We use several RBLs (in Exim) this way too -- to drive greylisting or in combination with other checks. Then we use RBLs with SpamAssassin to adjust the SA scores for mail that does get through. Result: Drastic reduction in mail needing review, no false positive drops (and practically none in spam catch folders), and practically all spam caught. Greylisting is cool. Combined with things like RBLs and other "spammy suspicious" checks it is nothing but a big win. -- Herb Martin
