Quoting Steve Barber, the cluebat supplier:
-----
Alexy -
Glad to hear you've got things working but I
think something is
still not quite right with your setup. I use xinetd and I didn't
have any problems. Unfortunately I've been doing most of my work
lately with Cyrus instead of UW imap, so I don't have any particular
suggestions for you, but I do know that last time I built UW, it
"just worked".
If I were you I'd review the installation documentation for something
you might have missed (for example, check the entries in /etc/services)
Sorry I can't be of more help, but maybe it will help just to tell
you that it shouldn't be that hard...
Steve
=====
Steve -- I use SuSE, which is the best Linux I
ever saw, given that I didn't use Debian yet. All
of the things are configured properly by default,
/etc/services are correct, and replacing xinetd by
DJB's tcpserver was another blessing from this
investigation. I don't need inetd/xinetd at all,
I only need internal imap/imaps for PHP, and I get
that with tcpserver, which also claims multiple
advantages over xinetd.
My problems caused me to suspect xinetd exactly
because there was no difference between imapd's
behavior via imap/143 v. imaps/993. All the logs,
/var/log/mail and /var/log/xinetd.log on SuSE,
properly differentiated those invocations of imap
v. imaps. xinetd simply failed to convey this to
imaps/993 properly, and it always started imapd in
text mode. I don't think o anything else but
xinetd is responsible. If you can think of
anything else, I'd try it. but for now I'm
convinced xinetd is to blame! It is configured
with SuSE's defaut logging options,
log_type = FILE /var/log/xinetd.log
log_on_success = HOST EXIT DURATION
log_on_failure = HOST ATTEMPT RECORD
# only_from = localhost
instances = 2
-- you see there's no USERID targeted in FAQs as
slowing down things polling identd's -- and error
lines in /var/log/mail did say this:
Aug 12 17:44:40 angle imapd[3628]: Connection reset by peer, while flushing line
user=??? host=UNKNOWN
but there's nothing in FAQs against that, and host
should be known to xinetd. The proper durations
and failure codes imaps=1 were found in xinetd.log
each such time, and imap=0 every time.
Folks with the plain old inetd didn't report such
problems, so everything points to xinetd. Also,
tcpserver docs mention various performance
deficiences of the *inetd's, so I came better off
in all cases with the tcpserver.
Feel free to suggest further things to try!
Cheers,
Alexy
--
------------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------
