> On Thu, 2007-01-11 at 21:30 -0700, Rick Widmer wrote:
>>
>> Joshua Megerman wrote:
>> > 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.
>
Well, changing the default LocalPort value won't necessarily cause a
change in functionality, as this is what the code does:
Get the value of the TCPLOCALPORT environment variable. If it's not set
(getenv returns NULL), set LocalPort to 110, otherwise use atoi to convert
the string to an integer and use that. Then, it does a case check on the
value of Localport, and here's why changing the default won't necessarily
break anything: If the port is anything other than
{25|110|143|465|587|993|995}, it checks the value of argv[1] for specific
substrings, and sets the connection type based on that:
a) if argv[1] has "true", it sets it to SMTP
b) if argv[1] has "imap", it sets it to IMAP
c) if neither a) or b) are true, it sets it to POP.
The biggest change that setting the default LocalPort to 0 rather than 110
would do is that it would allow for argv[1] to override the default
setting of POP, and it would set the VchkpwLogName to "vchkpw-0" instead
of "vchkpw-pop3". Since you cannot guarantee that an unset TCPLOCALPORT
is going to mean a pop3 connection on port 110, this seems like a logical
change. For users who are expecting things to work the same way, the only
difference will be the VchkpwLogName string will be different, and if they
are using SMTP or IMAP that doesn't set TCPLOCALPORT, it may well work as
documented.
>> 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.
>
I agree that this is also a correct solution, as this information is
needed to properly authenticate with libvpopmail. However, it doesn't
preclude the change to the LocalPort default for the reasons I outline
above. Also, I don't know what Dovecot passes as argv[1], but if it's
authenticating directly against libvpopmail, then vchkpw never enters into
it and the check against whether IMAP is denied would need to be written
into Dovecot directly...
Josh
--
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
[EMAIL PROTECTED]
