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 updated. 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 > Rick > > > >
