Hello to all,

since activating mimedefang/spamassassin and updating to the newest
sendmail (of the distro I'm using), some of the access.db rules are not
honored anymore.
I'm using (until I'll find some time to update the whole distro)
sendmail 8.13.1 (on SuSE9.2). I've configured two milters, the first is
antivir-milter (avira formerly H&B EDV) and the second is mimedefang
(2.57) with spamassassin (3.14). I also build sendmail.cf and the
access.db newly - stopped sendmail - stopped the milters - started the
milters and started sendmail.

Lines in the access file like the following do not work anymore. Mail is
accepted by sendmail. (whitespace is(are) tab(s))
Connect:221 ERROR:5.7.1:550 Mail from ip 221.x.x.x NOT accepted

Were can I have screwed up thing? Thanks for any .


Some addtl. info:

sendmail.m4:
divert(-1)
include(`/usr/share/sendmail/m4/cf.m4')
divert(0)dnl
VERSIONID(`@(#)Setup for SuSE Linux 8.13.1-custom (SuSE Linux)
2005/07/19')dnl
OSTYPE(`suse-linux')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`greet_pause', `2000')dnl
FEATURE(`smrsh')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`use_client_ptr')dnl
define(`_RELAY_FULL_ADDR_', `1')dnl
FEATURE(`delay_checks')dnl
FEATURE(rhsbl,`dsn.rfc-ignorant.org',`550 Mail from domain $`'&{RHS}
refused. MX of domain do not accept bounces. This violates RFC
821/2505/2821 - see http://www.rfc-ignorant.org/')dnl
FEATURE(rhsbl,`postmaster.rfc-ignorant.org',`550 Mail from domain
$`'&{RHS} refused. MX of domain does not have a working postmaster
address - see http://www.rfc-ignorant.org/')dnl
FEATURE(dnsbl, `dnsbl.njabl.org')dnl
FEATURE(dnsbl, `bl.spamcop.org')dnl
FEATURE(dnsbl, `relays.ordb.org')dnl
MASQUERADE_AS(`somedomain.tld')dnl
FEATURE(`masquerade_envelope')dnl
MASQUERADE_DOMAIN(`somedomain.tld')dnl
MASQUERADE_DOMAIN_FILE(`/etc/mail/local-host-names')dnl
FEATURE(`limited_masquerade')dnl
FEATURE(`generics_entire_domain')dnl
GENERICS_DOMAIN(`mail.somedomain.tld somedomain.tld')dnl
GENERICS_DOMAIN_FILE(`/etc/mail/local-host-names')dnl
define(`confPRIVACY_FLAGS',
`authwarnings,needmailhelo,novrfy,noexpn,noverb,re strictqrun,nobodyreturn')dnl
define(`confSMTP_LOGIN_MSG', `$j - Caution any action will be
logged!')dnl
define(`MILTER')dnl
divert(-1)
INPUT_MAIL_FILTER(`avmilter', `S=inet:3333@localhost,
F=R, T=S:10m;R:10m;E:10m')
divert(0)dnl
define(`MILTER')dnl
divert(-1)
INPUT_MAIL_FILTER(`mimedefang',
`S=unix:/var/spool/MIMEDefang/mimedefang.sock, T=S:5m;R:5m')
divert(0)dnl
DOMAIN(`generic')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
MAILER(`procmail')dnl
MAILER(`uucp')dnl
MAILER(`bsmtp')dnl
MAILER(`fido')dnl
LOCAL_CONFIG
Cwlocalhost mail.somedomain.tld

sendmail:
Version 8.13.1
Compiled with: DNSMAP EGD LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER
MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX
NEWDB NIS
NISPLUS PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB
USE_LDAP_INIT
OS Defines: ADDRCONFIG_IS_BROKEN HASFCHOWN HASFCHMOD
HASGETDTABLESIZE HASINITGROUPS HASLSTAT HASNICE HASRANDOM
HASRRESVPORT HASSETREGID HASSETREUID HASSETRLIMIT HASSETSID
HASSETVBUF HASURANDOMDEV HASSTRERROR HASUNAME HASUNSETENV
HASWAITPID IDENTPROTO IP_SRCROUTE NEEDSGETIPNODE
REQUIRES_DIR_FSYNC USE_DOUBLE_FORK USE_SIGLONGJMP USESETEUID
Kernel symbols: /boot/vmlinux
Conf file: /etc/mail/submit.cf (default for MSP)
Conf file: /etc/sendmail.cf (default for MTA)
Pid file: /var/run/sendmail.pid (default)
libsm Defines: SM_CONF_LDAP_INITIALIZE SM_CONF_LDAP_MEMFREE
SM_CONF_LONGLONG SM_CONF_MEMCHR SM_CONF_MSG SM_CONF_SEM
SM_CONF_SIGSETJMP SM_CONF_SHM SM_CONF_SSIZE_T
SM_CONF_STDDEF_H
SM_CONF_SYS_CDEFS_H SM_CONF_UID_GID DO_NOT_USE_STRCPY
SM_HEAP_CHECK SM_OS=sm_os_linux SM_VA_STD
FFR Defines:
Canonical name: mail.somedomain.tld
UUCP nodename: mail
a.k.a.: mail
a.k.a.: [<my-ipadress as octet>]
Conf file: /etc/mail/submit.cf (selected)
Pid file: /var/spool/clientmqueue/sm-client.pid (selected)

============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = mail
(canonical domain name) $j = mail.somedomain.tld
(subdomain name) $m = somedomain.tld
(node name) $k = mail
================================================== ======

In article <p3qvs3-ktp.ln1@platzl.konrad-gmbh.de> Stefan Schinzel
<sschinzel_keinen_muell_bitte_@gmx.de> writes:
>
>Lines in the access file like the following do not work anymore. Mail is
>accepted by sendmail. (whitespace is(are) tab(s))
>Connect:221 ERROR:5.7.1:550 Mail from ip 221.x.x.x NOT accepted
>
>Were can I have screwed up thing? Thanks for any .
>
>
>Some addtl. info:

You omitted the most important info, log entries showing that the rule
wasn't honored (of course we should take your word for it, but time and
again people complain that something "doesn't work" when the actual
problem is that they haven't understood how it is supposed to
work...:-). Anyway...

>FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl

Drop the -o, which tells sendmail to ignore the map completely on errors
(mentioned "a few" times before here) - in fact drop the whole second
argument (i.e. make it just FEATURE(`access_db')), since the rest is
default except where it's still wrong.

--Per Hedeland
per@hedeland.org

Per Hedeland schrieb:

Thanks for your reply,

[error discription]

> You omitted the most important info, log entries showing that the rule
> wasn't honored (of course we should take your word for it, but time and

Here are some entries of the log:

Sep 5 18:27:26 mail sendmail[26817]: k85GQsmA026817:
from=<customerssupport_570312701265vr@vr-networld.de>,
size=17289, class=0, nrcpts=1,
msgid=<200609051627.k85GQsmA026817@mail.somedomain .tld>,
proto=SMTP, daemon=MTA, relay=81-203-213-215.user.ono.com [81.203.213.215]
Sep 5 18:27:26 mail avmilter[23522]: An alert has been detected - mail
will be accepted and quarantined!
Sep 5 18:27:26 mail avmilter[23522]: Alert! The file
"df-21266-19307365" (sendmail ID: k85GQsmA026817) contains
"Phishing/VolksBKfrau.2"
Sep 5 18:27:27 mail sendmail[26817]: k85GQsmA026817: Milter: data, discard
Sep 5 18:27:27 mail sendmail[26817]: k85GQsmA026817: discarded
Sep 5 18:27:27 mail sendmail[26823]: k85GRRd2026823:
from=AvMilter@mail, size=1628, class=0, nrcpts=1,
msgid=<200609051627.k85GRRd2026823@mail.somedomain .tld>,
relay=uucp@localhost
.................................................. .................
Sep 5 19:31:14 mail sendmail[27056]: k85HUi3O027056:
from=<online-support_id_18750vr@vr-networld.de>,
size=17073, class=0, nrcpts=1,
msgid=<200609051731.k85HUi3O027056@mail.somedomain .tld>,
proto=SMTP, daemon=MTA, relay=[201.232.187.221]
Sep 5 19:31:14 mail avmilter[23522]: An alert has been detected - mail
will be accepted and quarantined!
Sep 5 19:31:14 mail avmilter[23522]: Alert! The file
"df-18226-12668033" (sendmail ID: k85HUi3O027056) contains
"Phishing/VolksBKfrau.2"
Sep 5 19:31:14 mail sendmail[27056]: k85HUi3O027056: Milter: data, discard
Sep 5 19:31:14 mail sendmail[27056]: k85HUi3O027056: discarded
Sep 5 19:31:14 mail sendmail[27062]: k85HVERj027062:
from=AvMilter@mail, size=1599, class=0, nrcpts=1,
msgid=<200609051731.k85HVERj027062@mail.somedomain .tld>,
relay=uucp@localhost
.................................................. .................

Corresponding lines from access db (wasn't changed):

Connect:61 ERROR:5.7.1:550 Mail from ip 61.x.x.x NOT accepted
Connect:81.203 ERROR:5.7.1:550 Mail from ip NOT accepted
Connect:201 ERROR:5.7.1:550 Mail from ip 201.x.x.x NOT accepted

This is how it should work (and how it worked before updating):
if a listed ip connects, sendmail stops the communication with the error
and NO MILTER is activated. Now it seems that the milters are invoked
regardless of the access db entries.

Sep 4 06:14:16 mail sendmail[15236]: k844ECZT015236:
ruleset=check_rcpt, arg1=<user@somedomain.tld>,
relay=[61.249.213.80], reject=550 5.7.1 <user@somedomain.tld>...
Mail from ip 61.x.x.x NOT accepted
Sep 4 06:14:17 mail sendmail[15236]: k844ECZT015236:
from=<customercare-97750941075vr@volksbank.de>,
size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA, relay=[61.249.213.80]

>>FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
>
> Drop the -o, which tells sendmail to ignore the map completely on errors
> (mentioned "a few" times before here) - in fact drop the whole second
> argument (i.e. make it just FEATURE(`access_db')), since the rest is
> default except where it's still wrong.

I have changed this.
You mentioned errors in the map, is there a tool which is able to check
the map syntactically?

Maybe I really don't know how things work, but it worked for over 20
months - a fortunate coincidence.

Thanks in advice.

In article <tlc2t3-o7t.ln1@platzl.konrad-gmbh.de> Stefan Schinzel
<sschinzel_keinen_muell_bitte_@gmx.de> writes:
>Per Hedeland schrieb:
>
>Thanks for your reply,
>
>[error discription]
>
>> You omitted the most important info, log entries showing that the rule
>> wasn't honored (of course we should take your word for it, but time and
>
>Here are some entries of the log:

[log entries showing the problem snipped]

>This is how it should work (and how it worked before updating):
>if a listed ip connects, sendmail stops the communication with the error
>and NO MILTER is activated. Now it seems that the milters are invoked
>regardless of the access db entries.

Well, technically sendmail never stops the communication (the SMTP
protocol doesn't really allow the server to do that), but it will give
error reply/ies in the SMTP dialogue, which should cause the client to
stop (at least in this case).

>>>FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
>>
>> Drop the -o, which tells sendmail to ignore the map completely on errors
>> (mentioned "a few" times before here) - in fact drop the whole second
>> argument (i.e. make it just FEATURE(`access_db')), since the rest is
>> default except where it's still wrong.
>
>I have changed this.

And it still doesn't work? I.e. sendmail runs happily and accepts
messages that it shouldn't? (Of course you must rebuild sendmail.cf and
restart sendmail.)

>You mentioned errors in the map, is there a tool which is able to check
>the map syntactically?

The kind of errors that I was referring to above are not with the syntax
of the text, but with the map being totally unusable - the map file
doesn't exist, or is corrupt, or has permission problems, or - probably
the most common - was built with a different and incompatible version of
Berkeley DB vs the one sendmail is using. If you have this kind of
problems, removing the -o will make sendmail exit with an error message.

In principle a good way to check that the map file is "physically" OK is
to run 'makemap -u' on it - it's just that the most common cause of the
most common problem is that you have built makemap and sendmail with
different/incompatible versions of Berkeley DB (e.g. forgot to upgrade
makemap when you upgraded sendmail). In that case makemap will of course
happily dump the map file that it has created, but sendmail can't read
it.

Regarding the syntax of the text, the only reasonable way to check is to
run sendmail in -bt mode and verify that you get expected results -
using /map for starters, but for full check you'll need to run the rules
that use the particular entries - that's the only place that "knows" the
details of the syntax.

>Maybe I really don't know how things work, but it worked for over 20
>months - a fortunate coincidence.

Well, you changed a lot - upgraded sendmail and started using milters. I
don't think your particular milters can have a bearing on your problem
as they only do content checks I believe (i.e. you have to go the DATA
phease in SMTP before they come into play, and you shouldn't be able to
with a working Connect: reject in access db), but of course removing
them as one step in debugging may be useful if none of the above s.

--Per Hedeland
per@hedeland.org

Per Hedeland schrieb:
> In article <tlc2t3-o7t.ln1@platzl.konrad-gmbh.de> Stefan Schinzel
> <sschinzel_keinen_muell_bitte_@gmx.de> writes:
>>Per Hedeland schrieb:
>>
>>Thanks for your reply,
>>
>>[error discription]
>>
>>> You omitted the most important info, log entries showing that the rule
>>> wasn't honored (of course we should take your word for it, but time and
>>
>>Here are some entries of the log:
>
> [log entries showing the problem snipped]
>
>>This is how it should work (and how it worked before updating):
>>if a listed ip connects, sendmail stops the communication with the error
>>and NO MILTER is activated. Now it seems that the milters are invoked
>>regardless of the access db entries.
>
> Well, technically sendmail never stops the communication (the SMTP
> protocol doesn't really allow the server to do that), but it will give
> error reply/ies in the SMTP dialogue, which should cause the client to
> stop (at least in this case).
>
>>>>FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
>>>
>>> Drop the -o, which tells sendmail to ignore the map completely on errors
>>> (mentioned "a few" times before here) - in fact drop the whole second
>>> argument (i.e. make it just FEATURE(`access_db')), since the rest is
>>> default except where it's still wrong.
>>
>>I have changed this.
>
> And it still doesn't work? I.e. sendmail runs happily and accepts
> messages that it shouldn't? (Of course you must rebuild sendmail.cf and
> restart sendmail.)
>
>>You mentioned errors in the map, is there a tool which is able to check
>>the map syntactically?
>
> The kind of errors that I was referring to above are not with the syntax
> of the text, but with the map being totally unusable - the map file
> doesn't exist, or is corrupt, or has permission problems, or - probably
> the most common - was built with a different and incompatible version of
> Berkeley DB vs the one sendmail is using. If you have this kind of
> problems, removing the -o will make sendmail exit with an error message.
>
> In principle a good way to check that the map file is "physically" OK is
> to run 'makemap -u' on it - it's just that the most common cause of the
> most common problem is that you have built makemap and sendmail with
> different/incompatible versions of Berkeley DB (e.g. forgot to upgrade
> makemap when you upgraded sendmail). In that case makemap will of course
> happily dump the map file that it has created, but sendmail can't read
> it.
>
> Regarding the syntax of the text, the only reasonable way to check is to
> run sendmail in -bt mode and verify that you get expected results -
> using /map for starters, but for full check you'll need to run the rules
> that use the particular entries - that's the only place that "knows" the
> details of the syntax.
>
>>Maybe I really don't know how things work, but it worked for over 20
>>months - a fortunate coincidence.
>
> Well, you changed a lot - upgraded sendmail and started using milters. I
> don't think your particular milters can have a bearing on your problem
> as they only do content checks I believe (i.e. you have to go the DATA
> phease in SMTP before they come into play, and you shouldn't be able to
> with a working Connect: reject in access db), but of course removing
> them as one step in debugging may be useful if none of the above s.

Thank you Per for your very detailed answers. I agree with you that the
milters aren't the problem.

It is a problem with the access.db.
I just build up a simple new one for testing and it worked. So there
shouldn't be a version mismatch between makemap's and sendmail's db
implementation.
But on the other hand i cannot find any error in the original access
file. It couldn't be a size problem, could it?
(about 10000 lines by now). Now I will build up a new access files piece
by piece.

>
> --Per Hedeland
> per@hedeland.org

Regards Stefan

In article <1835t3-cv.ln1@platzl.konrad-gmbh.de> Stefan Schinzel
<sschinzel_keinen_muell_bitte_@gmx.de> writes:
>
>It is a problem with the access.db.
>I just build up a simple new one for testing and it worked. So there
>shouldn't be a version mismatch between makemap's and sendmail's db
>implementation.
>But on the other hand i cannot find any error in the original access
>file. It couldn't be a size problem, could it?
>(about 10000 lines by now). Now I will build up a new access files piece
>by piece.

No, 10000 lines is nothing as far as Berkeley DB is concerned - it may
be quite a lot as far as the human maintainer of the text file is
concerned though.:-) You probably have some entry/ies that override the
desired ones somehow, so building it up piece by piece may be the way to
go to find that. See also the debugging hints at:
http://www.sendmail.org/~ca/email/chk-dbg.html

--Per Hedeland
per@hedeland.org