On Wed, Jun 16, 2010 at 10:59:55PM -0700, Chuck McManis
wrote:> In the interest of moving forward on this project
I looked back at your other thread and at this one, and, hmmm. I
invite you to join us in the new millennium.
1. POP3 sucks.
IMAP can do everything POP3 can do, and many things POP3 cannot.
Check it out, and you will want to give up POP3.
2. mbox sucks, mostly.
Mostly; mbox is slightly better for POP retrieve-and-delete usage,
but there, see #1 above. Maildir gives the administrator, and a
shell user, many options.
2a. mutt and alpine are both Unix console-based MUAs which
understand maildir *and* IMAP. I'm using mutt with IMAP,
because it has advantages over direct maildir access.
3. qmail is dead.
Over ten years without any coordinated development, five years
since the last (only?) netqmail release. Email has changed a lot
in those years, and yes, you can patch qmail to get most of the
functionality of a modern MTA, but IME that was a crapshoot. Why
fight it, when other, well-maintained, featureful MTA choices
exist?
3a. qmail is both much more vulnerable to spam AND by default,
the source of much spam.
> 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?
Not enough information provided to be able to answer that.
> 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
You would want to find out WHAT is listening on 110. Tools like
netstat(8) (8 in Linux, probably section 1 in BSD) are useful.
> 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
Yeah, Wietse wrote a similar program back in that era too, TCP
wrappers. Similarly, it was abandoned. Most Unix and Unix-like
operating systems have the ability to do packet filtering which is
more powerful and more flexible.
> 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
There's another DJB-ism that I don't care for; syslog(3)/syslogd(8)
works well. Those TAI64N timestamps are a pain.
> stuff but still wondering about the 'hand you a connection.'
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header