Skip to content
Sandro Mello edited this page Jun 23, 2017 · 16 revisions

Policies and Pools

A policy is a set of rules that strictly control the behavior of messages sent and received, the configuration is very flexible, so every policy will compare the objects of a particular connection and tries to match with Source and Destination rules in policies, for each one you can specify a group to match different conditions of a particular connection.

A connection to milter will loop for all the policies configured on the system, to save resources you could use pools of policies. A pool is a set of server names for running isolated policies, each pool could have multiple policies.

How does it work?

For every new connection:

  • The milter get the hostname of the MTA that is establishing the connection;
  • Certifies that the the server belongs to a pool;
  • Execute every policy on that corresponding pool ONLY.

What are the benefits of using pools?

  • Saving resources: preveting the execution of policies that does not belong to a particular connection;
  • Segment the logic of MTA's: this way it's possible to have groups of policies: outbound, inbound, dedicated_servers, etc;
  • No need for creating new policy servers to coverage all your MTA logic business;
  • Connections that don't belong to a particular policy should not be executed and scramble the data.

Policies - attributes

As stated before, the policies strictly control the behavior of messages, which comes over the attributes, each attribute control a specific behavior of a particular connection, the list bellow has the description of each attribute:

  • Source - Match the FROM of a connection
  • Destination - Match the TO of a connection
  • Enable - Enable or disable the policy
  • Type - If it's a regular policy, or should bypass the connection
  • Priority - The priority of the policy
  • JailBy - By which criteria the object is going to be rate limited and stored
  • JailSpec - The specification of how many messages the object could process
  • JailAction - The behavior in case of reaching the condition of JailSpec
  • ReplyData - The message to be sent when rejecting the connection
  • OnlyHeaders - This policy should only process the ActionHeaders behavior
  • CountRCPT - In case of multiple recipients will count each of then as the total of requests
  • StopHere - Stop processing additional policies
  • RequestsMon - Monitor the requests of this policy
  • SubjectProbation - Time (hours) in which the data stored for the feature subjectReputationFeature should be maintained
  • CountSentProbation - Time (hours) in which the data stored for sent messages by object should be maintained
  • IpProbation - Time (hours) in which the data stored for the feature ipReputationFeature should be maintained
  • BlockProbation - Time (hours) in which the data stored for the feature rateReputationFeature should be maintained
  • ActionHeaders - Tries to match a header in a message and then add a new header to the current message
  • SPF - Activate SPF validation. It will add a header with the status on every processed message. E.g.: Received-SPF : fail

Policies - attribute values

It's not necessary to set all the attributes above, there only two attributes required: Source and Destination, after the creation it's possible to see the default values of all attributes, check the command line reference guide for examples.

Type attribute

  • bypass: It will bypass the connection only if the Source has match
  • bypass+: It will bypass the connection if the Source and Destination match
  • regular: A regular policy

Priority attribute

Int type defining the priority of the policy

JailBy attribute

Smart Jail will match SASLUsername always, if does not found fallback to Sender. This is useful to prevent creating redundant policies

  • SenderIP: Use the sender ip address connection as object
  • Sender: Use the MAILFROM as object
  • Sender+: Smart Jail by sender
  • SenderDomain: Use the domain on MAILFROM as object
  • SenderDomain+: Smart Jail by domain
  • SASLUsername: Use the name of the user authenticated by SMTP instead of MAILFROM

JailAction attribute

  • block - Block the connection, the user will receive an error sending the e-mail
  • hold - Hold the message in postfix hold queue
  • monitor - Accept the connection and don't do nothing

ReplyData attribute

The message to sent when the client is blocked, must include the placeholder "%s"

Probation attributes

Float type defining the time of probation in hours

Source/Destination

It's possible to specify a keyword "any" that reference to any kind of object or add a group name, this group should be created first

Enable/OnlyHeaders/CountRCPT/RequestsMon/SPF

Boolean value, accept TRUE or FALSE in upper case

Group

Groups only exists to be included into Source and Destination attributes of policies.

How does it work when a group is in place on Source?

  • The milter tries to match the source group with MAILFROM* object in a redis SET
  • Fallback to an iteration through the set, if the object is not found in the redis SET
  • Tries to match an ip address with the MAILFROM object.

* The MAILFROM is changed acording to the configuration in JailBy, it could be a domain, a full account or an ip address.

How does it work when a group is in place on Destination?

  • The milter tries to match the destination group with TO (recipients) object
  • Iterate through the list of recipients trying to found one match with destination group

Important: The Destination attribute only validates the domain, so you should only include domains to the groups.

The groups accept the following syntax:

  • account@domain.tld - Matchs a full account object
  • @domain.tld - Matchs a domain object
  • a.b.c.d/CIDR - Matchs an ipv4 address

Metadata

Contains the information about the current and previous connection, it's only created if the Source and Destination has matched. After a new metadata is created all the data could be configured by this namespace, so if you want to change specific behavior of this object it's possible.

The attributes could be listed using the command line tool:

tmscli -a --metadata list

Metadata attributes

  • block_count - How many times this object was blocked
  • subject_repeated_count - How many times the subject was repeated
  • manual_block - If the account should be manually blocked
  • last_subject - The last subject of this object
  • subject_lastupdate - The last update of the subject
  • learningBlueMode - AI feature (unstable)
  • sentmessages_lastupdate - The last update of a sent message
  • learningRedMode - AI feature (unstable)
  • blue_creation_date - AI feature (unstable)
  • learnPredictSafeValue - AI feature (unstable)
  • bypass - Skip check for this object
  • ip_reputation_lastupdate - Last update of the ip reputation feature
  • last_update - Last update of this object
  • learnEscalationValue - AI feature (unstable)
  • predictBy - AI feature (unstable)

Check the features for more attributes