Is the problem access.db or dnsbl checks?

I'm receiving mail for a user@mydomain on an external MTA.
When the mail gets passed to an internal MTA running SA it gets flagged
as spam. No problem there.
What I am noticing, in the spam reports, is that the sending host is
in blacklists that the external MTA is supposed to be checking.
In the access.db on the external MTA there is a line
To:user@mydomain OK

Does this negate dnsbl checks if the mail is for user@mydomain, or is my
problem elsewhere.

For reference the dnsbl checks are

FEATURE(`dnsbl',`zen.spamhaus.org',`"554 Rejected " $&{client_addr}
"found in zen.spamhaus.org"')dnl
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"554 Rejected " $&{client_addr}
"found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl',`bl.spamcop.net',`"Spam blocked see
http://spamcop.net/bl.shtml" $&{client_addr}')dnl

I have also verified the ability to query the blacklists from the
external MTA's, so DNS doesn't seem to be the problem.

Any insights would be appreciated.
Thanks

Re: Is the problem access.db or dnsbl checks?

Post removed (X-No-Archive: yes)

Re: Is the problem access.db or dnsbl checks?

In article Res
writes:
>On Tue, 8 Jan 2008, NPG wrote:
>
>> To:user@mydomain OK
>>
>> Does this negate dnsbl checks if the mail is for user@mydomain, or is my
>
>Yes it does

Only if you use FEATURE(`delay_checks'), whose main purpose is precisely
to allow such negation. If you don't want that, don't use it - but maybe
read also (in cf/README) about the additional `friend' and `hater'
arguments that can be given to the FEATURE().

--Per Hedeland
per@hedeland.org

Re: Is the problem access.db or dnsbl checks?

* Per Hedeland wrote:
> In article Res
> writes:
>> On Tue, 8 Jan 2008, NPG wrote:
>>
>>> To:user@mydomain OK
>>>
>>> Does this negate dnsbl checks if the mail is for user@mydomain, or is my
>> Yes it does
>
> Only if you use FEATURE(`delay_checks'),
I'm not, however I am using

FEATURE(`lookupdotdomain')
FEATURE(`blacklist_recipients')

I'm not sure if that plays into this or not.
whose main purpose is precisely
> to allow such negation. If you don't want that, don't use it - but maybe
> read also (in cf/README)
I could be wrong, but the def of Ok from cf/README is

Accept mail even if other rules in the running ruleset would reject it.

So may theory is that the RBL checks are somewhere in the ruleset and
the OK lines are canceling them.
However, I am no expert in sendmail rulesets, I leave those alone.

The access.db is set up like

To:validuser1@ourdomain.com OK
To:validuser2@ourdomain.com OK
To:.ourdomain.com REJECT
To:ourdomain.com REJECT

It was set up like this to prevent backscatter, maybe it needs rethinking.

Re: Is the problem access.db or dnsbl checks?

In article NPG
writes:
>* Per Hedeland wrote:
>> In article Res
>> writes:
>>> On Tue, 8 Jan 2008, NPG wrote:
>>>
>>>> To:user@mydomain OK
>>>>
>>>> Does this negate dnsbl checks if the mail is for user@mydomain, or is my
>>> Yes it does
>>
>> Only if you use FEATURE(`delay_checks'),
>I'm not, however I am using
>
>FEATURE(`lookupdotdomain')
>FEATURE(`blacklist_recipients')
>
>I'm not sure if that plays into this or not.

Shouldn't be relevant as far as I can see.

>whose main purpose is precisely
>> to allow such negation. If you don't want that, don't use it - but maybe
>> read also (in cf/README)
>I could be wrong, but the def of Ok from cf/README is
>
>Accept mail even if other rules in the running ruleset would reject it.
>
>So may theory is that the RBL checks are somewhere in the ruleset and
>the OK lines are canceling them.
>However, I am no expert in sendmail rulesets, I leave those alone.

The important part is the "in the running ruleset". With a default
config, the RBL checks are done in check_relay (run as soon as the
client connects, though a rejection doesn't happen until the MAIL
command is issued IIRC), while lookups for 'To:' entries are done in
check_rcpt (run when the client issues a RCPT command). Since this means
that RBL rejection happens before any RCPT commands are issued, there's
no way that 'To:' entries can affect it - sendmail never gets any
recipient addresses to check.

Which is the main reason for delay_checks - when using this, all the
checks are done in check_rcpt, and basically in the opposite order -
which allows an 'OK' entry for 'To:' to "override" the RBL check (which
would happen later in the same ruleset, i.e. it's never done in that
case).

>The access.db is set up like
>
>To:validuser1@ourdomain.com OK
>To:validuser2@ourdomain.com OK
>To:.ourdomain.com REJECT
>To:ourdomain.com REJECT
>
>It was set up like this to prevent backscatter, maybe it needs rethinking.

That should also not affect the RBL checks per above.

So, either you need to look closer at your .mc file to find the problem
(don't forget any additional files that it includes e.g. via a DOMAIN()
macro), and/or post it here, and/or run the debugging checks from Claus
pages (http://www.sendmail.org/~ca/email/chk-dbg.html).

--Per Hedeland
per@hedeland.org

Re: Is the problem access.db or dnsbl checks?

* Per Hedeland wrote:
> So, either you need to look closer at your .mc file to find the problem

I found the problem

my mc file read

define(`confBAD_RCPT_THROTTLE`, `3`)dnl

blah blah

FEATURE(`dnsbl',`zen.spamhaus.org',`"554 Rejected " $&{client_addr}
"found in zen.spamhaus.org"')dnl
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"554 Rejected " $&{client_addr}
"found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl',`bl.spamcop.net',`"Spam blocked see
http://spamcop.net/bl.shtml" $&{client_addr}')dnl

dnl blah blah

instead of

define(`confBAD_RCPT_THROTTLE', `3')dnl

blah blah

FEATURE(`dnsbl',`zen.spamhaus.org',`"554 Rejected " $&{client_addr}
"found in zen.spamhaus.org"')dnl
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"554 Rejected " $&{client_addr}
"found in dnsbl.sorbs.net"')dnl
FEATURE(`dnsbl',`bl.spamcop.net',`"Spam blocked see
http://spamcop.net/bl.shtml" $&{client_addr}')dnl

dnl blah blah

Boy, do I feel dumb.