Table of Contents
What's this ??? “Network Classes” is a way to handle in a differently connections coming from different sources. Surely, you don't want to grant the same rights to clients in your local network and unknown clients in the other side of the world. Assigning “Network Classes” to networks is a comprehensive way to aggregate heterogeneous networks (IPv4, IPv6, host names, …) in order to assign common privileges, without having to specify all IP addresses/networks for each control parameter.
Historically, network classes were defined only by IP addresses in a flat text file, but other criteria were added to define classes.
This was the first and simplest way to define netclasses. This idea is : you can classify people who can connect to your mailserver in the following categories :
- LOCAL - SMTP clients in your really local network.
- DOMAIN - SMTP clients in your domain. This may be the case if your domain covers many geographically distinct sites.
- FRIEND - some SMTP clients with whom you talk frequently and you can give some privileges.
- AUTH - people connecting to your mailserver from everywhere and using your mailserver to relay their messages. E. g. roaming users. This network class isn't explicitly defined. Connections are put in this class, if the SMTP client use an anthenticated connection.
- OTHER - known networks to which you may want to use other labels than LOCAL, DOMAIN or FRIEND. This will be explained in the next paragraph.
- UNKNOWN - all other IP addresses not defined as above.
Network Classes are defined at ze-policy database in the following way :
NetClass:10 LOCAL NetClass:193.200 DOMAIN NetClass:193.200.3 LOCAL NetClass:domain.com DOMAIN NetClass:126.96.36.199 FRIEND NetClass:2001:660:3312:0:0:0:0:0/48 DOMAIN
NetClass names are case insensitive, may contain alphabets and underscores: a-z, A-Z, _, and should be reasonably short.
Sometimes, bundled categories (LOCAL, DOMAIN, and FRIEND) aren't enough to you and you'd like to define your own categories based, e.g., on the departments of your organisation. You can define your own classes.
NetClass:10.1.1 MATH NetClass:10.1.2 PHYSICS NetClass:10.1.3 MANAGEMENT ...
Classes defined this way are part of “KNOWN” networks and have the same privileges than them. But other than implicit privileges of known network classes, they inherit from default limits.
IP-RBWL (IP Realtime Black/White Lists)
IP-RBWL is a convenient way to define dynamic network classes. That means, the content of the class is defined elsewhere. A useful example is to network classes to assign very low limits to SMTP clients listed at some blacklist, or to apply greylisting filtering only to SMTP clients blacklisted.
<DNS-IP-RBWL> dnsbl.domain.com netclass=dnsbl; odds=2.0000; code=all; onmatch=stop; checks=addr,name </DNS-IP-RBWL>
# low limits ConnRate:dnsbl 3 ConnOpen:dnsbl 2 MsgRate:dnsbl 3 MaxMsgs:dnsbl 1 MaxRcpt:dnsbl 10 # apply greylisting only to blacklisted IP addresses GreyCheckConnect:default NO GreyCheckConnect:dnsbl YES-QUICK
DNS resolve fail or forged
Instead of applying binary decisions such as blocking connections from SMTP clients without DNS reverse resolution or incompatible direct/reverse DNS resolutions, one can assign lower resource limits to SMTP clients with these characteristics. The easiest way to do this is to assign a particular NetClass to this kind of SMTP client.
RESOLVE_FAIL_NETCLASS resfail RESOLVE_FORGED_NETCLASS resforged
Netclass configuration syntax
Below are some points you need to pay attention too when creating your policy files:
- A line that starts with a '#' is treated as comment.
- Comments aren't allowed in the same line as options: putting a '#' somewhere else, e.g. like this
NetClass:w.x.y.z CLASS # My comment
does not work.
- Lookup order of net classes: e.g. hostname.domain (w.x.y.z) is connecting to your mail server. The lookup order in ze-filter is: