RE: best of RBLs without the FPs
> Sorry, your subsequent emails answered this -- SA seems to be > the other tool that pushes a message into the greylist zone. > With these two (two right? > not any more?) tools driving your greylisting, ... Some other things like SPF fail or softfail too. (Too many people try to "BLOCK" on SPF softfail but at least in theory it is safe to block on SPF softfail.) Most two-letter country codes IF the HELO name doesn't validate, things like that. Anthing that looks like a dial/dynamic address, although many people would just block on these. The point is you can send anything through greylisting and virtually eliminate ANY false positives. But a low false positive rate mechanism through the greylist method means that it makes a "good" method great in terms of avoiding FPs and let's about 9-10% through. > I'm curious how many > (suspicious) mails make it to your spam buckets (or even to > your inbox)? We are not a big system, a few thousand mails a day and about 60% WERE spam before instituting this method. 90% of the spam never reaches SA so we are down from like 1000-1500 spams (received) per day to about 100 or so that we must review. These are not exact figures and might be off by 50% or so (low probably), but the percenctage is correct. And (I didn't mention) that our users have SpamBayes on their system so if anything gets through it is almost always caught there -- and we have them "forward as attachment" back to a SPam/Ham reporting address. -- Herb Martin > -Original Message- > From: email builder [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 27, 2005 1:54 AM > To: users@spamassassin.apache.org > Subject: RE: best of RBLs without the FPs > > > > --- email builder <[EMAIL PROTECTED]> wrote: > > > > But again, since almost no legitimate email is ever > greylisted only > > > almost nothing DESIRABLE EVER gets delayed. > > > > So you ONLY greylist what the RBLs tell you is on their > list? Maybe I > > need to go back and re-read your original email, which I skimmed > > perhaps too lightly... because even back in the day before we used > > greylisting (we use "straight"), and only had something > like four RBLs > > rejecting mail outright, we still saw a lot of spam getting through > > (for SA to score). So I just can't imagine that selective > greylisting > > of whatever is on the RBLs will catch nearly as much as > you'd want it > > to. What are your other mechanisms for tempfailing beside RBL? > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection > around http://mail.yahoo.com >
RE: best of RBLs without the FPs
--- email builder <[EMAIL PROTECTED]> wrote: > > But again, since almost no legitimate email is ever > > greylisted only almost nothing DESIRABLE EVER gets > > delayed. > > So you ONLY greylist what the RBLs tell you is on their list? Maybe I need > to go back and re-read your original email, which I skimmed perhaps too > lightly... because even back in the day before we used greylisting (we use > "straight"), and only had something like four RBLs rejecting mail outright, > we still saw a lot of spam getting through (for SA to score). So I just > can't imagine that selective greylisting of whatever is on the RBLs will > catch nearly as much as you'd want it to. What are your other mechanisms > for > tempfailing beside RBL? Sorry, your subsequent emails answered this -- SA seems to be the other tool that pushes a message into the greylist zone. With these two (two right? not any more?) tools driving your greylisting, I'm curious how many (suspicious) mails make it to your spam buckets (or even to your inbox)? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: best of RBLs without the FPs
> But again, since almost no legitimate email is ever > greylisted only almost nothing DESIRABLE EVER gets > delayed. So you ONLY greylist what the RBLs tell you is on their list? Maybe I need to go back and re-read your original email, which I skimmed perhaps too lightly... because even back in the day before we used greylisting (we use "straight"), and only had something like four RBLs rejecting mail outright, we still saw a lot of spam getting through (for SA to score). So I just can't imagine that selective greylisting of whatever is on the RBLs will catch nearly as much as you'd want it to. What are your other mechanisms for tempfailing beside RBL? __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
RE: best of RBLs without the FPs
> On Sonntag, 25. September 2005 08:54 Herb Martin wrote: > > [detailed description snipped] > > If a message gets by all this and is spammy then drop it > into one of > > two "spam catch accounts" for review. > > Seems to me most of this is "hand made" stuff, and quite a > good concept, BTW. Maybe it would be good to integrate > this/such a policy in SA. Is there any developer of SA > already working on it? If it makes the world safer, it would > be nice everybody [who wants] can implement it. > > mfg zmi There is a Greylist plugin for SpamAssassin but I don't understand it's strategy or purpose... 1) It makes no conceptual sense to me on the surface to ask SpamAssassin to "score for greylist" when SA is not a mail "filter" but rather a classifier that lets the "real mail filter" (e.g., your MTA access controls) reject, accept, or defer the message. 2) I don't want to SA check a message that is going to be greylist deferred even when SA hasn't run yet. (most of the time) 3) Sometimes I do want to Greylist AFTER SA tells me the message is especially Spammy. (occasionally) 4) Since my method is working (and fits those criteria above) I haven't really investigated the available plugin to understand how those issues are addressed or violated. (Lack of knowledge on my part.) I would be interested to hear another point of view from those who understand the SA Greylist plugin -- Herb Martin
Re: best of RBLs without the FPs
On Sonntag, 25. September 2005 08:54 Herb Martin wrote: > [detailed description snipped] > If a message gets by all this and is spammy then > drop it into one of two "spam catch accounts" for review. Seems to me most of this is "hand made" stuff, and quite a good concept, BTW. Maybe it would be good to integrate this/such a policy in SA. Is there any developer of SA already working on it? If it makes the world safer, it would be nice everybody [who wants] can implement it. 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 pgpkIEUCTqxKp.pgp Description: PGP signature
RE: best of RBLs without the FPs
> -Original Message- > From: Michael Monnerie [mailto:[EMAIL PROTECTED] > That sounds interesting. > > > Also, for us SpamAssassin in is TOO LATE in the chain 95% of > the time. > > We've already greylisted most things by the time SA runs (and thus > > avoid the expense of SA processing if the mail is not from a > > reasonably functional SMTP server.) > > Is SA before or after greylist? Both. Allow me to clarify... > I'm not sure I understood you. You do > - reject on some hard criteria Yes. > - check RBLs, SA assign scores Not quite. checking RBLs and other "soft" criteria (but NOT SA yet), greylist if matches occur. > - if some SA hit, greylist Yes, but only for the smaller portion of emails which make it this far. For those messages that are never greylisted by the initial checks, or which return after greylisting we check SA. For those which SA scores beyond a certain threshold (might be greater or less than actual Spam threshold) we greylist -- but only those that have not already made it past greylisting due to those RBL and other soft criteria. The (near) full sequence is this (missing are most of the various whitelists that will bypass a step): Hard checks -- reject RBL and soft checks during up to RCPT time greylist if suspicious (Virus checks and illegal file attachments, e.g, .pif -- reject SA check if threshold exceeded and NOT previously greylisted, then greylist (SA is bypassed for some mailing lists which discuss spam itself.) Also there are some additional hard checks on subject words, charsets/encodings but these are only performed on messages which exceed a (separate) SA threshold Example: If something is 30+ points spammy then if the charset is from Russian we don't likely want it, even though I, formerly, spoke a little Russian and can read the charset passably. If a message gets by all this and is spammy then drop it into one of two "spam catch accounts" for review. There are two such accounts, one for likely spam and the other for "high score" spam. This division makes review much easier. I hope that is clear -- it is difficult to state plainly since much of this is predicated on previous tests... -- Herb Martin
Re: best of RBLs without the FPs
On Samstag, 24. September 2005 19:26 Herb Martin wrote: > SA threshold exceeded will cause a non-greylisted message > to be sent through the greylist process. This can happen > at most once per message (even when resent) but normally > happens on only a small percentages since everything that > was otherwise suspicious got greylisted initially. That sounds interesting. > Also, for us SpamAssass in is TOO LATE in the chain > 95% of the time. We've already greylisted most things > by the time SA runs (and thus avoid the expense of SA > processing if the mail is not from a reasonably > functional SMTP server.) I'm not sure I understood you. You do - reject on some hard criteria - check RBLs, SA assign scores - if some SA hit, greylist Is SA before or after greylist? 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 pgpwLgNYrEmgY.pgp Description: PGP signature
Re: best of RBLs without the FPs
On Sep 24, 2005, at 2:41 PM, Rob McEwen wrote: Herb asked: What makes you uncomfortable? There really are only two issues: 1) Delay of legitimage email 2) Broken legitimate servers that won't resend Herb, Many web page event-driven e-mails may not have a re-try mechanism. Those web page, event-driven e-mails should be submitting the form to the web server from whence they came, and the web server should submit the message to its local MTA. That local MTA, if the webmaster and the postmaster are on the same page, should whitelist the web server. Thus, the web server doesn't need to re-try. Re-trying can be left to their local MTA. Then it's a question of "why is that MTA not re-trying". (and, frankly, if the web server is NOT going through it's local MTA, then I think that qualifies as "misconfigured enough to be shunned by any responsible postmaster of a remote MTA")
RE: best of RBLs without the FPs
> But I have solved this problem forevermore by placing the
> following override in my DNS server:
>
> // American Express ;
> zone "34.32.193.list.dsbl.org" in { type master; notify no;
> file "master/null.zone"; }; zone
> "34.32.193.sbl-xbl.spamhaus.org" in { type master; notify no;
> file "master/null.zone"; }; zone "34.32.193.dnsbl.sorbs.net"
> in { type master; notify no; file "master/null.zone"; }; zone
> "34.32.193.dnsbl.njabl.org" in { type master; notify no; file
> "master/null.zone"; }; zone
Why not just a single Whitelist zone checked before
your blacklists, and thus bypassing them?
This is what we do first (in Exim) -- accept whitelist
and only check RBLs if the whitelist is not matched.
Only takes one zone and it's a easier to add entries
to that.
--
Herb Martin
RE: best of RBLs without the FPs
> Herb asked: > >What makes you uncomfortable? There really are only two issues: > >1) Delay of legitimate email > >2) Broken legitimate servers that won't resend > > Herb, > > Many web page event-driven e-mails may not have a re-try > mechanism. And I think that some legit opt-in lists and > newsletters also might be sent on a 1-pass scenario. ... in > addition to what you've conceded. But these web page emails are not likely to be on RBLs if they are running on legitimate email servers AND are not open relays etc, and many/most such pages actually send their email through some SMTP server precisely so they will not need to deal with retries etc. I worried about this with my OWN customer web page email (to me only) but realized that I was going to have it use a reliable SMTP server anyway. (One that an outside sender cannot use.) But whitelisting can take care of that... > I don't see how a "greylisting-whitelist" could keep up with > the multitude of scenarios, even if these are all low > frequency percentage-wise. There just aren't that many in our experience -- greylistd comes with a nice whitelist (or broken servers) and you can add more. But this does not simplify things so it is important for you to know that we have only done this once right after installing the greylist daemon. It just doesn't happen that we lose mail from web forms. How much LEGITIMATE email do you get (or does anyone get) from "unknown" web forms? > However, I do see how your method is an excellent way to both: > > (1) minimize the problems of greylisting by going after what > is almost always spam in the 1st place > > AND > > (2) minimize the problems of FPs on RBLs since the legit mail > will almost always make it past the greylist. > > Therefore, I don't knock your system... maybe I just need to > test the waters and get a little more comfortable with it. Testing is good. Depending on your email server this is easy -- with Exim I just used a WARN on the greylist for a couple of days, then switched it to DEFER (which is a temp reject as opposed to a DENY.) By the way there is an "add-on SA Plugin" that does greylisting but I don't see the point of that as SA is NOT really a spam filter but a content classifier and only gives your MTA etc the info it needs to decide what to do with the email. Also, for us SpamAssassin is TOO LATE in the chain 95% of the time. We've already greylisted most things by the time SA runs (and thus avoid the expense of SA processing if the mail is not from a reasonably functional SMTP server.) > I fact, I probably will do this eventually... and I'm most > interested in putting it to use on only those messages which > just barely got caught and/or which just barely didn't get > caught by my current spam filtering. I'm kind of excited to > see if this can squeak a few tenths of a percent better > filtering out of my filter without generating FPs. It will (help that is) but the key to what I am suggesting (and doing) is that YOU get to decide. We still use SpamAssassin for all the hard cases (and even to drive a small amount of email through the greylist). If I had to give up one it would be Greylisting since SpamAssassin is a more comprehensive and general tool. So, all of those "excellent" RBLs that you trust can still be used to REJECT, and the flaky ones that Greylist doesn't stop can be used to SCORE in SpamAssassin. This latter is true for ANY test you choose. Some are reliable enough to reject (or even accept) and some are still going to get by Greylisting (about 10% of what we feed through greylisting "comes back" again -- and truthfully almost none of that is actually Ham.) But of course, in our system NONE of what is rejected by such "suspicion driven greylisting" is HAM.. > ONE MORE THOUGHT: > In general, I think that they greylist-only people (NOT Herb, > btw) are just lazy and are willing to make due with an > inferior system which is brainless and easy... But this also > the problem with brain-less Bayesian-only filters and, > consequently, the spammers found ways to beat the Bayesian > filters. You know, there is a similarly easy way for them to > beat greylisting, too... Defense in depth is the key. Trying to do that efficiently is critical for systems with high mail volumes. One of the useful features of my greylist mechanism is that is REDUCES the load both in receiving mail bodies AND in processing them through SpamAssassin. Oddly enough my BAYES_99 and BAYES_95 in SA give 0% false positives and hits 70-80% of spam, pretty good for BAYES_99 +BAYES_95 but if this seems low to others it's important to remember we are knocking down (over?) 90% of Spam before SA even sees it. One of the big advantages of this method is not that SA couldn't classify it but rather no human needs to later review the greylist defers that never return. If there WERE an FP, the sender would (almost certainly) get a Non-Delivery report from his O
RE: best of RBLs without the FPs
Michael Monnerie said:
>But as for Rob's way of doing things: Again this involves manual
>whitelists. It would be nice if there were automated things, as manual
>stuff tends to be error prone, outdated and not updated :-(
Interestingly, just this evening, a legit message sent to my server was
listed by dsbl.
This was a legit NOT-phish American Express e-mail sent from an IP address
that is the most often used legit American Express server on their corporate
network.
SEE:
http://www.senderbase.org/search?searchBy=organization&searchString=American
%20Express%20Europe%20Ltd
notice that the most used IP is
193.32.34.74
"74.34.32.193.list.dsbl.org" currently resolves to "127.0.0.2"
(at least, at the time that I write this)
Have I shaken anyone's faith in RBLs yet?
(also see examples about SBL-XBL and narja in my previous e-mails)
Does anyone hold onto the idea that you can really depend on RBLs by just
finding the magic one or two that never generate FPs?
But I have solved this problem forevermore by placing the following override
in my DNS server:
// American Express ;
zone "34.32.193.list.dsbl.org" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.sbl-xbl.spamhaus.org" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.dnsbl.sorbs.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.dnsbl.njabl.org" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.dnsbl.jammconsulting.com" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.blackholes.five-ten-sg.com" in { type master; notify no;
file "master/null.zone"; };
zone "34.32.193.dnsbl-1.uceprotect.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.dnsbl-2.uceprotect.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.sbl.csma.biz" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.no-more-funn.moensted.dk" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.l1.spews.dnsbl.sorbs.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.l2.spews.dnsbl.sorbs.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.bl.spamcop.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.t1.dnsbl.net.au" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.combined-hib.dnsiplists.completewhois.com" in { type master;
notify no; file "master/null.zone"; };
zone "34.32.193.dnsbl.ahbl.org" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.virbl.dnsbl.bit.nl" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.ubl.unsubscore.com" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.korea.services.net" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.psbl.surriel.com" in { type master; notify no; file
"master/null.zone"; };
zone "34.32.193.dnsbl.rangers.eu.org" in { type master; notify no; file
"master/null.zone"; };
Problem solved.
Sure, this involved a little "manual whitelisting"... but a permanent fix
and I'm finding that, after doing these for the largest IPS and mail
servers, the need to add additional whitelist sections gets more and more
rare... and, again, I continue to receive the benefits of MANY RBLs where
others not using these strategies (I outlined in a previous e-mail) would
either have to dump many RBLs or they'd simply have to live with many FPs.
Plus, I now don't have to worry about American Express messages getting
blocked by what everyone considers to be FP-safe RBLs. (which is a good
place to be at considering the listing I demonstrated today with regard to
DSBL)
Rob McEwen
RE: best of RBLs without the FPs
Herb asked: >What makes you uncomfortable? There really are only >two issues: >1) Delay of legitimage email >2) Broken legitimate servers that won't resend Herb, Many web page event-driven e-mails may not have a re-try mechanism. And I think that some legit opt-in lists and newsletters also might be sent on a 1-pass scenario. ... in addition to what you've conceded. I don't see how a "greylisting-whitelist" could keep up with the multitude of scenarios, even if these are all low frequency percentage-wise. However, I do see how your method is an excellent way to both: (1) minimize the problems of greylisting by going after what is almost always spam in the 1st place AND (2) minimize the problems of FPs on RBLs since the legit mail will almost always make it past the greylist. Therefore, I don't knock your system... maybe I just need to test the waters and get a little more comfortable with it. I fact, I probably will do this eventually... and I'm most interested in putting it to use on only those messages which just barely got caught and/or which just barely didn't get caught by my current spam filtering. I'm kind of excited to see if this can squeak a few tenths of a percent better filtering out of my filter without generating FPs. ONE MORE THOUGHT: In general, I think that they greylist-only people (NOT Herb, btw) are just lazy and are willing to make due with an inferior system which is brainless and easy... But this also the problem with brain-less Bayesian-only filters and, consequently, the spammers found ways to beat the Bayesian filters. You know, there is a similarly easy way for them to beat greylisting, too... simply track the "451 4.7.1" responses and send these again a few minutes later. When this becomes common practice, those who rely on greylisting will find their filters failing big time. Rob McEwen
RE: best of RBLs without the FPs
> From: Michael Monnerie [mailto:[EMAIL PROTECTED] > On Samstag, 24. September 2005 17:48 Herb Martin wrote: > > But again, since almost no legitimate email is ever greylisted only > > almost nothing DESIRABLE EVER gets delayed. > > That depends on your setup. Here, we basically use: > - checks on HELO, SPF, RBL, etc -> 550 reject The discussion context was among those who mistrusted their RBL (or who had experienced actual false positives) Of course in that context you can just reject on ANYTHING that meets YOUR critiria as being safe from those false positives. My method is designed to obtain at least 90% of the value of greylisting with NONE of the disadvantages. > - checks on SA -> accept but mark as SPAM > - greylisting for all that came until here The above is likely backwards from an efficiency point of view -- if you do the greylist first, even before the body is received (at RCPT time) you can avoid the load of receiving the email and the additional load of checking it with SpamAssassin. Especially if you are going to greylist it afterwards and essentially throw away the SA work results. We do however do this for those items that have NOT YET been greylisted but which meet some SpamAssassin threshold (we mark the greylisted mail so it is trivial to determined that it has been done -- i.e., that greylisting again won't help.) SA threshold exceeded will cause a non-greylisted message to be sent through the greylist process. This can happen at most once per message (even when resent) but normally happens on only a small percentages since everything that was otherwise suspicious got greylisted initially. > So every mail gets greylisted the first time for a triple. And this falls into the supposed weaknesses of greylisting or... > The simplest solution for starting with greylisting is to let > it run for 2 months in "dry mode", learning all triplets ...requires such schemes as "delaying 2 months" which isn't necessary or particularly helpful with the method we use. Greylisting with my method can start today. (Of after a suitable interval of sanity checks but certainly not 2 months or even a single week.) Also, the "delay for 2 months" has no effect on "new email correspondents" who must be initially greylisted once you go "live" with greylisting. Using the "suspicious email gets greylisted" method eliminates practically all of the disadvantages and will seldom if ever greylist a legitimate sense, even if this is the FIRST email. For my business users I cannot risk a "new client" getting blocked and do not even want the delay that greylisting causes if it can be (easily) avoided. Notice: Losing a client potentially equals losing thousands or tens of thousands of dollars. > But as for Rob's way of doing things: Again this involves > manual whitelists. It would be nice if there were automated > things, as manual stuff tends to be error prone, outdated and > not updated :-( And none of the greylist discussion should presume that whitelists are not themselves valuable -- these run ahead of the greylist and perhaps as part of it (for those broken servers.) -- Herb Martin
Re: best of RBLs without the FPs
On Samstag, 24. September 2005 17:48 Herb Martin wrote: > But again, since almost no legitimate email is ever > greylisted only almost nothing DESIRABLE EVER gets > delayed. That depends on your setup. Here, we basically use: - checks on HELO, SPF, RBL, etc -> 550 reject - checks on SA -> accept but mark as SPAM - greylisting for all that came until here So every mail gets greylisted the first time for a triple. The simplest solution for starting with greylisting is to let it run for 2 months in "dry mode", learning all triplets (ip,mail from/to) by using postfix's "warn_if_reject", and then remove that "warn_if_reject". As most legit e-mails (at least the most important ones) should have been sent within that 2 months, there's no delay for most "normal" e-mail. But as for Rob's way of doing things: Again this involves manual whitelists. It would be nice if there were automated things, as manual stuff tends to be error prone, outdated and not updated :-( 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 pgpybPRM9Plwp.pgp Description: PGP signature
RE: best of RBLs without the FPs
> From: Rob McEwen [mailto:[EMAIL PROTECTED] > In fact, a good example of positive solutions would be Herb > Martin's recent post about using Greylisting and RBLs > together where the message is not blocked outright based on > RBLs... but, rather, the RBL triggers the greylisting... that > was a great example of a good solution! This is the kind of > thing I'd like to talk about in this new thread. > > Personally, I don't feel comfortable with Greylisting and > there are some disadvantages to greylisting that many admins > can't live with. What makes you uncomfortable? There really are only two issues: 1) Delay of legitimage email 2) Broken legitimate servers that won't resend Most greylist code (e.g., Python Greylistd) comes with a whitelist of the very few servers that will suffer from #2 but notice what the use of RBL and such does: it practically eliminates the need for this whitelist TOO if you pick good drivers: Since those broken servers are also unlikely to suffer from RBL or other problems (or else they would lose a lot of their own mail) it's another way to cut down on problems. So basically a non-issue (broken resend servers) with Greylisting, becomes even less of an issue if you pick good drivers. As to #1, delays -- these are an issue with 'normal' greylisting -- legitimate "first time IP/sender/rcpt" email is delayed 15 minutes to a few hours. But again, since almost no legitimate email is ever greylisted only almost nothing DESIRABLE EVER gets delayed. Remember, we are only greylisting stuff that many (but not all) people would just REJECT. Do you have any other concerns about greylisting? I assure you the two above are irrelevant in practice (but you should check for yourself too.) > Therefore, I have another solution. In reading your solution it seems like a lot of extra work or (script) complications to keep it up when you don't need it. > HERE IS MY SOLUTION: > > (1) weigh the RBLs according to how FP safe they are (For > > (2) I also add points based on how many RBLs (weak or strong) > catch that sending server's IP. The idea here is that any one > (3) Still, occasionally, a large ISP's legit mail server will > But I found a solution here as well. I simply have done an > override on my caching DNS server where I nullify the lookups > for these RBLs. I base this on research I did lookups on It's simpler to just build another whitelist than override the server (unless that is what you mean.) -- Herb Martin
