SAUCE POLICY and RECIPIENT CLASSES ---------------------------------- SAUCE can (and should) be configured to treat different recipient addresses differently. When a RCPT command is received, SAUCE will determine what class the proposed recipient falls into. Then, depending on the class, it will decide whether to accept, defer or reject this recipient; the classes accepted for a particular message can also affect SAUCE's behaviour after it has received the message body. The categorisation of recipient addresses into classes may change from time to time or from message to message depending on other available information. RECIPIENT CLASSES ----------------- The recipient classes are: normal All normal SAUCE checking on the sending site's DNS and mail system, and on the syntax and semantics of the message headers, will be done. Mail from new sites and new senders will be delayed according to the configured policy. If a message goes to several "normal" recipients in a single SMTP transaction, the most strict SpamAssassin threshold of any of the those recipients is used. nodelay All the normal checks are done. However, mail will not be deferred solely because the sender or site is previously unknown to SAUCE. bait The address has been published in a way that will hopefully get it included in spammers' recipient lists, and never been published in a way that a human might accidentally mail it. SAUCE will blacklist the sending site and/or email addresses, according to its configuration. Mail for bait addresses is (usually) accepted and discarded, so that the bait addresses are not removed from spammers' lists. unchecked None of SAUCE's policy checks will be done. The intent is that SAUCE's behaviour for mail for unchecked recipients not be significantly different from that of the underlying MTA. HOWEVER: a single message delivery cannot go to both unchecked and normal/nodelay recipients, because SAUCE would be faced with a dilemma if the headers had policy problems - it would neither be correct to bounce, nor to accept, the mail. To avoid this, if SAUCE has already accepted a normal/nodelay address and is offered an unchecked one, or vice versa, SAUCE will defer the later address with a `450'. The calling site must retry the deferred address, but in practice may do so only some time later (and if it is broken, not at all). This means that messages sent to a mixture of normal/nodelay addresses and unchecked addresses will sometimes be delayed for at least some recipients. For this reason unchecked addresses should be used sparingly; they are intended for mail administration role addresses such as postmaster which *must* not reject mail spuriously. lax None of SAUCE's policy checks that can be applied at the RCPT stage will be done, and unless the same message is also sent to some normal/nodelay recipients, lax is just the same as unchecked. However, if single message is sent to a mixture of lax and normal/nodelay addresses, problems with its headers may cause the whole message transaction to be rejected, so that even the lax recipient will not receive it. This avoids the problem with `unchecked' above: instead of deferring the later address class with `450', SAUCE will accept all the recipients, but risk rejecting the whole mail - even for the lax recipients - if the headers reveal problems. If a message goes to several "lax" recipients, the most relaxed SpamAssassin threshold of any of the those recipients is used; however if it also goes to "normal" recipients, the message will still be rejected if any of the "normal" recipients wants to reject it. 450 451 452 550 552 553 These recipient classes specify directly the response to be sent to the RCPT command. Usually 550 or 450 should be used. Ordinary mail recipient addresses should use one of normal, nodelay or lax, along with possibly 550 to block specific kinds of mail. When to use lax and when to use unchecked ? ------------------------------------------- lax and unchecked are identical for messages which are not also sent to some normal/nodelay addresses, or for messages/sites with problems which SAUCE detects before seeing the headers. The only difference between them comes when a single message is sent to both normal/nodelay and lax/unchecked addresses (and there are no problems which show up before the message headers are seen). With unchecked, whenever such a message is sent, at least some of the recipients will recieve their copy of the mail late - even if there is nothing wrong with the mail, and they are regular correspondents. However, the unchecked recipients will receive the mail even if the headers are broken. With lax, if the message has no problems revealed by the headers, it will be delivered without delay to all of the recipients. However, if the headers have problems then the mail will be rejected after the body has been received, and so none of the recipients will receive it. Therefore, `unchecked' is more appropriate for administrative and problem-reporting addresses. `lax' should be used for normal correspondence, to avoid spurious delays to routine mail. POLICY FILE SYNTAX ------------------ SAUCE can be configured by the use of recipient policy files. These are a series of lines which look like this [-] followed by a single line containing only `.'. Blank lines are permitted. Lines starting with # are comments. is one of [] [/] (where the [ and ] are literals and must actually appear surrounding the address or mask/length.) is one of @ (not ending in @) (To match `<>' when specified as envelope sender, match `@' instead.) globs may contain no whitespace. They support [...], ? and * and \-escapes for those metacharacters. There is no way to specify patterns including whitespace. , where present, is one or more of the following *in this order*, separated by hyphens: errok Sending sites which generate errors when trying to mail (only) `errok' addresses will not make SAUCE angry; instead each such error will simply have the anger penalty acted out straight away and then forgotten. sa= | sa=skip | sa=scan Reject messages if their SpamAssassin spamscore is more than . "skip" disables SpamAssassin processing, "scan" enables it but just adds the headers, and never rejects. is a nonnegative number in decimal with possible fractional part, and possible sign at the start. (Note, when sa=*-policy or sa=*-user appears in an addr_regexp in the SAUCE config, the sa-* will only be applied if *some* rule in the specified policy matched. Usually it will be desirable to either provide a similar addr_regexp with a specific fallback policy, or a * * * policy in the policy config.) is the address class, ie one of 450|451|452|550|552|553 normal|lax|nodelay|bait|unchecked as specified above. The first matching line in the policy is determining. INSTALLING AND USING POLICY --------------------------- When a RCPT is issued the SAUCE configuration may direct that a policy file be used. This is done with the addr_regexp configuration directive. Policy files have to be compiled and installed into SAUCE's internal policy directory (/var/lib/sauce/policies by default), using the sauce-setsyspolicy and sauce-setuserpolicy commands. There are two special kinds of `class' which can be used in addr_regexp, `policy' for system policies specified by the administrator, and `user' for policies specified by individual users using userv. They work as follows: Recipient class Subpolicy argument in addr_regexp to sauce-set*policy Default policy file policy /etc/sauce/policy policy= : /etc/sauce/policy: policy=: ::$1 /etc/sauce/policy::$1 user ~$1/.sauce-policy user= ~/.sauce-policy user=: :$1 ~/.sauce-policy:$1 user=: : ~/.sauce-policy: user=:: ::$1 ~/.sauce-policy::$1 Here $1 is the first regexp match substring string from the addr_regexp, after the destination address has matched. In the regexp match all characters except 7-bit alphanumerics and the puncutuation characters - + _ . % $ will be replaced with ?, and if there are any more than 126 characters all extra ones will be replaced with *, before the relevant policy is looked up. Do not attempt to set or use policies whose names contain `/'. In any case, if the relevant policy has not been installed, or no line in the policy matches, then the addr_regexp processing continues as if the regexp had not matched. $Id: POLICY-CONFIG.text,v 1.3 2003/09/07 22:49:20 ian Exp $