It's even documented (somewhere) that NULL value means the same as
if the field wasn't even selected by the query.
Ah, so it is, on
http://wiki.dovecot.org/PasswordDatabase/ExtraFields> Not sure how
I missed that. Thanks.
also just as a note, when you go to 1.1 make sure to return
nopassword='Y' if you return a NULL password or dovecot will complain
and will fail auth.
On Feb 4, 2008 12:48 PM, WJCarpenter <[EMAIL PROTECTED]> wrote:
>
> >> 2. It looks like any value at all for the "proxy" field in the passdb
> >> l
On Mon, 2008-02-04 at 09:48 -0800, WJCarpenter wrote:
> >> 2. It looks like any value at all for the "proxy" field in the passdb
> >> lookup turns proxying on. The one exception is a value of NULL for
> >> "proxy", in which case proxying is not turned on and proxy-related
> >> other fields are ig
2. It looks like any value at all for the "proxy" field in the passdb
lookup turns proxying on. The one exception is a value of NULL for
"proxy", in which case proxying is not turned on and proxy-related
other fields are ignored. Is that how it's intended to work?
Yes. It might change
On Sun, 2008-02-03 at 12:03 -0800, WJCarpenter wrote:
> http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy
>
> 1. The wiki page says about password forwarding, "Make sure that the
> authentication succeeds with any given password. You can do this by
> using empty passwords." I didn't kno
In the course of experimenting with getting dovecot proxying to work,
I took a guess at two things. These work fine for me, but now I'm
wondering if they are "as designed" or just a lucky accident that
might stop working in the future.
(I'm using dovecot 1.0.rc17, which is the included version in
