PolicyD
Policies
Structure
PolicyD policies are a means to categorise incoming email into groups such that group-specific rules can be applied against the email.
A policy has a name, a priority and one or more policy members which consist of a source specification and a destination specification. Multiple policy members are logically ORed together.
The source and destination specifications are a logically ANDed list of policy groups. Each policy group can contain one or more policy group members which are logically ORed together.
A policy group member can be either another policy group or an IP address or subnet or a full or partial email address.
If that sounds complicated then, um, it is.
Basics
By way of an example, let's look at the simplest case. Two really basic policies are incoming and outgoing mail. That's two categories of mail you are likely to want to apply different rules to. By and large you expect more spam to be coming inwards than going outwards -- but don't ignore the idea that one of your own machines may have been compromised and might be spewing spam out onto the internet.
So, where to start? Well, one thing we do know is ourselves, our own IP addresses and email domains.
Outgoing Mail
We need to create a policy group called, say, my_lans with our internal lans as the policy group members, say, 192.168.0.0/24 and 192.168.1.0/24 which contains all the machines we expect to want to send email.
Note
As it stands, any other internal networks will be regarded as an external source of email and have different rules applied.
In our messy world of compromised machines we should also be sure that the source email address is one of ours as well, so we'll need another policy group, say, my_domains with our own email domain names as policy group members, say, example.com and example.net.
Only together, the ANDed combination of being from a machine we expect to be sending email and with a source email address of one of our domains, is this email considered as legitimate outgoing email.
Note
That means if your colleague wants to send email as from bob@search.example, which he would have been able to do before, then he will now be appearing as illegitimate email trying to be sent from this network. Bob will have to log onto Search Corp's webmail service. Or persuade you to add some new category for him because he's a lazy ass. Not going to happen, Bob!
At this point you may already begin to see the need for increasingly nuanced discrimination between different senders. You might start to distinguish between general (and more likely to be compromised) desktop machines and heavily monitored servers, probably distinguish further if there are designated mail servers etc. etc..
Finally, then, we might be able to construct a policy called, say, Outgoing with a single policy member which has a source component of %my_lans,%my_domains and a destination component of any (a wildcard meaning, er, anything).
Note
The % is used to signify that the element is a policy group and should be looked up.
Incoming Mail
The policy for incoming mail isn't quite the reverse of outgoing mail. For a start, people sending you mail don't know what your (internal) lans are so we can't specify those. However, that's a starter for ten. An incoming mail policy called, Incoming with a single policy member which has a source component of any and a destination component of %my_domains.
That's not all, though. We know that we are sent email that is not for one of our domains. By and large such email is spam but there is bound to be some mis-configuration out there (although we cannot distinguish it from spam!).
So we ought to have another category, a fallback policy, of stuff we aren't expecting which we can brusquely drop on the floor: source any destination any.
More Categorisation
You'll probably start with some generous limits on how much email people can send to you start to recognise spammy behaviour at which point you'll start to clamp down on how much email random people on the Internet can send you. That limit might well drop down to low single figures depending on your expectations.
Before you do that you need to separate known trusted senders from the hoi-polloi -- by and large, other users or organisations with whom you exchange a lot of email. The chances are, though, that other users and organisations aren't really sending you vast numbers of emails every day and so you can still set reasonable restrictions on how much email can be sent.
If you are operating on behalf of a lot of people you will find that a distinct proportion are signed up for "Deal of the Day" promotions from legitimate organisations. These may well send bursts of thousands of emails in a short window (often in the morning). So you might want a category for trusted bulk mailers.
On the whole you also don't expect your own systems to be pumping out a lot of email so to avoid being labelled as a spammer in turn you might want to put a sensible limit on the amount of outgoing email you can send. Except your own email servers might well exceed that limit regularly. So, one policy for desktops and another for servers and yet another for the official email servers.
With outgoing email you can further categorise by whether the user has logged in to send email, in PolicyD terms, whether we have a SASLUsername attribute. We should(?) trust them a little more if they have logged in.
If you have tight control over your email you may well have restricted remote users to logging into your mail server (web mail or IMAP/POP3) in order to send outgoing email. In that case you should not expect incoming email to have a sender address of one of your own domains. So you might want to categorise that case separately (source is %my_domains and destination is any as we don't care where it is going we already know it is illegitimate because nothing offsite can be from one of our domains).
Note
You should have also created an SPF record in the DNS with -all meaning only the listed entities are expected to be sending mail on behalf of this domain.
When you enable some more aggressive modules you may find that large global organisations dedicated to email delivery cannot set up their email servers correctly as well as smaller organisations who core business isn't running emails servers. In both cases you may need categories to excuse them from certain tests.
Spoofing
Underlying all of this is that the only fact we have in our hands at the time we are processing an email is the IP address of the sender. Everything else might be entirely made up. How do we handle that? Hmm, with difficulty. Hence the presence of Sender Policy framework (SPF) and other mechanisms to try to mitigate spoofing. SPF, for one, hasn't been universally taken up and isn't always accurately maintained. On top of which it allows a soft fail fallback result that even giant search organisations enable thus defeating the point of it.
Document Actions