On Jun 1, 2007, at 10:03 AM, Rob McEwen wrote:
Now, if you want to use SBL-XBL, that's fine (I do). "Normal"
users on
dynamic addresses don't show up on those lists.
I disagree. True for SBL, but not for XBL.
Consider that there are MANY situations where a small-to-large office
will all share an IP to the outside world. Maybe we are talking about
10 computers... maybe 100... maybe 1000+. All it takes is a single
computer getting a zombie (and this wouldn't be all that rare...
even if the I.T. guy was really good as his/her job!). Once one
such computer gets a zombie... then that IP can easily get listed
on XBL.
But, that would be an address like the server I'm sitting at now,
192.168.0.13, are you going to blacklist EVERY person using
192.168.0.13 on an internal network?
Look at the headers from another of my messages, it went through
several hops before apache.org ever saw it, and I send it directly
from the server. Apache.org SHOULD be using zen or something like it
to verify the server talking to it, but how would Zen identify my
computer on a subnet talking to my server which then goes through a
NAT and then to verizon.net with SMTP AUTH and THEN to apache.org?
Even if you go one server back from verizon.net, you'll find
smpt.interstellar.com is on a dynamic address and is in the Zen list
as such. Why is that a problem?
Received: from [206.46.252.48] (HELO vms048pub.verizon.net)
(206.46.252.48) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun
2007 11:42:28 -0700
Received: from smtp.interstellar.com ([71.116.65.245]) by
vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01
(built Apr 3 2006)) with ESMTPA id
<[EMAIL PROTECTED]> for
users@spamassassin.apache.org; Fri, 01 Jun 2007 13:41:48 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by
smtp.interstellar.com (Postfix) with ESMTP id 4F70B3F06DF; Fri, 01
Jun 2007 11:41:47 -0700 (PDT)
Received: from smtp.interstellar.com ([127.0.0.1]) by localhost
(interstellar.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 29L9yyuekAz6; Fri, 01 Jun 2007 11:41:46 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by
smtp.interstellar.com (Postfix) with ESMTP id 93A373F06D5; Fri, 01
Jun 2007 11:41:45 -0700 (PDT)
Another common scenario is that the end user's computer's IP often
gets placed somewhere in the header by the SMTP server that they
use for sending their legit e-mail. I think that this happens more
often
than not.
So here you have a fairly common situation where MANY outgoing
non spam legit e-mails have an XBL-listed IP somewhere in the header,
but with the actual sending mail server is NOT listed on any spam
blacklists because it simply doesn't send spam.
Exactly, so if you use Zen to scan the headers, you'll get false
positives all over the place.
Suppose also that this expoited computer is not yet spotted and
persists
for weeks. In such a scenario, if ALL spam filters ONLY checked the
actual sending server's IP, then ALL of the spam sent from this
exploited computer would easily be caught... and ALL of the legit
messages sent by that legit e-mail server from users in this office
would NOT be mistakenly blocked...
Seems that before weeks went by, the top server (in our case
verizon.net) would get blacklisted and they'd be talking to us pretty
quickly.
...a perfect world...
...but checking against OTHER IP addresses in the header messes
this all up.
Right, so per the warning on the Zen web page, do NOT use Zen for
scanning the headers or body of the mail. SBL-XBL is fine for that.
