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