procmail
[Top] [All Lists]

Re: Problem: procmail as Solaris Local TA

2000-01-07 19:27:30

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


<Prev in Thread] Current Thread [Next in Thread>