-1. ACL variables can now be given arbitrary names, as long as they start with
- "acl_c" or "acl_m" (for connection variables and message variables), are
- at least six characters long, with the sixth character being either a digit
- or an underscore. The rest of the name can contain alphanumeric characters
- and underscores. This is a compatible change because the old set of
- variables such as acl_m12 are a subset of the allowed names. There may now
- be any number of ACL variables. For example:
-
- set acl_c13 = value for original ACL variable
- set acl_c13b = whatever
- set acl_m_foo = something
-
- What happens if a syntactically valid but undefined ACL variable is
- referenced depends on the setting of the strict_acl_vars option. If it is
- false (the default), an empty string is substituted; if it is true, an error
- is generated. This affects all ACL variables, including the "old" ones such
- as acl_c4. (Previously there wasn't the concept of an undefined ACL
- variable.)
-
- The implementation has been done in such a way that spool files containing
- ACL variable settings written by previous releases of Exim are compatible
- and can be read by the new release. If only the original numeric names are
- used, spool files written by the new release can be read by earlier
- releases.
-
-2. There is a new ACL modifier called log_reject_target. It makes it possible
- to specify which logs are used for messages about ACL rejections. Its
- argument is a list of words which can be "main", "reject", or "panic". The
- default is "main:reject". The list may be empty, in which case a rejection
- is not logged at all. For example, this ACL fragment writes no logging
- information when access is denied:
-
- deny <some conditions>
- log_reject_target =
-
- The modifier can be used in SMTP and non-SMTP ACLs. It applies to both
- permanent and temporary rejections.
-
-3. There is a new authenticator called "dovecot". This is an interface to the
- authentication facility of the Dovecot POP/IMAP server, which can support a
- number of authentication methods. If you are using Dovecot to authenticate
- POP/IMAP clients, it might be helpful to use the same mechanisms for SMTP
- authentication. This is a server authenticator only. The only option is
- server_socket, which must specify the socket which is the interface to
- Dovecot authentication. The public_name option must specify an
- authentication mechanism that Dovecot is configured to support. You can have
- several authenticators for different mechanisms. For example:
-
- dovecot_plain:
- driver = dovecot
- public_name = PLAIN
- server_name = /var/run/dovecot/auth-client
- server_setid = $auth1
-
- dovecot_ntlm:
- driver = dovecot
- public_name = NTLM
- server_name = /var/run/dovecot/auth-client
- server_setid = $auth1
-
-4. The variable $message_headers_raw provides a concatenation of all the
- messages's headers without any decoding. This is in contrast to
- $message_headers, which does RFC2047 decoding on the header contents.
-
-5. In a DNS black list, when the facility for restricting the matching IP
- values is used, the text from the TXT record that is set in $dnslist_text
- may not reflect the true reason for rejection. This happens when lists are
- merged and the IP address in the A record is used to distinguish them;
- unfortunately there is only one TXT record. One way round this is not to use
- merged lists, but that can be inefficient because it requires multiple DNS
- lookups where one would do in the vast majority of cases when the host of
- interest is not on any of the lists.
-
- A less inefficient way of solving this problem has now been implemented. If
- two domain names, comma-separated, are given, the second is used first to do
- an initial check, making use of any IP value restrictions that are set. If
- there is a match, the first domain is used, without any IP value
- restrictions, to get the TXT record. As a byproduct of this, there is also a
- check that the IP being tested is indeed on the first list. The first domain
- is the one that is put in $dnslist_domain. For example:
-
- reject message = rejected because $sender_ip_address is blacklisted \
- at $dnslist_domain\n$dnslist_text
- dnslists = sbl.spamhaus.org,sbl-xbl.spamhaus.org=127.0.0.2 : \
- dul.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.10
-
- For the first blacklist item, this starts by doing a lookup in
- sbl-xbl.spamhaus.org and testing for a 127.0.0.2 return. If there is a
- match, it then looks in sbl.spamhaus.org, without checking the return value,
- and as long as something is found, it looks for the corresponding TXT
- record. If there is no match in sbl-xbl.spamhaus.org, nothing more is done.
- The second blacklist item is processed similarly.
-
- If you are interested in more than one merged list, the same list must be
- given several times, but because the results of the DNS lookups are cached,
- the DNS calls themselves are not repeated. For example:
-
- reject dnslists = http.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.2 : \
- socks.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.3 : \
- misc.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.4 : \
+ 1. ACL variables can now be given arbitrary names, as long as they start with
+ "acl_c" or "acl_m" (for connection variables and message variables), are at
+ least six characters long, with the sixth character being either a digit or
+ an underscore. The rest of the name can contain alphanumeric characters and
+ underscores. This is a compatible change because the old set of variables
+ such as acl_m12 are a subset of the allowed names. There may now be any
+ number of ACL variables. For example:
+
+ set acl_c13 = value for original ACL variable
+ set acl_c13b = whatever
+ set acl_m_foo = something
+
+ What happens if a syntactically valid but undefined ACL variable is
+ referenced depends on the setting of the strict_acl_vars option. If it is
+ false (the default), an empty string is substituted; if it is true, an
+ error is generated. This affects all ACL variables, including the "old"
+ ones such as acl_c4. (Previously there wasn't the concept of an undefined
+ ACL variable.)
+
+ The implementation has been done in such a way that spool files containing
+ ACL variable settings written by previous releases of Exim are compatible
+ and can be read by the new release. If only the original numeric names are
+ used, spool files written by the new release can be read by earlier
+ releases.
+
+ 2. There is a new ACL modifier called log_reject_target. It makes it possible
+ to specify which logs are used for messages about ACL rejections. Its
+ argument is a list of words which can be "main", "reject", or "panic". The
+ default is "main:reject". The list may be empty, in which case a rejection
+ is not logged at all. For example, this ACL fragment writes no logging
+ information when access is denied:
+
+ deny <some conditions>
+ log_reject_target =
+
+ The modifier can be used in SMTP and non-SMTP ACLs. It applies to both
+ permanent and temporary rejections.
+
+ 3. There is a new authenticator called "dovecot". This is an interface to the
+ authentication facility of the Dovecot POP/IMAP server, which can support a
+ number of authentication methods. If you are using Dovecot to authenticate
+ POP/IMAP clients, it might be helpful to use the same mechanisms for SMTP
+ authentication. This is a server authenticator only. The only option is
+ server_socket, which must specify the socket which is the interface to
+ Dovecot authentication. The public_name option must specify an
+ authentication mechanism that Dovecot is configured to support. You can
+ have several authenticators for different mechanisms. For example:
+
+ dovecot_plain:
+ driver = dovecot
+ public_name = PLAIN
+ server_name = /var/run/dovecot/auth-client
+ server_setid = $auth1
+
+ dovecot_ntlm:
+ driver = dovecot
+ public_name = NTLM
+ server_name = /var/run/dovecot/auth-client
+ server_setid = $auth1
+
+ If the SMTP connection is encrypted, or if $sender_host_address is equal to
+ $interface_address (that is, the connection is local), the "secured" option
+ is passed in the Dovecot authentication command. If, for a TLS connection,
+ a client certificate has been verified, the "valid-client-cert" option is
+ passed.
+
+ 4. The variable $message_headers_raw provides a concatenation of all the
+ messages's headers without any decoding. This is in contrast to
+ $message_headers, which does RFC2047 decoding on the header contents.
+
+ 5. In a DNS black list, when the facility for restricting the matching IP
+ values is used, the text from the TXT record that is set in $dnslist_text
+ may not reflect the true reason for rejection. This happens when lists are
+ merged and the IP address in the A record is used to distinguish them;
+ unfortunately there is only one TXT record. One way round this is not to
+ use merged lists, but that can be inefficient because it requires multiple
+ DNS lookups where one would do in the vast majority of cases when the host
+ of interest is not on any of the lists.
+
+ A less inefficient way of solving this problem has now been implemented. If
+ two domain names, comma-separated, are given, the second is used first to
+ do an initial check, making use of any IP value restrictions that are set.
+ If there is a match, the first domain is used, without any IP value
+ restrictions, to get the TXT record. As a byproduct of this, there is also
+ a check that the IP being tested is indeed on the first list. The first
+ domain is the one that is put in $dnslist_domain. For example:
+
+ reject message = rejected because $sender_ip_address is blacklisted \
+ at $dnslist_domain\n$dnslist_text
+ dnslists = sbl.spamhaus.org,sbl-xbl.spamhaus.org=127.0.0.2 : \