This thread probably needs to wind down; once again I will suggest taking discussions of this nature to a list I co-manage:
http://spammers.dontlike.us/ On Tue, Oct 04, 2016 at 01:13:00AM -0400, Sean Greenslade wrote: > On Tue, Oct 04, 2016 at 05:37:33PM +1300, Peter wrote: > > The main problem with this is that one of the primary advantages > > to using a DNSRBL is that it sits in front of SpamAssassin. > > DNSRBL blockign does not require deep inspection of message > > content so it can be checked first and clients blocked without > > wasting valuable server resources on anti-spam techniques that > > do require deep inspection (such as SA). If you're only > > checking the DNSRBLs from within SA itself then you negate > > this advantage completely. > That's true, however as I said in my previous message, I personally > would rather err on the side of accepting a questionable message. I > don't consider it a waste of resources. The problem with this reasoning is that DNSBLs are far more accurate spam detectors than content filters are. And the reason for that is that spam is all about consent (did the sender have permission to send to the recipient?) and not about content. I've seen spam runs from botnets with only a short text message, no marketing at all. It's still spam, coming from a botnet. That's the main reason we have postscreen: to stop the zombie armies. DNSBL scoring is a side benefit which happens to block a bunch of the "grayhat" spammers (list washers, et c.) > There are plenty of valid reasons one may want to accept and store > spam messages. Having a corpus of spam allows for [re]training of > bayesian filters. It also allows for manual inspection of the types > of spam currently in circulation. DNSBL operators do look at some of the spew that hits their spamtrap addresses, yes, and this information helps in tracking malware and botnets. But content-based identification of spam is never going to get around the infinite variations that spammers are using, and will be using. That's the nice thing about a spamtrap: the owner of a proper spamtrap *knows* that the address has never been used legitimately, so every mail it gets is some form of abuse. It's either spam from address harvesting, or confirmation attempts from legitimate bulk senders, wherein the address was falsely "subscribed". (Those usually come from botnets also.) > It allows users the chance to check for false positives and flag > them as such. > > In my opinion, outright rejection should be reserved for messages > that you are 100% sure are spam. And a problem with this is that rejection is the best way for an actual human sender to know that the mail was not delivered. In fact it is far safer to reject than to accept and put in a spam folder. A few users might be conscientious about checking there, but over time that's going to decline (especially if you've stored a bunch of junk known to be from botnets, that no one would ever want.) > I don't consider RBLs to be 100% reliable, Now you're talking FUD. You just lumped every DNSBL into a single category. That's wrong. Do look back at Wietse's post in this thread about ROC. But okay, it's also got a grain of truth. Even Spamhaus can be wrong. (So can SpamAssassin, for that matter; MUCH more frequently IME.) Here's the deal: 1. If someone is sending from a Zen-listed host, they WILL have delivery problems, and not only with you. They need to fix that. If Spamhaus was wrong, they need to contact Spamhaus. 2. If someone is sending from a host listed on multiple DNSBLs, ditto, they WILL have delivery problems. Yes, SORBS is more aggressive, but those SORBS-listed hosts have hit spamtraps which never should be getting mail. 3. It's always better to reject and thus notify the sender, than to provide more reading material for Dave Null. Spamhaus are aware of their position in the community. They do take it seriously. They keep documentation and make samples available. They are about as close to 100% as is humanly possible. And do also note the "human" word. Less reliable DNSBLs are fully automated, at least for listing, if not for delisting. > so I would not use them for message rejection. But of course, your > setup / users / requirements may be different from mine, so don't > take my advice as absolute. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
