Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

access map rule for eliminate dnsbl lookup

37 views
Skip to first unread message

Franta Hanzlik

unread,
Jul 17, 2013, 9:18:43 AM7/17/13
to
Hello Sendmail gurus,

I have in access map (/etc/mail/access) rules as these:

Connect:90.183.38.158 OK
Connect:209.85. OK

as method for eliminating DNSBL check for certain IP addresses - in
first case for mails from mailserver at IP=90.183.38.158, and in
second case from mails from mailservers whose first two bytes of IP
address are '209.85' and arbitrary last two.
And my problem: it seems as first rule works as expected, but not
second - IP address which starts with 209.85. are still checked for
DNSBL (at least I see in maillog records as:

Jul 12 13:47:27 srvr sendmail[23545]: r62BlFdu023545: ruleset=check_rcpt,
arg1=<fa...@my.dom>, relay=mail-oa0-f42.google.com [209.85.219.42],
reject=554 5.7.1 Rejected spam as 209.85.219.42 found in dnsbl.sorbs.net

Jul 13 11:56:36 srvr sendmail[24242]: r6F9uFsw024242: ruleset=check_rcpt,
arg1=<va...@my.dom>, relay=mail-ie0-f176.google.com [209.85.223.176],
reject=554 5.7.1 Rejected spam as 209.85.223.176 found in dnsbl.sorbs.net

Where can be problem, or how solve this issue?

Thanks in advance,
Franta Hanzlik

Loki Harfagr

unread,
Jul 17, 2013, 10:24:40 AM7/17/13
to
Wed, 17 Jul 2013 15:18:43 +0200, Franta Hanzlik did cat :
Don't put a dot after the leftmost part of IP@:
-----
Connect:209.85 OK
-----


A. Filip

unread,
Jul 17, 2013, 11:01:59 AM7/17/13
to
It is possible to see the lookups done using the test command below:

echo 'A <1.2.3.4><default><+tag><passthru>' | /usr/sbin/sendmail -d60.5 -bt

--
[Andrew] Andrzej A. Filip

Franta Hanzlik

unread,
Jul 17, 2013, 11:04:29 AM7/17/13
to
Loki thanks, I will tried it. But I was thinking about this syntax before,
and I disclaim it - because it seemed for me as without ending dot there
is impossible cover some cases. In this case (209.85) it is unique, but,
for example, what if I will need avoid DNSBL lookup for IPs where third
byte is one (e.g. for addresses 209.1.*.*)? When I use:

Connect:209.1 OK

then DNSBL lookup will be omitted not only for 209.1.*.*, but (if I
understand this) also for addresses 209.10-19.*.* and 209.100-199.*.*,
yes? Or how I arrange things to be dnsbl lookup omitted only for this
209.1.*.* range? (I wish to be possible use network prefix there, which
is casual way how ISPs have assigned IP blocks (e.g. 209.1.1.128/26) -
but this IMO isn't possible yet, right?

And excuse me, I forgot mention in my first mail, I'm using sendmail
v8.14.4. Maibe I can try compile and build sendmail-8.14.7, when it
could help solve this issue better.

Thanks, Franta Hanzlik

A. Filip

unread,
Jul 17, 2013, 11:19:51 AM7/17/13
to
It will match 209.1.*.* for IP addressees and 201.1 + *.201.1 for domain names.

It may cause problems with (fake) TLD numeric domains (e.g. "1").

Loki Harfagr

unread,
Jul 17, 2013, 1:10:06 PM7/17/13
to
Wed, 17 Jul 2013 17:01:59 +0200, A. Filip did cat :
Note to OP: that check will work with "Connect:" rules if your mention it as
the used tag, example:

echo 'A <209.85.11.111><default><+Connect><passthru>' | /usr/sbin/sendmail -d60.5 -bt

(this is not an innuendo but just because you seemed to pre-interpret the
Ruleset usage and inject too much of your wishes in the process ;-)
(the numbers in IP@ are treated as numbers not as a list of textual digits,
oh well I'll be easier to read with an example again ;-) :
$ grep 473 access
Connect:16.1 473 this IP is really too much

$ echo 'A <16.19.2.333><default><+Connect><passthru>' | /usr/sbin/sendmail -d60.5 -bt | tail -2
A returns: < default > < passthru >

$ echo 'A <16.1.2.333><default><+Connect><passthru>' | /usr/sbin/sendmail -d60.5 -bt | tail -2
A returns: < 473 this IP is really too much > < passthru >

Franta Hanzlik

unread,
Jul 17, 2013, 3:38:24 PM7/17/13
to
Hello Loki and Andrzej, thanks You both for explanation how this rules
works and how test it. Maybe this should be somewhere a bit better
explained (/usr/share/sendmail-cf/README in my distro explain dot at
FQDN string left side, but trailing dot not - it must not be
present??

And, regarding to idea of network prefix usage in access map
LHS - IMO when its usage was so extended with prefixes as
ClientRate/ClientConn/Compat/QGRP/GreetPause/Spam/Try_TLS/...,
then implementimg some as network prefix should not be too
difficult and this IMO could help with clear distinguishing
between FQDN and IPs, and with IPs fine refinements.




Franta Hanzlik

unread,
Jul 31, 2013, 10:27:42 AM7/31/13
to
Thanks - I now understand how it is working.
But, please, one more question: is possible accept mail for specified
recipient(s) and/or from specified sender, even if remote mailserver
is on blacklist (thus usual (enh)dnsbl check did refuse it)?

It is perhaps difficult, as dnsbl check is done (IMO) in CONNECT phase
and thus there would be some mechanism for delaying decision up to
phase when sender and/or recipient will be known as well.
And are some more complex checks as this even possible?

Thanks, Fr. Hanzlik

A. Filip

unread,
Jul 31, 2013, 1:45:09 PM7/31/13
to
Franta Hanzlik <fra...@hanzlici.cz> wrote:
> [...]
> But, please, one more question: is possible accept mail for specified
> recipient(s) and/or from specified sender, even if remote mailserver
> is on blacklist (thus usual (enh)dnsbl check did refuse it)?
>
> It is perhaps difficult, as dnsbl check is done (IMO) in CONNECT phase
> and thus there would be some mechanism for delaying decision up to
> phase when sender and/or recipient will be known as well.
> And are some more complex checks as this even possible?

FEATURE(`delay_checks') delays dnsbl check to 'RCPT TO" reply.
It allows to exclude some recipients from dnsbl checks.
[ see `friend' and `hater' parameter e.g. FEATURE(`delay_checks', `friend') ]

acess table "connect:XXX OK" entries allow to ignore dnsbl checks for
specific sending host(s).
0 new messages