Thanks for the response, some snippage to cut down on list traffic ...
On Thu, Jun 17, 2010 at 7:14 AM, /dev/rob0 <rob0@gmx.co.uk> wrote:
On Thu, Jun 17, 2010 at 12:20 AM, /dev/rob0 <rob0@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@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