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
[vchkpw] Re: vchpw/onauth connection types
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. 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? Rick
Re: [vchkpw] Re: vchpw/onauth connection types
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 [EMAIL PROTECTED]
Re: [vchkpw] Re: vchpw/onauth connection types
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
