On 03/28/2015 12:40 AM, Amir Caspi wrote:
On Mar 27, 2015, at 5:12 PM, Axb <axb.li...@gmail.com> wrote:
DOB isn't realtime/zero hour.
That kind of defeats the point, isn't it? I mean, if you wait too
long, it's no longer DOB, it's "few-DOB"...
I would have imagined that a DOB server would operate in a caching
mode where the first query on a domain would cause a whois lookup,
which then generates a cache table entry with the reg date.
Subsequent lookups then don't incur a whois hit, they just check the
cache table. In this way it could be effectively realtime since only
the first query causes a whois load, and it would always return the
correct answer.
I guess that's not the case?
DOB is based on more or less publicly accessible daily TLD zone data
(ICANN ZFA)
You're thinking passive DNS, as done by
https://www.farsightsecurity.com/
I have access to their DNSDB service for a hobby project and it's amazing.
Farsight's NOD service is way out of our means.
Does anyone recommend using the PSBL (Surriel) for sendmail dnsbl? I
see that it's enabled by default in SA, but should I "promote" it to
the sendmail level, or is it too prone to FP?
It works fine for a family server, but I wouldn't use it for rejecting
spam in a client's mailflow.
On a related note... since I implemented SpamCop, Barracuda, and
SpamHaus at the sendmail level, should I disable those RBL lookups in
SA, to prevent double-querying the RBLs for those mails that do get
through? Or does SA check _all_ Received lines, in which case I
should leave it enabled since sendmail only checks the connecting
MTA? (I should note that I _HAVE_ seen RCVD_IN_XBL/PBL/SBL and
RCVD_IN_BL_SPAMCOP_NET pop up not infrequently, despite implementing
dnsbl for those RBLs in sendmail, which means either they're getting
listed in the small interval between sendmail and SA, or SA is
checking more than just the last hop...)
Hard to say without tailing your maillogs.
Though, if you have your trusted/internal SA settings right, extra SA
checks shouldn't be an issue as you may already have most of the data in
your resolver's cache anyway.
