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



> Rick

Reply via email to