Network Classes

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.

Known/Unknown networks

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 :

  • KNOWN
    • 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:212.3.1.4                       FRIEND
NetClass:2001:660:3312:0:0:0:0:0/48      DOMAIN
All KNOWN networks have implicit privileges, as ze-filter considers you KNOW them, and you thrust them. So, filtering methods like greylisting, bad recipients count, … aren't applied to SMTP connections coming from KNOWN networks.

NetClass names are case insensitive, may contain alphabets and underscores: a-z, A-Z, _, and should be reasonably short.

Named networks

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:
    1. w.x.y.z
    2. w.x.y
    3. w
    4. hostname.domain
doc/concepts/netclass.txt · Last modified: 2018/02/09 15:51 by 127.0.0.1
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0