[wplug-internet] Spam filters

[Justin Smith]

I don't mind at all. I'm willing to defer to someone with more
experience, 
particularly if I've done thing on a whim. (And yeah, I do tend to act
on 
impulse with certain things.)

I actually don't have this level of control over Pair's webmail. You can
tick 
a checkbox in their Web interface to enable the DNSBLs, and that's it.
We've 
been using both SpamAssassin and greylisting up to this point with 
surprisingly little success. 

Prior to enabling the DNSBLs, we'd get about 5-6 spam messages per day
at 
work. Since switching them on, that's tapered off to an average of one.
I've 
confirmed the improvement anecdotally by asking around.

For now, then, let's see what results we get in our server logs. 
---

JUSTIN SMITH 

"Intelligence is the ability to avoid doing work, yet getting the work
done."
-Linus Torvalds 

On 2014-01-30 5:09 am, Vance Kochenderfer wrote: 

> On Wed, Jan 29, 2014 at 10:08:51PM -0500, Justin Smith wrote:
> 
>> We use Pair Networks for our email at work. The boss had me call them up today because their spam filters weren't cutting it, and the rep I spoke with walked me through setting up DNSBLs. They were so effective that it was almost like flipping and "off" switch. I haven't received a single junk email since then. I was so impressed that I thought I'd give it a shot on our WPLUG mail server. I added three DNSBLs: Spamhaus Zen, Spamcop, and another one whose name escapes me because I'm on the verge of falling asleep.
> 
> This is not inherently a bad idea, but requires thought and
> planning. DNS block lists vary widely in their quality, even
> among multiple lists from the same provider. They *will* block
> legitimate mail if not used carefully.
> 
> Five years ago, I ran a trial of pbl.spamhaus.org. See
> <http://www.wplug.org/pipermail/wplug-internet/2008-June/000115.html [1]>
> <http://www.wplug.org/pipermail/wplug-internet/2008-August/000116.html [2]>
> and the following messages in that thread for details. We ended
> up not using it because the benefit was small on top of our
> existing countermeasures.
> 
> My view on the proposed block lists:
> 
> zen.spamhaus.org - I have a generally favorable impression of
> Spamhaus, but the ZEN list combines four separate lists
> <http://www.spamhaus.org/zen/ [3]>. In my view, the PBL is the
> component list likely to be most stable and best curated, while
> the others have more activity and are more prone to error. This
> is why I started with the PBL in my testing. I would want to see
> good data on false positives for the complete ZEN list before
> using it. The component lists could also be judged/used
> individually.
> 
> dnsbl.sorbs.net - This list is a combination of 11 lists with
> various goals <http://www.sorbs.net/general/using.shtml [4]>. Some of
> these lists have nothing to do with e-mail. I would only consider
> adding them if Spamhaus alone was not effective enough, and the
> data showed it would provide additional gain without false
> positives.
> 
> bl.spamcop.net - SpamCop is based (in part) on user submissions,
> which are not 100% reliable. Even they themselves do not
> recommend outright blocking mail based on their list
> <http://www.spamcop.net/fom-serve/cache/297.html [5]>. My impression
> of SpamCop, admittedly based on hearsay rather than personal
> knowledge, is that they play fast and loose and don't worry too
> much about the consequences of an incorrect listing. They are IMO
> a last resort and I would have to see very compelling evidence
> before using them.
> 
> With any of these, I would want to set check_recipient_access to
> exempt mail addressed to postmaster@ or abuse@ from any DNSBL
> checks. If there is a problem with a list, there needs to be a
> way to contact the admins to work it out.
> 
> For now, I've added warn_if_reject to the DNSBL configuration so
> that matches are logged, but do not result in rejecting mail.
> This will allow us to collect statistics without the risk of
> blocking legitimate mail.
> 
> (For your workplace, you may want to take some of the same
> concerns above into consideration. If most of the people who send
> you e-mail have a pre-existing relationship, it may not be as much
> of an issue. But since WPLUG could potentially get valid mail
> from a wide variety of correspondents, false positives are a real
> problem. I would strongly recommend you look into greylisting
> <http://wiki.centos.org/HowTos/postgrey [6]> - it is extremely
> effective and safe. However, it can introduce annoying delays to
> users who expect e-mail to be "instant," so you need to understand
> its behavior before subjecting your users to it.)
> 
> Sorry for seemingly throwing cold water on your idea, but DNSBLs
> are one of those things that seem simple at first but can result
> in nasty unintended consequences. Please feel free to engage and
> discuss on this issue.
> 
> Vance Kochenderfer | "Get me out of these ropes and into a
> vkochend at nyx.net | good belt of Scotch" -Nick Danger
> _______________________________________________
> wplug-internet mailing list
> wplug-internet at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug-internet [7]
 

Links:
------
[1] http://www.wplug.org/pipermail/wplug-internet/2008-June/000115.html
[2]
http://www.wplug.org/pipermail/wplug-internet/2008-August/000116.html
[3] http://www.spamhaus.org/zen/
[4] http://www.sorbs.net/general/using.shtml
[5] http://www.spamcop.net/fom-serve/cache/297.html
[6] http://wiki.centos.org/HowTos/postgrey
[7] http://www.wplug.org/mailman/listinfo/wplug-internet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wplug.org/pipermail/wplug-internet/attachments/20140130/f174052d/attachment.html