Enabling SMTP Content Filters

Wallace is a Kolab Groupware content-filter, adding functionality to the SMTP message pipeline like resource scheduling, enforcement of invitation policies, appending of footers and signatures, etc.

Invitation policies

The invitationpolicy module of Wallace processes incoming iTip invitations or replies which address a local user. Depending on the recipient’s invitation policy settings or the global default, the iTip message is either automatically processed or forwarded to the user’s inbox or calendar for manual confirmation.

To enable the resource scheduling module, add invitationpolicy to the list of active wallace modules in /etc/kolab/kolab.conf:

[wallace]
modules = invitationpolicy, ...

A user’s invitation policy settings are stored in LDAP using the kolabInvitationPolicy which can contain multiple values which are processed from top to bottom until one matches the situation. A global default can be defined in /etc/kolab/kolab.conf with

[wallace]
(...)
kolab_invitation_policy = EVENT_ACCEPT_IF_NO_CONFLICT:example.org, ALL_UPDATE_AND_NOTIFY, ALL_MANUAL

The following values can be used to compose the invitation policy set:

General invitation policy settings

(apply to all iTip object types)

  • ALL_MANUAL

    Forwards the message to the user’s inbox for manual processing in the client.

  • ALL_ACCEPT

    Always accepts the event invitation or task assignment. This will reply to the organizer with PARTSTAT=ACCEPTED and store the event in the user’s default calendar or tasklist respectively.

  • ALL_REJECT

    Always rejects the invitation or assignment. This will also store a copy of the rejected invitation in the user’s default calendar for later reference.

  • ALL_UPDATE

    When receiving an iTip REPLY, this policy automatically updates the copy of the referring object in the user’s personal folders with the updated participant status of the replying user. This also reacts on iTip CANCEL messages by updating the object’s status to CANCELLED and the transparency to TRANSPARENT.

  • ALL_UPDATE_AND_NOTIFY

    Same as ACT_UPDATE but with an additional notification email being sent to the recipient reporting the updated participants status or object properties which have changed.

  • ALL_SAVE_TO_FOLDER

    No automatic accepting or rejecting is being done for iTip invitations here but the invitation is being saved in the user’s default calendar or tasklist respectively and the iTip message is not forwarded to the user’s email inbox.

  • ALL_SAVE_AND_FORWARD

    Same as ALL_SAVE_TO_FOLDER but forwarding the original iTip message to the user’s email inbox for notification purposes.

  • ALL_CANCEL_DELETE

    When receiving an iTip CANCEL message, this policy removes the copy of the referring object from the user’s personal folders.

  • ALL_CANCEL_DELETE_AND_NOTIFY

    Same as ALL_CANCEL_DELETE but with an additional notification email being sent to the recipient reporting removal of the referred object.

Event-specific policy settings

  • EVENT_ACCEPT

    Same as ALL_ACCEPT but only applies for event invitations.

  • EVENT_ACCEPT_IF_NO_CONFLICT

    Same as EVENT_ACCEPT but only if the invitation doesn’t conflict with an existing event in the user’s calendar(s).

  • EVENT_TENTATIVE

    Same as EVENT_ACCEPT but replying with PARTSTAT=TENTATIVE.

  • EVENT_TENTATIVE_IF_NO_CONFLICT

    Same as EVENT_TENTATIVE_IF_NO_CONFLICT but replying with PARTSTAT=TENTATIVE.

  • EVENT_REJECT

    Same as ALL_REJECT but only applies for event invitations.

  • EVENT_REJECT_IF_CONFLICT

    Same as ACT_REJECT but only rejects invitations if they conflict with an existing event in the user’s calendar(s).

  • EVENT_SAVE_TO_FOLDER

    Same as ALL_SAVE_TO_FOLDER but only applies for event invitations.

  • EVENT_SAVE_AND_FORWARD

    Same as ALL_SAVE_AND_FORWARD but only applies for event invitations.

Task-specific policy settings

Basically all values from the General invitation policy settings but with the TASK_ prefix instead of ALL_.

Per sender invitation policies

Each policy identifier can have a sender filter appended with :[sender@]domain.tld. If present, the policy will only be applied if the sender of the iTip message matches the given domain or email address substring. Otherwise the entry will be ignored and the process continues with the next entry in the list.

Auto-updating all participant’s calendars

Along with the ALL_UPDATE policy, Wallace can also update copies of the referenced event in all the participant’s calendars. With the regular iTip workflow, an iTip REPLY will only inform the organizer about the participation status of an individual. Enabling the following config option in /etc/kolab/kolab.conf will instruct the server to automatically update the status in the personal calendars of each listed participant.

[wallace]
(...)
invitationpolicy_autoupdate_other_attendees_on_reply = true

Note

Auto-updating of all event copies is only executed if the event organizer receiving the iTip reply has activated the ALL_UPDATE invitation policy.

Resource scheduling

The resource scheduling module of Wallace can pick up incoming messages and identify iTip invitations which address a resource. The invited resource’s calendar is then consulted and the invitation is either accepted or declined depending on the resource’s availability for the requested time.

To enable the resource scheduling module, add resources to the list of active wallace modules in /etc/kolab/kolab.conf:

[wallace]
modules = resources, ...

Footers and signatures

Another Wallace module can append footers or signatures to outgoing messages. Enable this module by adding footer to the list of active wallace modules in /etc/kolab/kolab.conf:

[wallace]
modules = footer, ...
footer_text = /etc/kolab/footer.text
footer_html = /etc/kolab/footer.html

The module requires the following additional config options:

footer_text

Absolute path to a text file holding the contents of the footer to be added to plain text messages.

footer_html

Absolute path to a text file holding the HTML formatted contents of the footer to be added to outgoing HTML messages.

Debugging Wallace

When running in default mode, Wallace (wallaced) is writing warning messages to the pykolab log (as it is a part of the pykolab structure). For debug purposes Walllace can be made to increase the amount of verbal data written to the logfile. Increasing the debug level is done by starting the Wallace demon with the debug switch, as shown hereunder;

Manually via the console:

Stop Wallace

CentOS7/RHEL7

systemctl stop wallace

CentOS6/RHEL6

service wallace stop

Start Wallace “manually” with the debug switch

/usr/sbin/wallaced -l debug -d 9

This will bring debug output directly to the console, and it can be quite verbal. A different way to gain access to the debug information (in a less messy fashion) is to..

Change the startup script to set the debug switch:

Change the script /etc/sysconfig/wallace

# Set debug flag and level:
# FLAGS="--fork -l warning"
FLAGS="--fork -l debug --debug=9"

Restart Wallace

CentOS7/RHEL7

systemctl restart wallace

CentOS6/RHEL6

service wallace restart

As Wallace is a part of the pykolab framework, the debug information can be found in the pykolab log: /var/log/kolab/pykolab.log

To follow the debug messages added to the logfile live:

tail -f /var/log/kolab/pykolab.log