On Thu, 2007-01-11 at 21:30 -0700, Rick Widmer wrote:
> Joshua Megerman wrote:
> >>For example, vchkpw-imap would set the type to imap. vchkpw-smtp would
> >>set it to smtp, etc. This seems like a trivial change, and would only
> >>require a softlink back to vchkpw to enable. Am I thinking straight, or
> >>am I way offbase?
> > It's not an unreasonable way of doing things, although vchkpw will try to
> > figure out what the connection type is based on argv if the port is
> > unknown. Maybe the best solution is to eliminate the default setting of
> > LocalPort to 110 if TCPLOCALPORT isn't set, allowing vchkpw to look for
> > "true" (smtp) or "imap" (imap) in argv. I would think that if the
> > local port variable isn't set, we should leave it as an unknown, and not
> > force it to 110 (thus forcing a pop connection down the line).
> > Anyone else?
> I'd be very nervous about changing the default action. I've already
> learned my lesson (the hard way) about making tiny changes to existing
> functionality - even when you think it shouldn't matter to anyone
> else... it probably does.
That would be my feeling as well - I would prefer to just add
functionality that does not interfere with anything existing, and
especially not change anything existing.
> It seems to me that since vchkpw uses TCPLOCALPORT to determine how it
> is called, and Dovecot wants to use vchkpw for password checking, then
> Dovecot should handle setting the environment variables properly.
> Possibly it is a matter of the way Dovecot is being started that is
> hiding the environment variable. Maybe you can set the environment
> variable before calling vchkpw.
> You are running on a standard imap port, right?
Yep - Dovecot (which also provides POP, though I'm not sure if it's a seperate
binary like Courier) has some sort of 'native' vpopmail auth built in. I found
that while it does work to authenticate, at minimum the lastauth data isn't
So it doesn't appear to be complete.
> If Dovecot has a constant value passed into argv I would be willing
> to add that to the guessing code in vchkpw, but I don't like the idea of
> adding _another_ block of testing for argv.
> I believe the best answer is to have the right port in TCPLOCALPORT when
> you call vchkpw.
I agree - I didn't realize there was a TCPLOCALPORT variable to set that
would specify that - that seems like an easy fix. I'll check with the
Thanks for your help!