Prev: mail for mx2.youngguns.nl loops back to myself
Next: Timeout of SMTP servers
From: Stan Hoeppner on 22 Jan 2010 11:58
Noel Jones put forth on 1/22/2010 10:00 AM:

> Nothing is logged because the DNS server gives an authoritive "does not
> exist" answer. That's not an error, it is the expected response when a
> client is not listed in an RBL.

Hi Noel,

I was not venting at Postfix, or Wietse, or any of the devs for that matter, as
much as I was venting at the situation. Vietse, Victor, my apologies if it
seemed I was venting at you. I was not.

My venting should be aimed at Spamhaus. What they've done here is the opposite
of transparency. In the case of Google DNS, Spamhaus has pulled something a bit
underhanded in my estimation. They don't want people using Google DNS to query
Spamhaus zones. That's fine. I have no problem with that. But the way in
which they have blocked access creates a silent discard on mail servers using
Google DNS, or at least Postfix (I can't speak for other MTAs in this regard).

What they should have done is reply with a code that actually generates a
visible log error, so an admin, such as myself, can actually see that something
is wrong. Instead, all I got from my logs was silence. Multiple months of that
deafening silence finally prompted my action as I knew there had to be something
wrong. My A/S special sauce is good, but it's not so darn good that I wouldn't
at least get one zen lookup in a few months. Thankfully it's good enough that
even without any dnsbls I've only been averaging about 1 spam/day in the inbox.
Getting zen lookups working again may not help much, but at least I'll get one
more shot at killing the junk before letting it through.

Anyway, I've got my own resolver up now on my Postfix MX. It appears to be working:

greer:/# host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org A 127.0.0.10
2.0.0.127.zen.spamhaus.org A 127.0.0.2
2.0.0.127.zen.spamhaus.org A 127.0.0.4

--
Stan

From: Mark Goodge on 22 Jan 2010 12:07
On 22/01/2010 16:58, Stan Hoeppner wrote:
>
> My venting should be aimed at Spamhaus. What they've done here is the opposite
> of transparency. In the case of Google DNS, Spamhaus has pulled something a bit
> underhanded in my estimation. They don't want people using Google DNS to query
> Spamhaus zones. That's fine. I have no problem with that. But the way in
> which they have blocked access creates a silent discard on mail servers using
> Google DNS, or at least Postfix (I can't speak for other MTAs in this regard).

They're not doing anything underhand. What they're doing to Google is
exactly the same as they do to any other DNS server which exceeds the
rate limit for the free lookup. This is documented on the Spamhaus
website, along with a note explicitly warning users of free public DNS
resolvers that they shouldn't use Spamhaus as it probably won't work.
And, after all, why should it? if something is being provided for free,
such as an open public DNS resolver, then the operators aren't going to
want to pay for commercial access to something that they can't recoup
money on by charging their own users.

If you're going to use a PBL, such as those provided by Spamhaus, then
you really ought to read the documentation first in order to avoid
obvious bear traps like the one you fell into. It's not the fault of
Spamhaus, Google or Postfix if people don't RTFM.

Mark

From: Stan Hoeppner on 22 Jan 2010 12:33
Mark Goodge put forth on 1/22/2010 11:07 AM:
> It's not the fault of
> Spamhaus, Google or Postfix if people don't RTFM.

I'll give you that. I'd been using zen for years, and sbl-xbl for years before
that. When I changed my resolvers to Google from my current provider's (for
performance reasons, and not just my MX), I didn't go to spamhaus.org to check
and make sure it was ok to do so. It never dawned on me that there would be a
problem. I guess because I'm not a dns monkey (not a racial slur, think
training monkeys) it just didn't occur to me that there would be a problem.

The most interesting part about this, actually, is that when I switched my
resolvers back today, I found Google was apparently blocking them also,
Centurylink's dsl customer resolvers. This happened within the past 3 months.
I don't know what the reason is, but I doubt it's based on query volume given
that these resolvers serve residential and small business dsl customers. They
were working fine before I switched to Google resolvers.

I think it's working again now, though I'll have to wait and see, given my mail
flow and the fact that zen and postgrey only get table scraps, and not many at
that. ;)

--
Stan

From: Noel Jones on 22 Jan 2010 13:13
On 1/22/2010 10:58 AM, Stan Hoeppner wrote:
> Noel Jones put forth on 1/22/2010 10:00 AM:
>
>> Nothing is logged because the DNS server gives an authoritive "does not
>> exist" answer. That's not an error, it is the expected response when a
>> client is not listed in an RBL.
>
> Hi Noel,
>
> I was not venting at Postfix, or Wietse, or any of the devs for that matter, as
> much as I was venting at the situation. Vietse, Victor, my apologies if it
> seemed I was venting at you. I was not.
>
> My venting should be aimed at Spamhaus. What they've done here is the opposite
> of transparency. In the case of Google DNS, Spamhaus has pulled something a bit
> underhanded in my estimation. They don't want people using Google DNS to query
> Spamhaus zones. That's fine. I have no problem with that. But the way in
> which they have blocked access creates a silent discard on mail servers using
> Google DNS, or at least Postfix (I can't speak for other MTAs in this regard).

First remember how RBLs work. An authoritive NXDOMAIN means
the site is not listed, any other answer means the site is
listed. No answer (timeout) is an error that can only mean
"try again". That doesn't leave any option for an automatic
"you're blacklisted" code.

When spamhaus blacklists a site, they answer that every host
is not listed via the normal NXDOMAIN. There are good reasons
to do this, but it doesn't make the job any easier from this
side of the fence.

Since they return the normal "not listed", no MTA or filter
will log anything unusual -- you just won't see any hits.

The up side is that it's unlikely that any MTA or filter will
mistakenly reject or delay mail. If spamhaus just didn't
answer, you would get timeouts in your log but high volume
sites could experience a denial of service if every mail
transaction suddenly took 30-60 seconds longer than normal.
If they list everyone, that creates a worse problem.

I suspect your other provider did something manually to return
timeouts. While this logged the errors that finally brought
this to your attention, this has the very real potential to
cause problems, although it's unlikely that anyone with high
enough volume to suffer from this uses an external DNS. So
while it would be wrong for spamhaus to timeout on everyone,
it's not so bad for an ISP's DNS to return timeouts.

>
> What they should have done is reply with a code that actually generates a
> visible log error, so an admin, such as myself, can actually see that something
> is wrong.

As you see now, this is simply not possible with the current
implementation of RBLs. This isn't a postfix (or any MTA
specific) problem, but rather the way that *all* RBLs are
implemented since their invention.

For this to change, there would need to be an invention of an
agreed-upon method to signal the client that their query
succeeded, but is not honored for some reason. This is
unlikely to happen anytime soon since there is no obvious
technical solution, and it's not a problem the RBL operators
are particularly concerned about.


> Instead, all I got from my logs was silence. Multiple months of that
> deafening silence finally prompted my action as I knew there had to be something
> wrong.

If you're concerned, hack up a cron script to probe the test
addresses and mail yourself the output.

I think we've spent enough time on this.

-- Noel Jones

First  |  Prev  | 
Pages: 1 2
Prev: mail for mx2.youngguns.nl loops back to myself
Next: Timeout of SMTP servers