On Thu, 3 Jun 2004, Jeff Chan wrote: > On Thursday, June 3, 2004, 2:38:40 PM, Joseph Kang wrote: > > > Um... The ability to use DNS RBL checks have been in sendmail for quite some > > time now. If you don't agree with it, take it up with the sendmail > > developers. > > Or just don't use it. You can always not use RBLs in sendmail > (or other MTA) and instead check against RBLs in SpamAssassin and > then be able to adjust the scores there. Using RBLs in the MTA > is a binary decision: drop at the transport level or not.
I'll second Jeff's comment here. RBLs as implemented in Sendmail are a binary decision. Either we *accept* this message or we *do not* (before we even get to the "MAIL FROM:" clause). This can lead to serious consequences, especially with very broad RBLs like SPEWS. I used to think that RBLs were a great idea at the MTA level, but having seen a lot of problems with them (mainly in the level of trust one has in whatever RBL one is using) I'm now of the opinion that blocking at the MTA-level because of an RBL listing (unless *YOU* are maintaing the RBL and accept full responsibility for it) is a poor practise. > > Personally, I find it easier to drop a message from a server listed in an > > RBL prior to attempting delivery than doing so after delivery (for those us > > who aren't using a milter). The operative question here is: "Do you trust the RBL admins' judgement implicitly?" The obvious answer, unless you know them personally, should be "no". Are you willing to risk dropping perfectly legitimate mail? > > Obviously, dropping messages at the MTA via RBL has its own hazards... > > Yes, it can mean missed legitimate messages if the RBL entry is > wrong for your users. Which is also why MTAs include a way to > describe why the message was rejected so a legitimate sender or > their ISP can get themselves off the RBL. Hint: The "noise level" for most admins at ISPs is such that they may never even _see_ what caused a rejection unless a user complains (and loudly, at that). Too, some RBLs are deliberately over-broad, make no bones about it, and are impossible to get out of. "Prove you're not a spammer", they say. They might as well ask, "When did you stop beating your wife?" It's impossible to prove a negative. > > That's the administrator's prerogative. PERSONALLY, I prefer to dump on > > sight. :) The only responsible way to do that is to run your own RBL, and personally accept the consequences for it. Sometimes those consequences can be severe; imagine the wrath of the VP of sales when he misses a big lead from a potential client who happens to have recently inherited an ex-spammer's IP block. > > Cuts down on a ridiculous amount of e-mail and cuts down on the amount of > > junk that gets passed on to our MS Exchange server. > > Yes, and using RBLs in the MTA also cuts down on the messages > even reaching SpamAssassin, which can save quite a bit of CPU. > Like anything else using an RBL in the MTA has tradeoffs that > the system administrator needs to be aware of, including false > positives, choice of lists, etc. A better solution is the use of per-user "lookasides" where SA never gets invoked for certain messages. This is a layer "above" whitelisting as messages never pass through SA and cause the cycle-hit. > That said, they work fine for many people. True, but in my experience the usefulness is limited at best. +------------------------------------------------+---------------------+ | Carl Richard Friend (UNIX Sysadmin) | West Boylston | | Minicomputer Collector / Enthusiast | Massachusetts, USA | | mailto:[EMAIL PROTECTED] +---------------------+ | http://users.rcn.com/crfriend/museum | ICBM: 42:22N 71:47W | +------------------------------------------------+---------------------+
