[Dovecot] Ok, I've given up

[/dev/rob0]

On Thu, Jun 17, 2010 at 01:46:19AM -0700, Chuck McManis wrote:
> 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.

You didn't have any comment on the above; I hope those suggestions 
were useful.

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

One that supports many/most ESMTP features without patching (so, 
netqmail, "Last modified: Wed Feb 2 23:37:31 EST 2005", can be 
considered "without patching".)

(Apparently, since DJB released qmail into public domain, no one has 
cared enough to roll up a release which included the patches, FWIW.)

RFCs 5321 & 5322 were released in 2008. Various ESMTP extensions 
which are in common use came after the end of qmail development.

Spammers are working every day to cause more abuse. Postmasters are 
trying to stay ahead of them, but we still see that over 90% of all 
traffic to port 25/tcp is abuse.

> I've looked pretty thoroughly at sendmail, postfix,
> and qmail and of the three qmail is fairly reliable.

Perhaps it is. Does it do what you need? You mentioned wanting to 
protect users' passwords. STARTTLS and AUTH are not supported by 
qmail without patching, and I wouldn't be so confident in those 
patches, if I was running qmail.

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

Good. You might also want to consider zen.spamhaus.org. I find that 
rejecting non-FQDN HELO names will stop around 25% of all connections 
I get, but perhaps if you've maintained your tcpserver access lists 
well, you're not getting as many of those. If not, you're lucky, 
because here too, qmail has no native ability to perform access 
checks based on the HELO/EHLO name.

The qmail design of accept-then-bounce is thoroughly discredited. I 
hosted a domain which didn't have email, and 90% of my logs were 
backscattering qmail woodpeckers coming back again and again after 
"554 5.7.1 <rcpt at that.domain>: Relay access denied ..."

(The domain expired, and gradually my logs quieted down.)

> > > Question 1) Are my user's passwords safe from prying eyes?
> >
> > Not enough information provided to be able to answer that.

(Apparently it was enough information for Timo to answer.)

> > > 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 
> >
> > 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' ;-)

Software written in the 1990s and no longer maintained, I call 
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.

Easily done with firewall rules per port, too. But, abuse is abuse, 
and generally a host which is abusing you is ONLY going to abuse you, 
so IMO, it might as well (or should) be blocked entirely.

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

Sure, who can resist questions like these? :)

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

"Provides DNS for ..." meaning, it is the "nameserver" host for these 
20-30 clients?

> Preferred OS and what makes it the one you choose?

Familiarity. Most of my Unix admin time has been done in Slackware 
Linux. I like the simplicity and the ease of management. Any Unix or 
GNU/Linux can do the job ... the admin's personal preference and 
experience is what matters.

> Preferred MTA and what makes it the one you choose?

I spent my time to become proficient in Postfix. I think Sendmail 
and Exim are also good choices.

> Name service?

I run ISC BIND named(8) for recursion and for globally-available 
authoritative DNS. I run dnsmasq(8) for local authoritative DNS and 
as nameserver for client hosts. It uses a non-root named(8) on 
alternate ports for its upstream recursion.

> ssh implementation?

I think OpenSSH is the only show in town, but as another poster 
pointed out, watch for updates.

I normally eschew security through obscurity, but for SSH, you can 
enjoy much quieter logs simply by using an alternate port on the 
outside. The spammer/scammers' attack bots are only hitting port 22 
with the brute force attacks.

> Hardware?

Yours could be done on rather modest, consumer-grade hardware, but 
when there's revenue at stake, don't skimp. At least buy quality
hardware and good power protection. I'm a fan of hardware RAID, 
having invested in a few 3ware controllers.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header