Subject: uw imapd problem: no connect from certain ip's (with no rverse dns)

From: Søren Friis-Nielsen <[email-masked]>
Date: Mon, 02 Jun 2003 11:40:48 +0200

I am somewhat of a newbie. I have tried to find a solution to this 
problem: I run a mailserver at home that some of my friends use. Some of 
them cannot connect via IMAP or POP (but webmail works fine). Below are 
some entries from logfiles:

/var/log/syslog (servername and ip changed):

Jun  1 18:39:56 myserver imapd[32406]: connect from 130.225.x.x
Jun  1 18:39:56 myserver imapd[32406]: imap service init from 130.225.x.x
Jun  1 18:39:56 myserver imapd[32406]: Command stream end of file, while 
reading line user=??? host=[130.225.x.x]

/var/log/mail.info (servername and ip changed):

Jun  1 18:39:56 myserver imapd[32406]: Command stream end of file, while 
reading line user=??? host=[130.225.x.x]

These line repeat themselves many times.

I tried to do a lookup:

myserver:~# host 130.225.x.x
130.225.x.x does not exist (Authoritative answer)

Can this be the source of the problem?

I checked other machines that had no problem connection through imap and 
they all looked up okay (hostname was found).

If this is the problem, then what can I do about it?

Regards,
Søren Friis-Nielsen.

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Mon, 2 Jun 2003 08:58:54 -0700 (PDT)

> reading line user=??? host=[130.225.x.x]

This message means that the client disconnected without first issuing a
proper LOGOUT command.  Some poorly-written clients do this in the false
impression that it is "efficient" to do this.  In any case, this should be
interpreted as equivalent to a LOGOUT, and that the client never logged
in.

The most likely explanation is that the client does not know how to log in
to the server properly.  I noticed that the connection was not SSL
encrypted ("imap service init" instead of "imaps service init").

By default, UW imapd does not permit plaintext password login methods
(LOGIN command, AUTHENTICATE LOGIN command, and AUTHENTICATE PLAIN
command) unless the session is SSL or TLS encrypted.

Non-plaintext login methods (AUTHENTICATE CRAM-MD5, AUTHENTICATE GSSAPI,
and others) are permitted in unencrypted sessions, but they have to be
set up with their own database; they can't use the /etc/passwd password.

If you use a client which only has plaintext password login methods, and
which does not use SSL or TLS encryption, you will not be able to log in.
Combine that with a poor design (such as not issuing proper LOGOUT
commands, and not giving informative error messages to the user), and
you'll observe the behavior that you're reported.

The simplest thing is to see if the client has some option to use SSL, and
if so, try setting that option.  Otherwise, discard that client and use
quality client software (such as Pine).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.