Hi Philip...
Thanks for the reply. The perl code works fine on our system, however,
we may have figured out the problem. Our guess is:
The router was passing "SomeAcount(_at_)chebucto(_dot_)ns(_dot_)ca" to procmail
and...
on the first try, SomeAccount(_at_)chebucto(_dot_)ns(_dot_)ca was failing the
password
look up because of the "@chebucto.ns.ca".
Procmail was then converting to lowercase AND removing the "@chebucto.ns.ca"
before trying again to look up 'someaccount' in the password file (which
fails)...
We've made an adjustment to the zmailer router.cf and we're going to have
another go at this.. I'll let you know.
dlp
On Thu, 6 Jan 2000, Philip Guenther wrote:
"David L. Potter" <potter(_at_)chebucto(_dot_)ns(_dot_)ca> writes:
We tried to use procmail as the local transport agent on our
SunOS 5.7 system. Zmailer is our mailer. Procmail version is:
procmail-3.14
In this situation, procmail is functioning properly on several test and
all other 'lower-case' accounts.
The problem is that procmail is failing to deliver mail to 'SomeAccount'
with the error that user someaccount does not exist.
We used a wrapper to confirm that procmail is receiving 'SomeAccount' and
account 'SomeAccount' does exist.
A look at the code suggests that the CaseSensitive lookup is failing and
pocmail is switching to case 'insensitive' in a valiant attempt to
deliver the mail.
Yep. So the problem is that the getpwnam() of the original
(non-lowercased) username is failing. You need to figure out why
that's happening. If you have perl installed, try doing the getpwnam()
from there and see what happens:
perl -le 'print join(":", getpwnam("SomeAccount"))'
It that doesn't return anything then something is up with libc or your
password file/database.
Philip Guenther