Connect:1.2.3 REJECT Connect:1.2.3.4 OK Connect:relay.domain RELAY To:another.domain RELAY From:friend.domain OK From:some.domain REJECT From:friend@some.domain OK To:olduser@ REJECTThis gives high flexibility without resorting to multiple maps. Even though the table might be hard to read, it is easy to generate it from simpler descriptions (e.g., different files). This is optional, the default behavior (and map content) is backward compatible (except for some slight enhancements). Since we tag the LHS, we can have `multiple' entries regarding the same `key', because they are distinguished by the tags. A drawback might be a larger map, as can be seen from the example. The entries above will allow connections from the IP number 1.2.3.4 and reject everything else in the net 1.2.3. It allows relaying from relay.domain and to another.domain.
By using FEATURE(`delay_checks') the rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, check_rcpt is the first check_* ruleset to be called. After it completes, check_mail and check_relay will be called in order. Moreover, one argument can be specified for the delay_checks feature:
This allows for simple exceptions from the tests, e.g. by activating the spamfriend option and having
To:abuse@ SPAMFRIENDin the access map, mail to abuse@localdomain will get through. It is also possible to specify a full address or an address with +detail:
To:abuse@abuse.my.domain SPAMFRIEND To:me+abuse@ SPAMFRIEND
HSubject: $>+CheckSubjectdoes not strip comments (in parentheses) before passing the value of the header field to CheckSubject. A default ruleset for headers which don't have a specific ruleset defined for them can be given by:
H*: $>CheckHdrAfter all of the headers are read, the check_eoh ruleset will be called for any final header-related checks. The ruleset is called with the number of headers and the size of all of the headers in bytes separated by $|. One example usage is to reject messages which do not have a Message-Id: header is given in the cf/README file.
A very first version of my header check rulesets is available for 8.10.
H?${macro}?hname: htemplate
The htemplate is macro-expanded before insertion into the message.
The header will be in the message if {macro} is set,
which can be done by
using any of the normal methods,
as well as with the
macro storage map
in a ruleset.
If one of these headers is in the input it is
reflected to the output regardless of these flags or
macros.
Example:
HMessage-Id: $>CheckMessageId
Kstorage macro
H?${MyMacro}?X-MsgId: ${MyMacro}
SCheckMessageId
R$< $+ @ $+ > $@ OK
R$+ $: $(storage {MyMacro} $@ Illegal Message-Id $) $1
Note: the syntax has been changed in beta 12, it was
without the question marks before:
H${macro}hname: htemplate
FEATURE(`dnsbl')
can be included several times with different arguments.
For example:
FEATURE(`dnsbl',`relays.mail-abuse.org') FEATURE(`dnsbl',`inputs.orbs.org')
LOCAL_RULESETS
SLocal_check_relay
R$* $: $&{client_resolve}
RTEMP $#error $@ 4.7.1 $: "450 Access temporarily denied. Cannot resolve PTR record for " $&{client_addr}
RFORGED $#error $@ 4.7.1 $: "450 Access temporarily denied. IP name possibly forged " $&{client_name}
RFAIL $#error $@ 4.7.1 $: "450 Access temporarily denied. IP name lookup failed " $&{client_name}
You can put these rules in any of the Local_check_* rulesets
depending on your needs.
{currHeader} contains the current header value as a quoted string. If {hdrlen} is greater than or equal MAXNAME the header has been truncated.