[Dovecot] Ok, I've given up

[Chuck McManis]

On Thu, Jun 17, 2010 at 12:20 AM, /dev/rob0 <rob0 at gmx.co.uk> wrote:

> 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.
>

So SMTP hasn't changed much in 30 years ;-) I'd be interested in what you
consider a 'modern' MTA. I've looked pretty thoroughly at sendmail, postfix,
and qmail and of the three qmail is fairly reliable. Not sure what makes a
particular MTA more 'vulnerable' to spam. I don't run an open relay and I
generally find barracuda central a decent rbl source. Between that and using
tcpserver to simply not accept connections from zombies spam hasn't really
been an issue.


>
> > 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.
>

Actually I know its dovecot that opens 110. I see it in netstat and I've got
lsof to tell me that its being held open by the pop3 process:

dovecot   82197     root   15u    IPv4   0xc435d4f0        0t0      TCP
*:pop3 (LISTEN)

I'm not new to system administration mind you, just new to using dovecot.

And looking through tcpdump logs of what the clients send and vs what
dovecot responds, basically it is listening too, and refusing to answer, any
requests on 110. So it seems like we should be able to have it not listen
there. From watching the packets I've managed to convince myself that
dovecot is only allowing SSL connections to go through authentication. But
if there is a vulnerability in its pop3 code I worry about someone getting
squirrelly with the 110 port, hence my desire to just have it not listen
there at all.

> 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.
>

We have different interpretations of 'abandoned' ;-) I looked at using the
firewall rules to manage connection rules (love the concept behind fail2ban
although I've got an equivalent). But if your system is only exporting 4
ports to the web (SSH, DNS, SMTP, and POP) its actually easier (and thus for
me at least less error prone) to manage that on a per-daemon basis.

> 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.
>

I've got scars from syslog biting me in a variety of ways, not the least of
which are denial of service attacks which starve the kernel of mbufs by
generating syslog bombs. I'm sure its great for collecting log data from a
bazillion servers but for running a single server it creates more problems
than it solves for me. At least with something like multilog the failsafes
don't cripple the system, and that's key for me.

Out of curiosity, lets say you were given the task I've set for myself which
is described thusly:

Provide a system that gives shell and email service to a dozen users, hosts
perhaps 15 or so mailing lists, provides DNS for 20 - 30 machines.

Preferred OS and what makes it the one you choose?
Preferred MTA and what makes it the one you choose?
Name service?
ssh implementation?
Hardware?

Now I'll confess that in the way back times I helped start a company that
built this exact thing as a hands off appliance for small to medium
businesses, the company was called 'FreeGate.'  When the domain was retired
I believe one of the boxes reported back an uptime of just over 5.5 years
for a 48 user, 150 host domain.

Cheers,
--Chuck


> > 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
>