[Dovecot] Ok, I've given up

[Chuck McManis]

Thanks for the response, some snippage to cut down on list traffic ...

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

> > On Thu, Jun 17, 2010 at 12:20 AM, /dev/rob0 <rob0 at gmx.co.uk> wrote:
> > >      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.
>

Absolutely, I pulled the mutt packages and built it and played around with
it. Its very nice. It will work better than doing a maildir2mbox before
running, thanks for that.


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

I actually have the equivalent of a netqmail++. We had used it at FreeGate
and I became pretty comfortable in the source base so its what I'm familiar
with.


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

Fair point.


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

Yup. (well 73% in my case but I've got a small domain off in an unused
corner of the universe)

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

This is true, although as I've said I'm pretty comfortable around Dan's
source code (even if I abhor his coding style).


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

I've gone back and forth on FQDN bouncing. I used to reject it out of hand
(if you're using tcpserver you can use it to pass along a signal that the IP
and name don't match, and then in qmail you can compare the HELO name with
the $REMOTEHOST value to bounce (or spike) on mismatch)). But enough people
seem to screw this up but be legitimate that I've switching to using it as a
strong signal to the spam classifier as 'likely spam'. I've got the
equivalent of the 'fail2ban' utility which auto-blocks any address which
sends an obvious spam (non-address for example)


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

I've always considered the accept-then-<action> and the <action> was pretty
configurable. I just spike (aka send to /dev/null) and ban (update the
tcpserver rules). About 8 years ago I was still helpfully bouncing stuff
until I added up how much b/w I was consuming by sending bounces to folks
who didn't send the email in the first place and stopped doing that. Which
is a long way of saying I agree with you that accept-and-bounce isn't a
useful policy for MTAs


> Software written in the 1990s and no longer maintained, I call
> abandoned.
>

Ok, but generally the patches for qmail have been feature patches, not bug
fixes it seems. I can accept your definition of abandoned as software that
doesn't get changed by the author and there is no official maintainer of a
version.


> [snip]
>


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

Yes, name resolution and a name cache for the folks on the network.


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

Fair enough, I tend to land on FreeBSD for server software and Ubuntu/Gentoo
for desktop.

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

After your message I went hunting for 'state of the art' MTAs, it seems
sendmail, postfix, qmail, and exlim are the only ones people talk about.


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

Ok, I'm on v9 since I was dealing with poisoning attacks on my cache in 8
pretty much constantly. (this led to some of the syslog explosions)
Typically I'll get combined spam floods and DNS 'result' floods from what is
presumably the same botnet. V9 seems to able to ignore the result floods
more effectively than V8 did.


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

I found it takes longer for them to find the port but they still try brute
force it.  Maybe I'm just lucky in that regard (for some definition of
lucky)

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

Cool. Having worked at NetApp for a few years I am not a fan of hardware
RAID, the hardware vendors know less about making RAID reliable than random
open source programmers seem to. I am a fan of reliable storage though. I've
got a NetApp filer for home directories but I've been evaluating a ZFS based
file server as well to see if it can get the same level of reliability.

Thanks for the feedback Rob, I appreciate it.

--Chuck

--
>     Offlist mail to this address is discarded unless
>    "/dev/rob0" or "not-spam" is in Subject: header
>