PROBLEM:

Sendmail can see and use the access.db file, as defined in /etc/sendmail.cf:

Kaccess hash /etc/mail/access

Running Sendmail in test mode behaves properly in that it can see the map,
and returns matches:

% sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /map access 192.168.0.10
map_lookup: access (192.168.0.10) returns RELAY (0)
>

Relayer writes valid entries as normal, and evidenced:

% relayer -view

Relay   -  Host: localhost.localdomain  Value:  RELAY
Relay   -  Host: 192.168.0.10   Value:  RELAY
Relay   -  Host: localhost      Value:  RELAY
Expires -  Host: 192.168.0.10   Time:   Thu Feb  1 19:42:42 2001 (981081758)

However, when users try to relay, they are always denied, no matter what.

SOLUTION:

In this case, sendmail.cf was built by hand, and the following entry was
omitted from the .mc file:

FEATURE(access_db)dnl

If you have built yours from hand, you must have the above entry in your
source file before you create the .cf file with M4.  If you have not built
your file, search for any of the following:

######################################################################
###  SearchList: search a list of items in the access map
###     Parameters:

If your sendmail.cf does not contain anything like the above, that is most
likely the case.  

Problem noted by Aaron Gray

------------------------------------------------------------------------------

<A response to a person saying that sendmail and relayer weren't getting
along with the file created for relayer>



I've also had similar problems, and my solution was quite comprehensive, but
I think it is the better way to do it.

Install the berkeley DB stuff, >= 2.x, say, in /usr/local
Link /usr/include/db.h to the /usr/local/BerkelyDB/db.h (something like that)
keep the old file, of course.

Do the same with the libdb.a file, and it's derivatives -- again, keep them.

Re-install PERL.  I know, wtf?  It includes DB_File by default, and so it 
needs to be linked to the new stuff.  You may get away with installing DB_File
by itself, as part of it's respective package, but by default, Perl includes
it statically -- always available, not a module, so the core needs to be 
updated.

Re-compile sendmail, including makemap.  Make *sure* it picks up the new DB
stuff!

There may be a better way to do this.  Make sure you explore all of your 
options first.  My last experience was on an older Solaris 2.5.1 machine, and
I tried in earnest for over a month, on and off, and finally this was the
only solution that worked for me.  It comes down to two different versions 
of the DB file being created.  *IF* relayer makes the file, life is good, but
sendmail cannot access it.  If it is the other way around, relayer cannot
access it.

Sendmail likely has something like a "hash -o <file>", yes?  The -o makes it
optional, and sendmail will not complain with an error, nor will it fail.  If
you remove the -o option, it will complain and fail as you would expect.

To test it, you can copy your sendmail.cf to another file, say, relayer.cf.
Then, test it as in:

/usr/lib/sendmail -bt -C/your/relayer.cf

It will come up if all is well, and if and when it does, will have a simple
">" prompt.

You can then connect to qpopper, login, have it write (hopefully, if all is
working) your entry, and then, at the sendmail -bt ">" prompt:

> /map access 192.168.1.2

If a match is found, it will show it, else it will report 0 matches.  Obviously,
use your actual IP address :)

Then, you are ready to relay, for one hour, assuming you have the cron job
working every 5 minutes or so.  I may make this into a daemon at some point,
we'll see.  Don't hold your breath though :)-