sanesecurity signatures for clamav
These are well worth adding
http://sanesecurity.com/
The story so far: Over the last two weeks, I've explained how you can set up a mail server to provide you with POP3 and IMAP services, for your own email, with some basic filtering of inbound connections, and the ability to connect to it and send emails from just about anywhere. This week, it's time to add more serious mail …
Exchange Server 2012, unlike previous versions doesn't contain a SPAM and virus filter. Yes if you are really committed you can via the command-line manually set up some rules, but it is far simpler to implement and maintain a third-party SPAM and virus solution...
"Exchange Server 2012, unlike previous versions doesn't contain a SPAM and virus filter"
There is no such product.
If you mean Exchange 2013 then that's not correct:
See https://technet.microsoft.com/en-us/library/jj150481(v=exchg.150).aspx
Microsoft do recommend that you use a cloud based service for more advanced protection though.
And massively more complex to manage, with far more potential bugs, undocumented interrelationships and dependancies, too.
For a simple mail server for anything up to SMB, Exchange is huge, huge, overkill - and more expensive if you aren't on Technet.
The only people who should use Exchange are those who explicitly need it - for everyone else, there's Linux/Unix based tech.
Steven R
"And massively more complex to manage"
Actually it's somewhat easier to install and manage than this solution - it pretty much just works and is ready to go once installed.
"- and more expensive if you aren't on Technet."
That is true, it's about £900 with 5 CALS. TechNet no longer exists by the way - it's MSDN only now.
"Actually it's somewhat easier to install and manage than this solution - it pretty much just works and is ready to go once installed."
No it's not - first you need AD. So one doesn't set up just a stand-alone Exchange server.
Setting up a simple standalone mail server like the example in these articles is a piece of piss by comparison. The best part is you learn a lot more about how it all works under the hood too, which helps if you ever need to troubleshoot it later. I've had to troubleshoot many mail servers in my time including Exchange (from 5.5 to 2013) and believe me, Exchange is by far the biggest handful (and most delicate) once things go pear shaped.
Anybody who thinks that one vendor has all the answers only shows up their very limited experience in the technology industry.
Exchange is probably overkill for a home server and although setting it up is indeed simpler than all this config file editing it has it's own set of quirks. Getting through the prereqs on older versions used to be a good definition of hell but the last version I installed seemed to automate most things.
Anyway I went with something called VPOP3. Setup is largely automatic but if you like tinkering you can do that through the UI. There are hints and tips throughout so it's easy enough. Personally though I just leave it alone. Life is too short to spend more than an hour setting up a mail server.
I'm afraid you're violating the license. AFAIK, TechNet licenses could be used only for learning/testing purposes, and they can't be used for any production environment - and even running your private mail server is a production environment.
Moreover, the resource needed - including a Windows server 64 bit license and CALs... - make it an expensive choice.
To be honest, I don't run anti-spam/virus stuff - it really isn't needed on a private home server (and I am savvy enough to know what is crap mail and what isn't). I guess if you are setting this up for an organisation with a few users, then it is required (especially if the end users are running MS stuff).
I do use the blacklist stuff though (DNSBL) - also block dodgy ip blocks on the firewall (China, Russia etc.) and use SPF. Postfix does the rest.
See:
https://zeltser.com/malicious-ip-blocklists/
Yes, I think if it's just a couple of people and you have the wits to recognise a phishing email, then just a combination of greylisting and filtering based on DNSBLs will very likely cut things down to manageable proportions. Certainly, greylisting is the one thing that keeps the biggest load off my servers.
On the other hand, if you have less technically aware people, then something that can spot things like phishing and viruses is probably a very good idea.
Mostly, you can build up from each of the parts of this tutorial and stop when you've got to the level of protection that feels right for you. Or indeed you can drive yourself made with tweaks to Amavis settings and custom rules for SpamAssassin if you want to crack down even more.
I would really recommend to setup a couple of DSNBL services to block spam. They will do it very early in the connection, checking the originating IP, and will refuse delivery or close the connection before the spammer can deliver its message, reducing the bandwidth used, and reducing the load of performing a full message analysis. In my experience, most spam will be usually caught by DSNBLs.
Usually most spam coming from botnets, open proxies, spam-friendly ISPs and so on will be blocked by DNSBL, and this may account for a large fraction of received spam, especially if some of your accounts has been in use for many years, and ended up in some big spam lists.
What usually isn't blocked at that level is spam (or phishing) using big mail services account - i.e. gmail, yahoo, etc., or smaller and/or not yet identified spam operations.
Those often can be identified by an URL blacklist service - checking contained URLs for known spam/phishing operations (if not, and they are repeated, use your own blacklist). Some mail server (or addons) can do it themselves, SpamAssassin can use some within its processing workflow. They are useful because usually a hit means a message is really spam/phishing, and can be marked, routed, or deleted accordingly.
"Nigerian" scams usually need to analyze the message, while malware carried in attachments may need rules to neuter executable files (if users don't complain too much) and AV checking. I see one commenter doesn't use an AV, but my advice is to keep mailboxes clean from known malware, it takes a little distraction to infect a system, especially since today PDF and Office files are a big risk.
If possible, it's not bad to re-run AV checks on older data after some time with newer signatures as well. And I prefer to backup "clean" data as well.
Here's an example of using Postscreen with the config from the article, to do preliminary checks against DNSBL services. As I say, I've only recently been tinkering with this, so I'm not going to recommend specific block lists to use until I have more experience.
In that particular instance, I'm usually zapping stuff to my Synology via the second (private) network port on the box, so I don't worry too.much about it.
Yes, if I were sending stuff over the public net, it would be wise to use encryption, SSH and distract the agencies with a squirrel too.
This post has been deleted by its author
So I don't want exchange and life is far too short to fiddle this much just for email.
I want a box that is as near to zero config as possible but that will still keep my data local and support full mail/calendar and note functionality across win/mac/ios and android.
Does such a thing exist?
Off the top of my head, I'd suggest looking at some of the packages for a NAS. For instance, if you have a Synology then their Mail Server package allows you to host IMAP mailboxes for people, and calendars can be handled with CalDAV via the control panel's WebDav settings
This tutorial covers the basics: https://www.synology.com/en-global/knowledgebase/tutorials/463 though note that on DSM 5.2 you'll find WebDAV settings not at the top level of the control panel but in the 'File Services' section
If you don't mind running a Windows box then VPOP3 will do what you want and it's apparently now free for personal use up to 5 users. There are a few things that are only available with the Enterprise version though:
* IMAP support.
* Incoming SSL support.
* IPv6 receipt (you can send on IPv6 but the free version only supports one incoming protocol so it's either IPv4 or IPv6 and I suggest the first one :) ).
Installation is about what you'd expect for a Windows application. Double click the setup icon and sit back. Once it's done the server will be running and all you have to do is create user accounts. I've been running it now for nearly ten years. I've upgraded four times over the years and that was painless as well - just run the installer and wait.
I've never used the calendar facility so can't comment on that.
There are a couple of other free mail servers for Windows and when I tried them they all seemed as easy to set up as VPOP3. Hacking text configuration files around is just not something Windows users expect to have to do. I suppose having to pay for most things we use means we expect the easy life :D
Most of what has been described in these articles will work just fine on Linux too. The first part explains a little bit about the choice of OpenBSD.
There will obviously be a few differences when it comes to things like package installation, start-up scripts and file paths.
If you *really* want to run your own on-premise "appliance" version of (Linux for example) to make this sort of thing "less fuss, less muss" and still retain control (ie, physical access,ownership) of your box, maybe take a look at "ClearOS" Community edition:
https://www.clearos.com/clearfoundation/software/clearos-6-community
ClearOS is based on what used to be called SME server / E_Smith server. ie, it has been around for a while; it has a good history of "stable, well maintained, works, and not bleeding edge".
I use ClearOS as a variety of SMB sites and it is super solid. Pretty much all the admin stuff can be done from the web-admin GUI. CLI via SSH is there and available if-when you need/prefer it.
It is free (community version) but you do need to register (free) with them. If you don't like that you may need to look elsewhere. But in terms of a very well built, well thought out, mature "appliance" distro - you can add roles:features as needed (Mail, anti-spam, anti-virus, greylisting, SMB:Domain controller, etc etc etc) - boat loads of options.
Highly recommended.
Tim
Happen to lease a windows based server and after a few abortive attempts with alternatives, have been very happy with this, for what must be getting on for a decade.
Nice little GUI gives you pretty immediate access to whatever you might need, and back end is a MySQL db, so when I did have a "catastrophic server failure" (some numpty trashed my live server), was re-buildable from the bits I'd backed up remotely.
I have been using Mdaemon from Alt-N for many years and enjoy the ease it is to set it up
Pretty easy to set ut and lightweight but with most of the bells and whistles.
Just need a windows machine, download the software and even a gimp can get it running.
Spiceworks users seem to like it too https://community.spiceworks.com/product/3590-alt-n-technologies-mdaemon-server
F
SPF is a pretty big joke. If you are (incorrectly) using it to outright block mail versus using it as a scoring system, you're going to get false positives. Using it as a scoring system, it holds so little weight, it barely factors in to the overall spam score. That combined with the fact that spammers can just as easily set up an SPF record to authorize mail from anywhere (but luckily they are generally not that smart), it's never really lived up to its original hype.
If you are (incorrectly) using it to outright block mail versus using it as a scoring system, you're going to get false positives.
No, that's utter nonsense.
SPF gives the domain owner a method to declare which servers will send email on behalf of his domain. If he's restricted those servers to a set of defined machines, then it is not a "false positive" to reject everything else - that is what the domain owner said he wanted.
Vic.
SPF obviously isn't easy to implement !
Virgin Media's new "Improved" email system is currently blackholing most of my emails because it doesn't like the fact that they are forwarded from my domain host. Every other email on the Virgin support forum is about either not blocking spam or blackholing legitimate emails.
SPF obviously isn't easy to implement !
Well, I've no personal experience of implementing it with postfix, but I've done it with other MTAs (exim was a bit of a pain...). Google tells me that postfix SPF packages are available...
Virgin Media's new "Improved" email system is currently blackholing most of my emails because it doesn't like the fact that they are forwarded from my domain host.
If you are simply forwarding mail, that has a tendency to break someone else's SPF rules (you are impersonating their domain...). That's what SRS is for. But VM should not be blackholing anything - if it fails validation, it should be rejected.
Vic.
If you are simply forwarding mail, that has a tendency to break someone else's SPF rules
This is my point exactly. SPF falls down when someone has their email address set to forward elsewhere, because the original sender didn't "authorize" their email to be sent by another other server. You can't rely on every mail server out there that allows email forwarding to another server to have implemented SRS.
It also doesn't "stop SPAM" in and of itself. It simply makes it where someone can't impersonate your email address in the envelope sender. Spammers could just as easily create SPF records for their own throwaway domains authorizing the world (but luckily they rarely do).
SPF falls down when someone has their email address set to forward elsewhere, because the original sender didn't "authorize" their email to be sent by another other server.
That isn't "falling down", that's working as intended. If a domain owner lists the servers that may send email for his domain, and declares all other servers to be fraudulent if they try, then that is the decision of the domain owner. It's his domain...
It also doesn't "stop SPAM" in and of itself
It isn't trying to. SPF is an anti-forgery system, not an anti-spam one.
Vic.
If a domain owner lists the servers that may send email for his domain, and declares all other servers to be fraudulent if they try, then that is the decision of the domain owner.
So you're saying that some regular old joe that knows nothing about SPF or even DNS who sets up his email address to forward to another email account is equivalent to him trying to forge the original sender?
And it's effectiveness as an anti-forgery system is a joke. The envelope sender can be something that passes an SPF check with flying colors (or even has no SPF record), yet the From header in the email is what the end user actually sees. How many people do you know that are smart enough when they receive a "suspicious" email to view the headers to see if the From header matches the Return-Path or trace the Received headers to find the originating server?
By all means, have an SPF record on your domain. It (sometimes) helps deliverability. But don't think that it stops me from being able to send out email that convincingly looks like it's from you.
So you're saying that some regular old joe that knows nothing about SPF or even DNS who sets up his email address to forward to another email account is equivalent to him trying to forge the original sender?
If that's what the domain owner has declared, then yes. It is. That's what ownership means.
And it's effectiveness as an anti-forgery system is a joke
Well, you have some strange ideas about SPF and make that claim. I use it, and would not. Perhaps you might like to wonder if there is more than just mere correlation to that...
Vic.
If that's what the domain owner has declared, then yes. It is. That's what ownership means.
So when user B doesn't get user A's email because user B has configured a forwarder and the email is rejected due to a violation of user A's SPF record, it's user B's fault?
Well, you have some strange ideas about SPF and make that claim. I use it, and would not. Perhaps you might like to wonder if there is more than just mere correlation to that...
I HAVE been using SPF for a long time now, mainly because of "hey, it's one more thing you can try to make email deliverability work better". The fact that I say it's a joke doesn't mean I say no one should use it. It means don't put much faith behind it.
And the fact that you use it and would not make the claim that it is an ineffective anti-forgery system does not make the opposite true. Please do share anything that was not true about my anti-forgery statement.
Spamassassin will check SPF records as part of the config described here, and I'd recommend that you set them up for any server you're running; a few other people mentioned that in the comments last week as well.
I didn't really have a lots of space to cover all the network side of the config - there are only so many pages long an article can be before it's really annoying clicking through, sadly.
Anyway, for people not familiar with it, SPF is a fairly straightforward DNS entry - you create a TXT entry for your domain, using a specific syntax, and it essentially allows you to say "Only these specific hosts are allows to send mail from my domain. If you get mail from nigelwhitfield.com that comes from anywhere else, reject it"
Checking isn't mandatory, but many sites do use it. You can learn more at OpenSPF but bear in mind two things
1. Set it up wrong and you may cause lots of servers to reject your messages
2. If you host mailing lists or forward mail for people, SPF can cause problems with that
@TheVogon: Thanks for that; when I set up SPF myself originally, I used the basic wizard on the OpenSPF site, and I see that's now gone away.
I agree that it's pretty straightforward to create a record, especially using a wizard like that. And it's easy enough to turn on in most MTAs or spam filters.
Of course, it's also pretty easy for senders of marketing emails to create their own SPF records, or sign messages with DKIM. So SPF is probably most useful against zombies and compromised systems.
I have a hard fail (-all) in my SPF record, is also partly why I have the submission port set up on the mail server, to ensure that wherever I am, outbound messages always come from that address. I don't see the point of anything other than the hard fail option, really - it seems on the face of it to tremendously reduce the utility of SPF.
I used the basic wizard on the OpenSPF site
SPG is actually easier, IMO, if you ignore the wizards doing the rounds and just write the record. Help is readily available from the SPF mailing list (of which I am a member).
So, for example, if your outbound email comes from IP addresses 1.2.3.4 and 2.3.4.5, your record is simply:
v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 -all
And that's it. Using "mx" usually implies a misunderstanding of the protocol, using "ptr" almost always so. Using "a:" records is often seen as lazy, since these are usually trivially re-written as "ip4:" or "ip6:" records, reducing the overall DNS load of the record.
I don't see the point of anything other than the hard fail option, really - it seems on the face of it to tremendously reduce the utility of SPF.
The purpose of SOFTFAIL is twofold: one is to enable testing without breaking everything, and the other is to enable the reputation-based scoring that an earlier commentard suggested was the "right" way to use SPF (with which I fervently disagree, but that's another matter). But hard fail is a good thing.
What makes me *properly* angry is the number of records I've seen lately ending in "+all" - this says categorically that "absolutely everyone else on the Internet is positively authorised to send mail on behalf of this domain"[1]. Someone somewhere is putting out some very bad information, and there will be violence if I find out who...
Vic.
[1] "+all" must surely be there for orthogonality only; it has no sane use-cases. As such, I have modified my SPF milter to treat "+all" as "-all", and I recommend everyone else do the same.
You can go through all this trouble to set up Postfix, or you can install Citadel. The Easy Install script takes about 20 minutes.
You can install an entire EL distro and set up sendmail/dovecot/spamassassin/clamav/SPF in a similar amount of time[1] - the defaults are almost[2] exactly what you want anyway. I think the point of this series is more to show the process of setting up a mailserver form scratch, rather than actually achieving one.
Vic.
[1] Probably not the first time through, though.
[2] The default sendmail installation *only* listens to localhost. You need to make an explicit (very simple) change to make it go live (edit out the "Addr=127.0.0.1" in the DAEMON_OPTIONS line)
Well, quite; you can install OpenBSD and add the packages used here in a pretty short space of time. And though some people will find using vi take a bit longer to edit config files than filling in some web forms, it doesn't actually take an awfully long time.
I don't think the process we showed here is massively involved really - but we did show it in stages, where pretty much each one leaves you with a working system, and hopefully at least an understanding of how everything fits together.
It may well be quicker to grab an off the shelf package that wraps everything up with wizards, but I think learning how the parts fit together is always a worthwhile exercise.
A typical OpenBSD install takes about 5 minutes or less, and if you know the packages you want to install, inside of 20 minutes is not unrealistic. For the vi challenged, OpenBSD actually comes with a second editor in the base system - the emacs clone mg(1), which is essenstially 'emacs as just a text editor'.
Nice series and I love the fact that you're using OpenBSD. However, I tend to think that building an OpenBSD mail server and not mentioning the built-in greylister spamd(8) is something of an omission. I've built a few rather similar systems myself, sometimes with spamd(8) on a gateway with other 'firewall' configuration, sometimes single box configs that run all the services. Setting up with spamd(8) would of course also mean tackling a minimal PF configuration, which may sound a bit foreign if OpenBSD is unfamiliar territory to start with, but I suspect the performance would be slightly better than with postgrey, and you would also gain the potential entertainment that greytrapping offers.
I've written some articles about these systems over the years, see eg the gentle introduction http://bsdly.blogspot.com/2013/05/keep-smiling-waste-spammers-time.html, the slightly more verbose http://bsdly.blogspot.com/2014/02/effective-spam-and-malware.html and about blacklists management with spamd tools http://bsdly.blogspot.com/2013/04/maintaining-publicly-available.html as well as of course a few items on incidents involving systems I run.