How Groups Work

Groups, group administrators, and permissions are all defined in the database, but members of a group are defined in a group’s member list, which is stored in a subdirectory of the /opt/pmx6/members-per-group directory. For example, member lists Group1 and Group2 could appear as follows:


Notice that group lists are located within automatically generated subfolders whose names are based on the first two letters of the group name. This is to limit the number of files in a single folder in very large systems.

The elements of the list are email address parts, which take one of the following three forms:

  • Exact: ie/
  • User Inexact: ie/ user@
  • Domain Inexact: - ie/

The members-per-group directory is a default resource that is currently populated manually by the global administrator. This can be done by running the pmx-list command, editing a list directly, or using pmx-ldap-sync or some other tool to populate the list from an external source. The global administrator must then manually synchronize the changes to the members-per-group directory with the database via the pmx-profile sync-to-db and pmx-makemap --grouplist -g commands.

Note PureMessage uses pmx-profile and pmx-makemap --grouplist -g to regularly synchronize data with edge servers. If these jobs are enabled via the Local Services tab of the PureMessage Manager, it is not necessary to run these commands manually.

Recipient-to-Group Mappings

The pmx-makemap --grouplist -g command converts the contents of the members-per-group directory into one flat CDB map that maps recipients to groups. For example, it might look like this:

  • group1
  • group2
  • postmaster@: group3
  • group4

Every recipient entry in the members-per-group directory has a corresponding entry in the CDB map, with the right-hand column indicating the short name of the group that it is a member of. The CDB map defines the recipient-to-group mappings used by the PureMessage policy.

When the policy processes a message, the mappings are applied and data concerning the recipient/group relationships are written the message_log and the quarantine minfo log. This data cannot be retroactively assigned or changed after the message has been processed by the policy.

Two things are important in properly determining the recipient-to-group mappings for a message: traffic direction and precedence.

Traffic Direction

Mappings are evaluated only for the sender (ENVELOPE FROM address) if a message is outbound, and for all recipients ( ENVELOPE TO addresses) if the message is inbound. Traffic direction is determined based on the "internal-hosts" list, so if a message comes from a relay that is in the internal hosts list, it is expected that the message is outbound. Otherwise it is inbound.

Note If the ENVELOPE TO address is mapped to another address in the recipient-aliases map, the mapped address is used for group determination, rather than the original ENVELOPE_TO address.


A recipient-to-group mapping must be unique, so precedence is enforced in the determination of a group. The lookup works according to the following matching order:

  1. Exact: (for example,
  2. User Inexact: (for example, user@)
  3. Subdomain Inexact: (for example, The example below shows the precedence used for subdomains.
  4. Domain Inexact: (for example,

This means that if a message is to for example, the following matches would be tested against, with the first one returning:

  • joe@

The subsequent group information is then written to the message_log and the quarantine minfo (if any mapping exists for the addresses it checked). This information is then consumed by other scheduled jobs in the system (for example, pmx-qmeta-index and pmx-reports-consume-message-log) and used, for example, for group-specific reports and the quarantine.