> Joshua Megeman wrote:
>> It sets the connection type based on a list of known
>> ports (25/465/587 for SMTP, 110/995 for POP and 143/993 for IMAP), and
>> defaults to POP on an unknown conenction.
> Sorry, this isn't an actual thread reply, but I just came across an
> issue with the vchkpw program itself.
> I use Dovecot for my IMAP server, and to get last auth to work properly,
> I have to call the vchkpw program.  LastAuth works now, but since vchkpw
> defaults to pop, a pop restriction causes IMAP (and webmail) not to
> work ;)  Now I'll admit this is probably a mistake in how Dovecot does
> vpopmail authentication - but I was wondering if we could also set the
> connection type based on the binary name.
The connection type is based on the value of the TCPLOCALPORT environment
variable, which defaults to 110 if it's not set.  I don't know exactly how
dovecot works, but if you're not calling it from tcpserver, that's
probably what's happening.

> 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?
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics

Reply via email to