[Dovecot] Ok, I've given up

[Chuck McManis]

Sigh,

In the interest of moving forward on this project I've given up trying to
get Dovecot to support mailboxes, rather I've tweaked around in qmail and
had it deliver into a mail directory on a disk, that isn't NFS mounted. That
got me past the various locking complaints and "operation not supported" on
home directories that were mounted from the NetApp filer.

Going as vanilla as possible I've managed to both send an email that qmail
delivered and fetch the email with my 3 test clients (Eudora, Thunderbird,
and Evolution) (I know they are, in a sense, all variations on a theme but
MUA monoculture seems to be inevitable these days).

So a few questions for the other esteemed system operators here if you know
the answer I'd love to hear it.

Question 1) Are my user's passwords safe from prying eyes?

First, part of this effort was to move off of an APOP infrastructure into
something more secure against password eavesdropping. To that end I've
configured Dovecot with simply:

protocols = pop3
service pop3-login {
  inet_listener pop3s {
    port = 995
    ssl = yes
  }
}

Note that there is NO port = 110 listener and yet Dovecot seems to listen
there anyway. My question, can I be sure that it is not accepting non-SSL
based connections? Attempts to use plaintext on 110 were rebuffed so that
seems to be the case. My intent is that if my user is using this in an
airport they won't give away their email password to a bad guy who is
sniffing all the packets.

Question 2) Is there any way to run dovecot from tcpserver ?

One of the things I like is the program tcpserver. I like it because I can
simply "not allow" large chunks of the internet to connect at all to certain
ports. (I use this for SSH in particular since all the kids love throwing
dictionary attacks around). I'd like to give my POP3 ports equivalent
protection. I also like the logging facilities of the supervise / multilog
service.

To use this I'd need Dovecot to accept the connection handed to it, and not
do the whole setsid daemon thing since tcpserver will start another one if
needed. I can send the logging out to stderr (thanks!) and get the logging
stuff but still wondering about the 'hand you a connection.'

--Chuck