<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So, I am thinking it might be a good time to revisit this...<br>
<br>
The amount of spam that's been getting thrown at us lately is quite
prodigious. Just looking at the moderation queue for the "wplug"
mailing list (where at least most spam goes to die, since it's sent
by non-subscribers), there were about 40 attempts to send spam
through that list just in the last 24 hours. I just got 7 new
moderation notifications just in the last 50 minutes.<br>
<br>
We've been using a set of RBL's in our Postfix config (in warning
mode only) for a while now. I need to see if I can find any
existing tools to analyze the logs. Real quick analysis (i.e., just
using "wc"....) shows that RBLs would have blocked about 7100
incoming messages in the last month. On the other hand, of 7 new
moderation notifications just received, 4 of them would have been
blocked by RBL - the other 3 would have gotten through anyway. So
I'm still unsure of the overall benefit, and we'd need to find a
reasonable way to analyze the existing logs to see if the RBLs would
have dropped any legitimate traffic if they'd been turned on "for
real"...<br>
<br>
--Pat.<br>
<br>
<div class="moz-cite-prefix">On 1/30/2014 7:16 PM, Justin Smith
wrote:<br>
</div>
<blockquote cite="mid:a43d4213e0e4548561b0a09d7884c888@adminix.net"
type="cite">
<p>I don't mind at all. I'm willing to defer to someone with more
experience, <br>
particularly if I've done thing on a whim. (And yeah, I do tend
to act on <br>
impulse with certain things.)<br>
<br>
I actually don't have this level of control over Pair's webmail.
You can tick <br>
a checkbox in their Web interface to enable the DNSBLs, and
that's it. We've <br>
been using both SpamAssassin and greylisting up to this point
with <br>
surprisingly little success. <br>
<br>
Prior to enabling the DNSBLs, we'd get about 5-6 spam messages
per day at <br>
work. Since switching them on, that's tapered off to an average
of one. I've <br>
confirmed the improvement anecdotally by asking around.<br>
<br>
For now, then, let's see what results we get in our server logs.</p>
<div>---<br>
<p><strong>Justin </strong><strong>Smith</strong></p>
<p><span style="color: #c0c0c0;">"Intelligence is the ability to
avoid doing work, yet getting the work done."</span><br>
<span style="color: #c0c0c0;">-Linus Torvalds </span></p>
</div>
<p>On 2014-01-30 5:09 am, Vance Kochenderfer wrote:</p>
<blockquote type="cite" style="padding-left:5px;
border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>On Wed, Jan 29, 2014 at 10:08:51PM -0500, Justin Smith wrote:</pre>
<blockquote type="cite" style="padding-left:5px;
border-left:#1010ff 2px solid; margin-left:5px">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.</blockquote>
<pre>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
<<a moz-do-not-send="true" href="http://www.wplug.org/pipermail/wplug-internet/2008-June/000115.html">http://www.wplug.org/pipermail/wplug-internet/2008-June/000115.html</a>>
<<a moz-do-not-send="true" href="http://www.wplug.org/pipermail/wplug-internet/2008-August/000116.html">http://www.wplug.org/pipermail/wplug-internet/2008-August/000116.html</a>>
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
<<a moz-do-not-send="true" href="http://www.spamhaus.org/zen/">http://www.spamhaus.org/zen/</a>>. 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 <<a moz-do-not-send="true" href="http://www.sorbs.net/general/using.shtml">http://www.sorbs.net/general/using.shtml</a>>. 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
<<a moz-do-not-send="true" href="http://www.spamcop.net/fom-serve/cache/297.html">http://www.spamcop.net/fom-serve/cache/297.html</a>>. 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
<<a moz-do-not-send="true" href="http://wiki.centos.org/HowTos/postgrey">http://wiki.centos.org/HowTos/postgrey</a>> - 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
<a moz-do-not-send="true" href="mailto:vkochend@nyx.net">vkochend@nyx.net</a> | good belt of Scotch" -Nick Danger
_______________________________________________
wplug-internet mailing list
<a moz-do-not-send="true" href="mailto:wplug-internet@wplug.org">wplug-internet@wplug.org</a>
<a moz-do-not-send="true" href="http://www.wplug.org/mailman/listinfo/wplug-internet">http://www.wplug.org/mailman/listinfo/wplug-internet</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wplug-internet mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wplug-internet@wplug.org">wplug-internet@wplug.org</a>
<a class="moz-txt-link-freetext" href="http://www.wplug.org/mailman/listinfo/wplug-internet">http://www.wplug.org/mailman/listinfo/wplug-internet</a>
</pre>
</blockquote>
<br>
</body>
</html>