Dan Lists:
> On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema wrote:
> >
> > I will not base Postfix development on UNDOCUMENTED return values.
> > That is unmaintainable.
>
> I've brought it up on the FreeBSD lists. I suggested that it is a bug
> for getpwnam_r to act the way it is. I'll probabl
On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema wrote:
>
> I will not base Postfix development on UNDOCUMENTED return values.
> That is unmaintainable.
I've brought it up on the FreeBSD lists. I suggested that it is a bug
for getpwnam_r to act the way it is. I'll probably end up submitting
a bug
Dan Lists:
> > It has NOTHING TO TO WITH THREADS.
In particular, getpwnam() on top of *SQL etc. return null (i.e.
user not found) when the database is unavailable. There is no
official API for getpwnam() to indicate "I don't know" because
getpwnam() is not supposed to return in such cases.
As do
On Tue, Dec 4, 2012 at 5:48 AM, Wietse Venema wrote:
>> Taking a quick look at the source, it looks like 2.8 does not use the
>> thread-safe getpwnam_r. It does not appear that postfix is threaded,
>> so it should be safe to not use getpwnam_r.
>
> It has NOTHING TO TO WITH THREADS.
>
> Postfix
Dan Lists:
> > Postfix avoids using using getpwnam() because it is fundamentally
> > broken on lots of systems (reporting "user does not exist" after
> > failure to complete the request).
> >
> > You can force Postfix to use getpwnam() if you know that you
> > will never use *SQL or LDAP etc. datba
On Mon, Dec 3, 2012 at 7:42 PM, Wietse Venema wrote:
> Dan Lists:
>> >> Does postfix need to treat the EINVAL as if the user does not exist?
>> >> Is there a way to change the behavior of getpwnam*?
>> >
>> > EINVAL is not a documented result code.
>> > http://pubs.opengroup.org/onlinepubs/0096953
Dan Lists:
> >> Does postfix need to treat the EINVAL as if the user does not exist?
> >> Is there a way to change the behavior of getpwnam*?
> >
> > EINVAL is not a documented result code.
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/getpwnam.html
> >
> > Postfix is built accoirdin
On Mon, Dec 3, 2012 at 5:14 PM, Wietse Venema wrote:
> Dan Lists:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema wrote:
>> > Dan Lists:
>> >> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up
>> >> passwd info for user: I
Dan Lists:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema wrote:
> > Dan Lists:
> >> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up
> >> passwd info for user: Invalid argument
> >
> > The getpwnam_r() SYSTEM LIBRARY ROUTIN
On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema wrote:
> Dan Lists:
>> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up
>> passwd info for user: Invalid argument
>
> The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error,
> with errno set to EINVAL (Invalid argument).
>
> Fi
Dan Lists:
> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up
> passwd info for user: Invalid argument
The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error,
with errno set to EINVAL (Invalid argument).
Find out why the SYSTEM LIBRARY ROUTINE reports this error.
> Becaus
=deferred (user lookup error)
Because it is a temporary error, it keeps trying over and over. In
the case of aliases, the valid recipients get a copy each time it
retries.
Delivery to users that exist works fine. IMAP and POP work fine. All
other system functions work fine. We've been usin
12 matches
Mail list logo
