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