tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mail.local NSS awareness
On Tue, Apr 29, 2008 at 08:25:41PM +1000, Luke Mewburn wrote:
> On Tue, Apr 29, 2008 at 09:16:06AM +0000, Emmanuel Dreyfus wrote:
> | Hello
> |
> | mail.local assumes that if getpwnam(3) returns NULL, that means the
> | recipient does not exists, and the message shall be dropped. Hence it
> | returns code EX_OK to the MTA.
> |
> | This behaviour does not take NSS into account. NSS source others than
> | file may fail, and they may fail for a temporary condition. In that
> | situation, mail.local should exit with a status code different than
> | EX_OK, so that the MTA understands that delivery should be retried
> | at a later time.
> |
> | As I understand, sendmail expects EX_OK, EX_TEMPFAIL, or EX_UNAVAILABLE,
> | so I propose the patch included below. I don't know how well that cope
> | with other MTA, or if there are other errno like EAGAIN and ETIMEDOUT
> | that should cause EX_TEMPFAIL (temporary failure) instead of
> EX_UNAVAILABLE
> | (permanent failure). Opinions?
>
> POSIX doesn't document that getpwnam() can fail with EAGAIN or ETIMEDOUT;
> I think you'd be relying upon implementation-specific values.
>
>
> Arguably the retry after temporary failure could be dealt with via
> the nsswitch.conf interface, although the NetBSD implementation
> doesn't support that at this time.
>
> NetBSD's nsswitch implementation was inspired by early Solaris 2.x
> (2.3? 2.4?) behaviour; it appears that Solaris 8 (2.8?) now supports
> tryagain=(return|continue|forever|<n>)
> which could be used to force retries on temporary failures "forever"
> or for "n" retries.
>
> Until now there hasn't been a big demand for the "tryagain=(forever|<n>)"
> semantics in NetBSD; if you think it would be useful for you, submit
> a PR so we don't forget about it.
>
Note that I had (have) a version of nss that supported these
additional behaviors (tryagain...). I can't recall right now why
we (Luke and I) couldn't come to an agreement on getting these
changes incorporated into the tree.
Home |
Main Index |
Thread Index |
Old Index