Re: [vchkpw] Re: vchpw/onauth connection types
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 > > > >
Re: [vchkpw] Re: vchpw/onauth connection types
> 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]
Re: [vchkpw] Re: vchpw/onauth connection types
Joshua Megerman wrote:
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.
Good catch! I agree LocalPort should be set to 0 instead of 110 in line
117 (5.4.17) of vchkpw.c because the current value blocks the default
case from ever happening. I'm not so sure it will fix Rick's problem -
it depends on what Dovecot's imap program is called. Still it is the
first step in allowing the name to be recognized in the default case.
Vchkpw will still default to pop if it doesn't find anything else that
identifies how it is being called. I just made the change in cvs.
Rick R.: You might want to try changing 110 to 0 in line 117 of vchkpw
and see if that fixes your problem. If so, please let me know.
If not please post how you are running Dovecot imap and I will see if I
can detect your situation from argv[1].
Also, please note that README.roamingusers mentions that you need to run
your POP daemon under tcpserver to allow it to work. If you aren't
running imap under tcpserver, doing so will almost certainly fix your
problem.
Rick
Re: [vchkpw] Re: vchpw/onauth connection types
On Fri, 2007-01-12 at 09:32 -0700, Rick Widmer wrote:
>
> Joshua Megerman wrote:
>
> > 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.
>
> Good catch! I agree LocalPort should be set to 0 instead of 110 in line
> 117 (5.4.17) of vchkpw.c because the current value blocks the default
> case from ever happening. I'm not so sure it will fix Rick's problem -
> it depends on what Dovecot's imap program is called. Still it is the
> first step in allowing the name to be recognized in the default case.
>
> Vchkpw will still default to pop if it doesn't find anything else that
> identifies how it is being called. I just made the change in cvs.
>
>
> Rick R.: You might want to try changing 110 to 0 in line 117 of vchkpw
> and see if that fixes your problem. If so, please let me know.
I'm sure it will - once I removed the 'deny pop' from that account, imap
worked fine.
> If not please post how you are running Dovecot imap and I will see if I
> can detect your situation from argv[1].
>
> Also, please note that README.roamingusers mentions that you need to run
> your POP daemon under tcpserver to allow it to work. If you aren't
> running imap under tcpserver, doing so will almost certainly fix your
> problem.
*smacks forehead* Duh. I was wondering where vchkpw got the variable
for smtp connections, since it's called from tcpserver - and figured
tcpserver was providing it. I never extended that to "run dovecot
under tcpserver stupid!" :)
I probably won't have time today to test - I will get back to the list
asap.
Thanks!
Rick
>
> Rick
>
>
