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[1] 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[1].  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[1] 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[0].
> 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
dovecot list. 

Thanks for your help!


> Rick

Reply via email to