Many policies in slimta will be applied directly before queuing the message.
These are called queue policies, and they are especially useful because they
are executed once for every message and the results are persistently
stored. Spam filtering is an example of a great queue policy, because it is
expensive and the results can be stored in the
Envelope object as an
attribute or header.
Other policies in slimta will be applied directly before each delivery attempt, called relay policies. A great example of a relay policy would be recipient forwarding looked up from a database; you would want to make sure the latest forwarding rules are applied on each delivery attempt, to not use a stale rule. At the moment, no relay policies are included with slimta.
Addition of a
Date: header is a necessary policy for most MTAs, when the
original message lacks one. The header generally uses local time-zones written
as acronyms, for better human-readability.
Date: header addition is a queue policy, given by the
from slimta.policy.headers import AddDateHeader queue.add_policy(AddDateHeader())
Message-Id: header should be added by the first MTA receiving the
message from the client, if not by the client itself. The header should not be
overridden by any subsequent MTA handling the message. A
look similar to an email address: left- and right-parts separated by an
with the whole thing surrounded by
>. The right-part of the ID
is usually the FQDN of the MTA that first received the message. The left-part
should be a string that tries to uniquely identify the message from all the
other messages the MTA has or will handle. This uniqueness is usually attained
by concatenating a randomly-generated UUID to a timestamp.
Message-Id: header addition is a queue policy, given by the
from slimta.policy.headers import AddMessageIdHeader queue.add_policy(AddMessageIdHeader())
Received: header is the most unique and complicated header of those that
MTAs should add to a message. The header should be pre-pended to every message,
so that the order that each MTA handled the message is preserved. The header
does not have a strict, RFC-mandated format, but cr.yp.to has a good
recommendation that fits what most good MTAs will do, and slimta attempts to
Received: header addition is a queue policy, given by the
from slimta.policy.headers import AddReceivedHeader queue.add_policy(AddReceivedHeader())
Forwarding policies range from quite simple to exorbitantly complex. The
Forward policy included with slimta can only
handle static rules (e.g. not queried from a database) using regular
Because the mappings are static and thus will never become stale like a database
lookup might, this is implemented as a queue policy, given by the
from slimta.policy.forward import Forward fwd = Forward() fwd.add_mapping(r'(ian|icg)@example.com', 'firstname.lastname@example.org') queue.add_policy(fwd)
The included spam filtering mechanism uses SpamAssassin by making a socket
connection to a
spamd server. When used as a policy, the message is scanned
X-Spam-Status: header is added to the message with either
"NO" indicating spamminess. If spammy, another header
also added with the symbols used in the match.
SpamAssassin is an expensive operation, so it is implemented as a queue policy,
given by the
from slimta.policy.spamassassin import SpamAssassin queue.add_policy(SpamAssassin())