Sigh,
In the interest of moving forward on this project 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?
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 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 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 stuff but still wondering about the 'hand you a connection.'
--Chuck
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.
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.
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.
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.
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.
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
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.
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
On 17/06/2010 09:46, Chuck McManis wrote:
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?
This is probably a good "slashdot asks" question... A million replies driven by what people are familiar with...
I think you already named all the main software packages, so really bar some smaller apps (which definitely will work better for certain more niche projects!) you really have:
- Postfix/Sendmail (and perhaps qmail) for smtp
- Dovecot / Cyrus (and perhaps Courier) for imap
I should think that the real point is the management of all of the above. Yes any reasonably competent user here can probably manage a one off server, but managing one "for a friend", ie for very little cost (perhaps 5 mins a year) will mean a requirement for some management tools
Perhaps someone else can name a bunch of distros which package the above up with a nice GUI and make a cool integrated system? Obviously at the larger end you have the Scalix / Open Exchange / SOGO, etc (insert 5 more here) type systems, but all the ones I know of feel a bit bulky for a small office?
Probably the answer for many is to go hosted..?
What I have is a rails app using ActiveScaffold which manages a fairly generic database and allows me to very easily manage users across all servers in a very simple way. Very happy to opensource it if someone wanted to do some spade work to tidy it up, but really it can be re-implemented in a few hours by anyone competent with Rails and I'm very happy to share my DB schema which is really the trick
My system uses:
- Dovecot (changed from Courier some years ago, no experience of Cyrus, but sounds like a competitor)
- Postfix (never used qmail, used Sendmail in the early 90s and never ever ever want to see it again (sorry))
- Spamassassin
- P0f
- Clamav
- Fail2ban + simple iptables rules
- Mysql for database, every main app keys into a single schema
- DNSCache for local dnscache on the servers, but found dnsmasq ample for a home office size setup. DNSmadeeasy.com for domain hosting...
I think without my custom rails app to manage the DB schema it would be a complete pain to admin, but all it takes is a basic gui to transform such a bag of bits to something useful...
Good luck
Ed W
Chuck McManis wrote:
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?
Ubuntu. All the loveliness of Debian but actually usable in the real world.
Preferred MTA and what makes it the one you choose?
Exim. http://shearer.org/MTA_Comparison
Name service?
Name service?
ssh implementation?
Not really a question. But if there must be an answer then OpenSSH from the distro, remembering to make sure we have the distro's security stream in our package sources.
(If you need more security than this, then you should have the funds to do this properly without asking questions on mailing lists. If you need more security but aren't attracting that revenue stream, then in the wrong game and you need to go home and have are re-think about what you want to do to make a living.)
Hardware?
Rent a virtual machine (e.g. Xen based). This saves you having to make capital expenditure on hardware (= keeps the bean counter happy). Also it means you can do backups to S3 over the backbone.
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.
I've not generally noticed a problem with uptime these days.
Bill
On 17/06/2010 12:19, William Blunn wrote:
Rent a virtual machine (e.g. Xen based). This saves you having to make capital expenditure on hardware (= keeps the bean counter happy).
I haven't found virtual machines to be especially price efficient when you need plenty of storage available? Do you have a recommendation?
If you treat carefully around the edges of the bulk hosting sites there seem to be some reasonable quality options, eg: http://www.hetzner.de/en/hosting/produkte_rootserver/eq4/ 50 Euro/month including 2x 750GB drives
Also it means you can do backups to S3 over the backbone.
How are you backing up to S3? Most of the options I have seen have some serious issues that limit reliable full backups? Its been on my todo list for some time now to fix the C s3fs implementation that you find here: http://code.google.com/p/s3fs/ - code is shocking and could easily be fixed up pretty well...
http://s3tools.org/ - seems maintained, but not used it?
Brackup seems excellent, but has only an initial patch to support backing up user permissions, so at this stage seems more useful for data files than a whole system backup?
Also you have the option of cheap hosting through the likes of say Dreamhost or Kimsufi http://www.kimsufi.co.uk/ks/ £15/month for a single machine with a single 250GB (non backed up) disk. Twice that price can get you multiple TB disks. Use this plus rsync?
Not really sure where the sweet spot is here, but unsure what S3 really buys us?
I've not generally noticed a problem with uptime these days.
It becomes a challenge doesn't it... I just had to reboot a machine with something like 2+ years of uptime in order to upgrade a kernel and it's kind of annoying to see the uptime reset!
Cheers
Ed W
Ed W wrote:
How are you backing up to S3? Most of the options I have seen have some serious issues that limit reliable full backups? Its been on my todo list for some time now to fix the C s3fs implementation that you find here: http://code.google.com/p/s3fs/ - code is shocking and could easily be fixed up pretty well...
http://s3tools.org/ - seems maintained, but not used it?
Brackup seems excellent, but has only an initial patch to support backing up user permissions, so at this stage seems more useful for data files than a whole system backup?
Also you have the option of cheap hosting through the likes of say Dreamhost or Kimsufi http://www.kimsufi.co.uk/ks/ £15/month for a single machine with a single 250GB (non backed up) disk. Twice that price can get you multiple TB disks. Use this plus rsync?
Not really sure where the sweet spot is here, but unsure what S3 really buys us?
I would imagine it would be some variation on dumping databases, making tarballs, chopping up into <5GB pieces and then uploading them with s3cmd (s3tools.org).
Over and above rented server storage, S3 should provide multi-site redundancy (coverage against a plane making an unscheduled landing into the data centre).
Bill
On 17/06/10 13:33, William Blunn wrote:
Ed W wrote:
How are you backing up to S3? Most of the options I have seen have some serious issues that limit reliable full backups? Its been on my todo list for some time now to fix the C s3fs implementation that you find here: http://code.google.com/p/s3fs/ - code is shocking and could easily be fixed up pretty well...
http://s3tools.org/ - seems maintained, but not used it?
Brackup seems excellent, but has only an initial patch to support backing up user permissions, so at this stage seems more useful for data files than a whole system backup?
Also you have the option of cheap hosting through the likes of say Dreamhost or Kimsufi http://www.kimsufi.co.uk/ks/ £15/month for a single machine with a single 250GB (non backed up) disk. Twice that price can get you multiple TB disks. Use this plus rsync?
Not really sure where the sweet spot is here, but unsure what S3 really buys us?
I would imagine it would be some variation on dumping databases, making tarballs, chopping up into <5GB pieces and then uploading them with s3cmd (s3tools.org).
Over and above rented server storage, S3 should provide multi-site redundancy (coverage against a plane making an unscheduled landing into the data centre).
Tarsnap is worth glancing at:
Bill
Peter Risdon wrote:
Tarsnap is worth glancing at:
They appear to use S3 as their back-end :-)
They charge $0.30 / GB.month compared to $0.15 / GB.month for S3, which would seem to be within the bounds of reason if they are effectively mapping S3 space into something more convenient.
I suppose it depends how much you want to outsource.
Bill
On 17/06/10 14:11, William Blunn wrote:
Peter Risdon wrote:
Tarsnap is worth glancing at:
They appear to use S3 as their back-end :-)
That's right, thought it might be relevant. It's written by Colin Percival, FreeBSD's security officer.
They charge $0.30 / GB.month compared to $0.15 / GB.month for S3, which would seem to be within the bounds of reason if they are effectively mapping S3 space into something more convenient.
And very secure.
I suppose it depends how much you want to outsource.
Bill
Peter.
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: headerThanks 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
On 2010-06-17 11:52 AM, Chuck McManis wrote:
but I've been evaluating a ZFS based file server as well to see if it can get the same level of reliability.
Care to share which one? Or just a FreeBSD based one of your own making?
I've been considering NexentaStor Comunity Edition. The boss doesn't like spending money, and we don't really *need* anything super fancy, but I really like what I hear about ZFS...
--
Best regards,
Charles
On Thu, Jun 17, 2010 at 9:26 AM, Charles Marcus <CMarcus@media-brokers.com>wrote:
On 2010-06-17 11:52 AM, Chuck McManis wrote:
but I've been evaluating a ZFS based file server as well to see if it can get the same level of reliability.
Care to share which one? Or just a FreeBSD based one of your own making?
Its just a FreeBSD 8.0 system with a Marvell 8 port SATA card and a couple of TB of of SATA drives. I configured ZFS pretty much with all the default knobs. One of my SATA "drives" is actually outside the box so that I can turn it off to introduce a "failed drive" to the system to evaluate error handling and recovery.
I've been considering NexentaStor Comunity Edition. The boss doesn't
like spending money, and we don't really *need* anything super fancy, but I really like what I hear about ZFS...
For most NAS stuff so far it seems pretty reasonable. Its both not as space efficient and better than the NetApp in terms of total available space becaus the NetApp box lops off like 65GB of every drive in a combination of 'right sizing' and reserving space. ZFS uses the whole drive but has ginormously fat metadata blocks that it mirrors a lot. The Netapp box out performs it in terms of both bulk transfers and IOPs but I've done practically no tuning on the ZFS system.
--Chuck
--
Best regards,
Charles
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.
Hmm, I would rather estimate it to around 99% on our multi-domain mailserver, including the connections we deny at the SMTP level on the basis of rules like "deny systems that do not know their hostnames" or "deny systems that cannot do a proper SMTP greeting".
Cheers, Jakob Curdes
On 2010-06-17 4:46 AM, Chuck McManis wrote:
I'd be interested in what you consider a 'modern' MTA.
postfix.
Sendmail is fine (reasonably well maintained), but much more complicated than postfix.
qmail is basically totally unmaintained for many years.
Between that and using tcpserver to simply not accept connections from zombies spam hasn't really been an issue.
You're using dovecot, so why not use sasl_auth (dovecot-sasl) instead? That is the modern way.
--
Best regards,
Charles
On Thu, Jun 17, 2010 at 04:46, Chuck McManis <chuck.mcmanis@gmail.com> wrote:
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 abandoned sendmail many years ago and haven't looked back. I tried qmail and postfix, and was a lot happier with postfix. I overlooked exim at the time, but from what little I've seen and heard, it should be up there with postfix, making for a tough choice if you didn't have anything to bias your choice (like having used one of them already for a few years).
I prefer to avoid DJB's "the code is the comment" code because it's too hard to maintain. Hard to maintain == risk of breaking it, IMHO. But I do like DJB's CDB concept.
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?
I'd prefer Slackware or OpenBSD based on the simplicity. But I do/have run some things on CentOS, Debian, Fedora, FreeBSD and Ubuntu, for various reasons where those get me going faster, or have what I need, including my current mail server on Ubuntu (for a faster "get a startup started" where needs were not well defined), which will be migrated to Slackware, maybe in early '11.
Postfix is my 1st choice due to experience, but Exim seems to be a fine next choice.
My authoritative DNS runs on NSD3, and my caching DNS runs on BIND9. They are run on different IPs on the same machines (5, later to be 6, instances of each). Local hidden zones are on BIND9, but I don't have to do a split horizon to have it.
OpenSSH.
x86_64 machines because it's COTS. The mail server is running on a pair of 500GB drives in RAID1. Next machine will probably be more drives and 1TB each. I'm looking for a RAID controller than can do a 3-way or 4-way mirror. I also rsync everything to another box every hour and working on setting up a delta archive from that backup.
Phil Howard <ttiphil@gmail.com>:
I abandoned sendmail many years ago and haven't looked back. I tried qmail and postfix, and was a lot happier with postfix. I overlooked exim at the time, but from what little I've seen and heard, it should be up there with postfix, making for a tough choice if you didn't have anything to bias your choice (like having used one of them already for a few years).
FWIW I switched from sendmail to exim when switching my home server from SuSE to debian back in 2001. And I've really never wanted to switch, neither back to sendmail, nor to anything else.
Main reason: I understand the configuration files' logic.
I have no experience of MTAs other than sendmail or exim, though...
On Wed, Jul 14, 2010 at 17:49, Steinar Bang <sb@dod.no> wrote:
Phil Howard <ttiphil@gmail.com>:
I abandoned sendmail many years ago and haven't looked back. I tried qmail and postfix, and was a lot happier with postfix. I overlooked exim at the time, but from what little I've seen and heard, it should be up there with postfix, making for a tough choice if you didn't have anything to bias your choice (like having used one of them already for a few years).
FWIW I switched from sendmail to exim when switching my home server from SuSE to debian back in 2001. And I've really never wanted to switch, neither back to sendmail, nor to anything else.
Main reason: I understand the configuration files' logic.
I have no experience of MTAs other than sendmail or exim, though...
And I fully accept that as a sufficient reason to make a choice. I made the choice of Dovecot, having zero experience with it, because of my experience with Courier. Sadly, making such a choice with zero experience and zero knowledge of either options is the really hard one to make.
-- sHiFt HaPpEnS!
Phil Howard <ttiphil@gmail.com>:
And I fully accept that as a sufficient reason to make a choice. I made the choice of Dovecot, having zero experience with it, because of my experience with Courier. Sadly, making such a choice with zero experience and zero knowledge of either options is the really hard one to make.
Ah, wrt. to IMAP servers I at least have the experience of three different servers: UoW imapd, Cyrus imapd and now dovecot.
Based on that selection: dovecot is by _far_ the simplest one to get started with, and by far the most stable and scalable.
The second time a cyrus upgrade trashed my read marks I started looking for a replacement, and a quick google search found me dovecot.
I took some time figuring out what method I should use to transfer the mailboxes, and eventually settled on imapsync. I set up dovecot on a different machine than the one cyrus was running on, used imapsync to pull the mailboxes over, and then shut down cyrus on the first machine, installed dovecot, rsync'd the mailboxes back, and was up and running with the new dovecot.
As a bonus I could go back to use procmail for mail filtering. It's ugly... but I know it...
On 17.6.2010, at 6.59, Chuck McManis wrote:
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 there anyway.
Yes, it's doing that by default. If you want to disable it, use
service pop3-login { inet_listener pop3 { port = 0 } }
My question, can I be sure that it is not accepting non-SSL based connections?
disable_plaintext_auth = yes is also default, so it won't allow users to log in via non-SSL anyway (with 110 port it requires starttls). Of course, this might not prevent some clients from trying to send the password anyway.
Question 2) Is there any way to run dovecot from tcpserver ?
v1.x yes (but there have been some problems), v2.0 no.
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 ports.
v2.0 supports tcpwrappers if that helps.
Thanks Timo. --Chuck
On Thu, Jun 17, 2010 at 4:34 AM, Timo Sirainen <tss@iki.fi> wrote:
On 17.6.2010, at 6.59, Chuck McManis wrote:
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 there anyway.
Yes, it's doing that by default. If you want to disable it, use
service pop3-login { inet_listener pop3 { port = 0 } }
My question, can I be sure that it is not accepting non-SSL based connections?
disable_plaintext_auth = yes is also default, so it won't allow users to log in via non-SSL anyway (with 110 port it requires starttls). Of course, this might not prevent some clients from trying to send the password anyway.
Question 2) Is there any way to run dovecot from tcpserver ?
v1.x yes (but there have been some problems), v2.0 no.
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 ports.
v2.0 supports tcpwrappers if that helps.
participants (11)
-
/dev/rob0
-
Charles Marcus
-
Chuck McManis
-
Ed W
-
Jakob Curdes
-
Peter Risdon
-
Phil Howard
-
Steinar Bang
-
Timo Sirainen
-
William Blunn
-
William Blunn