Squirrelmail / Imap problem

crawl

New member
Joined
Feb 5, 2004
Messages
4
Hi,

I just installed my first copy of DA on a FreeBSD 5.1 machine, and everything is working great except imap. When I try to login using squirrelmail I recieve a failed login screen, and the following is in /var/log/maillog:

Feb 22 02:28:59 srv4 imapd[1022]: Command stream end of file, while reading line [email protected] host=localhost [127.0.0.1]

Things I've tried:

/usr/local/directadmin/scripts/imapd.sh (didn't seem to do anything)

/usr/local/directadmin/scripts/squirrelmail.sh

Doublechecked squirrelmails config for localhost, port 143, and imap server = uw

deinstalled and installed imap-uw from ports, using make WITH_SSL_AND_PLAINTEXT=true install clean

made sure inetd was running by adding inetd_enable="YES" to rc.conf

made sure imap4 line was in inetd.conf

added an imapd file in /etc/pam.d with the following:

imap auth required pam_unix.so
imap account required pam_unix.so

When I attempt to login using squirremail I can see imapd loads, so I know it's up and running. I just can't figure out why it's refusing the login.

UebiMiau works fine, so I know it's an imap problem of some sort.

I'm stumped at this point!

Thanks
 
Last edited:
This should probably be in the FreeBSD 5.x forum...

Just make sure you are using [email protected] as the username. If you don't get any other error messages, I would do the following:

Try going to /var/www/html and removing squirrelmail and squirrelmail-1.4.2.

Then going to:

/usr/local/directadmin/scripts/ and run squirrelmail.sh
 
Ok, I tried that with the same results using the default server software setting in squirrelmail of other and changing it to uw.

I can log in using the system account (no @domain.com), but the virtual accounts aren't working.

Thanks
 
Have you been able to use a email client software to make sure that accounts works in IMAP?

Sorry I said to reinstall I forgot that the UebiMiau webmail client uses POP. If you can pop it would sound like IMAP is not working properly.
 
Hello,

If you had another /usr/sbin/imapd binary, DA wouldn't have copied it's own.. so just delete that file, then run the imapd.sh script again. (Only ours supports virtual email addresses)

Be sure to check the /var/log/maillog to see what it's up to.

John
 
I got it working by really going thru the system and manually removing the bits and pieces left from the other imap servers I had installed from ports, and then running the DA script. I can't say exactly what fixed it because I did so much, but it's working great now.

Thanks for trying to help me out :D
 
Any ideas what else might cause this or a similar problem?

I am on FBSD 4.10 and inetd/imap are running. I can telnet to IMAP on 143.

The errors I get in the maillog are: Jun 17 08:52:41 uhost01-opus imapd[81667]: Command stream end of file, while reading line [email protected] host=localhost.opusnet.com [127.0.0.1]

I removed the imapd and re-ran imapd.sh but there was no change. I compare the filesize to a working instance on a different server and they were the same.

I tested with the firewall disabled.

I can log into the users mailbox with POP so I know the password is correct.

I can also log into the account in the admin domain - without the @domain after the username.

Is there some way imap just isn't working right or seeing the virtual domains?
 
If I run /usr/sbin/imapd I get

* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] uhost01-opus.opusnet.com IMAP4rev1 2003.339 at Thu, 17 Jun 2004 12:31:21 -0700 (PDT)

It then sits in imap till I ctrl-c to escape.
 
Hello,

Not too sure.. it's loading correctly.. perhaps check the /var/log/messages, or the /var/log/maillog for possible clues.

Try squirrelmail if you haven't already.

John
 
We had a similar problem, on one client's server, same error:

Command stream end of file

when trying to download attachments.

Searched and searched.

Finally reinstalled and restarted the imap daemon from the DA imapd.sh script after first removing the old daemon file per John's instructions.

Now it works.

So I'd say at least restarting the daemon should be everyone's first step, and if that doesn't fix it, try reinstalling and restarting.

My client's problem was on RHEL, so it's NOT a FreeBSD thing.

Jeff
 
Back
Top