You can dump the contents of a db file by doing the following:
db_dump -p access.db
where access.db is the db file.
As an alternative for a good solid pop-before-smtp solution, you may want
to check out the drac daemon at:
http://mail.cc.umanitoba.ca/drac/index.html
There are rpm's available for dracd and qpopper (patched for use with
dracd). All that is needed to get sendmail to work with dracd is a simple
addition of a feature() in the sendmail.mc file. Again, the homepage
describes all of this. We have been using dracd, qpopper and sendmail on
a very busy server without a single problem.
--
Chris Szilagyi
Network Administrator
Esphere Technologies, LLC
(254) 755-0222 x317
[EMAIL PROTECTED]
"A. M. Salim" wrote:
Hi,
Yes, we are indeed running dns on the same box (bind 8) and the symptoms
are almost identical to what you describe. Though I had not observed
the
correlation between upstream connection being bad (if our upstream
connection is bad, it is not bad for hours but typically minutes,
whereas
the relaying problem lasts for hours on end once it happens). Nor have
I
observed 0 length databases (/etc/mail/popauth.db and
/etc/mail/access.db
for example).
I wonder if there is a utility for peeking into, or listing, the
contents
of these db's? Then when the problem happens I can at least get a look
see into the db and see if there is a data corruption or something.
best regards
Mike
> Hmm, in a way that's similar but different from the problem I run into
> myself, but it might be rooted in the same background. Is your server
by
> any chance also running a dns server? I've noticed with my setup that
> sometimes what will happen is that the dns server will do a refresh on
a
> list it holds, and during that time period seems to be unavailable for
> requests, and what ends up happening is that the database for
accepting
> relaying ends up at a 0 length until it fixes itself. I've noticed
this
> particularly during times when an upstream connection is bad, and my
> incoming sendmail connections are taking a very long time to finish.
I'm
> not sure whether the problem is either a) sendmail not letting the
database
> be repopulated when it's receiving a connection or b) the database
just not
> populating properly when the dns server is having trouble for whatever
> reason. But for me, what ends up happening is that *all* relaying
gets
> rejected. Typically it doesn't clean itself up until after the net
> connection clears up.
>
> This situation, while fairly rare for my setup, has led me to start
> considering something like smtp auth instead of pop before SMTP.
>
>
