Commit | Line | Data |
---|---|---|
87ba3f5f | 1 | $Cambridge: exim/doc/doc-txt/NewStuff,v 1.42 2005/05/17 15:00:04 ph10 Exp $ |
495ae4b0 PH |
2 | |
3 | New Features in Exim | |
4 | -------------------- | |
5 | ||
6 | This file contains descriptions of new features that have been added to Exim, | |
7 | but have not yet made it into the main manual (which is most conveniently | |
8 | updated when there is a relatively large batch of changes). The doc/ChangeLog | |
9 | file contains a listing of all changes, including bug fixes. | |
10 | ||
11 | ||
e5a9dba6 PH |
12 | Exim version 4.52 |
13 | ----------------- | |
14 | ||
15 | TF/01 Support for checking Client SMTP Authorization has been added. CSA is a | |
16 | system which allows a site to advertise which machines are and are not | |
17 | permitted to send email. This is done by placing special SRV records in | |
18 | the DNS, which are looked up using the client's HELO domain. At this | |
19 | time CSA is still an Internet-Draft. | |
20 | ||
21 | Client SMTP Authorization checks are performed by the ACL condition | |
22 | verify=csa. This will fail if the client is not authorized. If there is | |
23 | a DNS problem, or if no valid CSA SRV record is found, or if the client | |
24 | is authorized, the condition succeeds. These three cases can be | |
25 | distinguished using the expansion variable $csa_status, which can take | |
26 | one of the values "fail", "defer", "unknown", or "ok". The condition | |
27 | does not itself defer because that would be likely to cause problems | |
28 | for legitimate email. | |
29 | ||
30 | The error messages produced by the CSA code include slightly more | |
31 | detail. If $csa_status is "defer" this may be because of problems | |
32 | looking up the CSA SRV record, or problems looking up the CSA target | |
33 | address record. There are four reasons for $csa_status being "fail": | |
34 | the client's host name is explicitly not authorized; the client's IP | |
35 | address does not match any of the CSA target IP addresses; the client's | |
36 | host name is authorized but it has no valid target IP addresses (e.g. | |
37 | the target's addresses are IPv6 and the client is using IPv4); or the | |
38 | client's host name has no CSA SRV record but a parent domain has | |
39 | asserted that all subdomains must be explicitly authorized. | |
40 | ||
41 | The verify=csa condition can take an argument which is the domain to | |
42 | use for the DNS query. The default is verify=csa/$sender_helo_name. | |
43 | ||
44 | This implementation includes an extension to CSA. If the query domain | |
45 | is an address literal such as [192.0.2.95], or if it is a bare IP | |
46 | address, Exim will search for CSA SRV records in the reverse DNS as if | |
47 | the HELO domain was e.g. 95.2.0.192.in-addr.arpa. Therefore it is | |
48 | meaningful to say, for example, verify=csa/$sender_host_address - in | |
49 | fact, this is the check that Exim performs if the client does not say | |
50 | HELO. This extension can be turned off by setting the main | |
51 | configuration option dns_csa_use_reverse = false. | |
52 | ||
53 | If a CSA SRV record is not found for the domain itself, then a search | |
54 | is performed through its parent domains for a record which might be | |
55 | making assertions about subdomains. The maximum depth of this search is | |
56 | limited using the main configuration option dns_csa_search_limit, which | |
57 | takes the value 5 by default. Exim does not look for CSA SRV records in | |
58 | a top level domain, so the default settings handle HELO domains as long | |
59 | as seven (hostname.five.four.three.two.one.com) which encompasses the | |
60 | vast majority of legitimate HELO domains. | |
61 | ||
62 | The dnsdb lookup also has support for CSA. Although dnsdb already | |
63 | supports SRV lookups, this is not sufficient because of the extra | |
64 | parent domain search behaviour of CSA, and (as with PTR lookups) | |
65 | dnsdb also turns IP addresses into lookups in the reverse DNS space. | |
66 | The result of ${lookup dnsdb {csa=$sender_helo_name} } has two | |
67 | space-separated fields: an authorization code and a target host name. | |
68 | The authorization code can be "Y" for yes, "N" for no, "X" for explicit | |
69 | authorization required but absent, or "?" for unknown. | |
70 | ||
c1ac6996 PH |
71 | PH/01 The amount of output produced by the "make" process has been reduced, |
72 | because the compile lines are often rather long, making it all pretty | |
73 | unreadable. The new style is along the lines of the 2.6 Linux kernel: | |
74 | just a short line for each module that is being compiled or linked. | |
75 | However, it is still possible to get the full output, by calling "make" | |
76 | like this: | |
77 | ||
78 | FULLECHO='' make -e | |
79 | ||
80 | The value of FULLECHO defaults to "@", the flag character that suppresses | |
81 | command reflection in "make". When you ask for the full output, it is | |
82 | given in addition to the the short output. | |
83 | ||
87ba3f5f PH |
84 | PH/02 There have been two changes concerned with submission mode: |
85 | ||
86 | (a) A new option, /name=value, makes it possible to supply a user name | |
87 | to be inserted into any created Sender: header line. Typically, this | |
88 | would be looked up from $authenticated_id. | |
89 | ||
90 | (b) The envelope sender address is forced to be the same as the | |
91 | submission mode sender address. | |
92 | ||
e5a9dba6 | 93 | |
b5aea5e1 PH |
94 | Version 4.51 |
95 | ------------ | |
96 | ||
1a46a8c5 PH |
97 | PH/01 The format in which GnuTLS parameters are written to the gnutls-param |
98 | file in the spool directory has been changed. This change has been made | |
99 | to alleviate problems that some people had with the generation of the | |
100 | parameters by Exim when /dev/random was exhausted. In this situation, | |
101 | Exim would hang until /dev/random acquired some more entropy. | |
102 | ||
103 | The new code exports and imports the DH and RSA parameters in PEM | |
104 | format. This means that the parameters can be generated externally using | |
105 | the certtool command that is part of GnuTLS. | |
106 | ||
107 | To replace the parameters with new ones, instead of deleting the file | |
108 | and letting Exim re-create it, you can generate new parameters using | |
109 | certtool and, when this has been done, replace Exim's cache file by | |
110 | renaming. The relevant commands are something like this: | |
111 | ||
112 | # rm -f new.params | |
113 | # touch new.params | |
114 | # chown exim:exim new.params | |
115 | # chmod 0400 new.params | |
116 | # certtool --generate-privkey --bits 512 >new.params | |
117 | # echo "" >>new.params | |
118 | # certtool --generate-dh-params --bits 1024 >> new.params | |
119 | # mv new.params params | |
120 | ||
121 | If Exim never has to generate the parameters itself, the possibility of | |
122 | stalling is removed. | |
123 | ||
124 | PH/02 A new expansion item for dynamically loading and calling a locally- | |
125 | written C function is now provided, if Exim is compiled with | |
126 | ||
127 | EXPAND_DLFUNC=yes | |
128 | ||
129 | set in Local/Makefile. The facility is not included by default (a | |
130 | suitable error is given if you try to use it when it is not there.) | |
4754440d PH |
131 | |
132 | If you enable EXPAND_DLFUNC, you should also be aware of the new redirect | |
133 | router option forbid_filter_dlfunc. If you have unprivileged users on | |
134 | your system who are permitted to create filter files, you might want to | |
135 | set forbid_filter_dlfunc=true in the appropriate router, to stop them | |
136 | using ${dlfunc to run code within Exim. | |
137 | ||
138 | You load and call an external function like this: | |
1a46a8c5 PH |
139 | |
140 | ${dlfunc{/some/file}{function}{arg1}{arg2}...} | |
141 | ||
4754440d PH |
142 | Once loaded, Exim remembers the dynamically loaded object so that it |
143 | doesn't reload the same object file in the same Exim process (but of | |
144 | course Exim does start new processes frequently). | |
1a46a8c5 PH |
145 | |
146 | There may be from zero to eight arguments to the function. When compiling | |
147 | a local function that is to be called in this way, local_scan.h should be | |
148 | included. The Exim variables and functions that are defined by that API | |
149 | are also available for dynamically loaded functions. The function itself | |
150 | must have the following type: | |
151 | ||
152 | int dlfunction(uschar **yield, int argc, uschar *argv[]) | |
153 | ||
154 | Where "uschar" is a typedef for "unsigned char" in local_scan.h. The | |
155 | function should return one of the following values: | |
156 | ||
157 | OK Success. The string that is placed in "yield" is put into | |
158 | the expanded string that is being built. | |
159 | ||
160 | FAIL A non-forced expansion failure occurs, with the error | |
161 | message taken from "yield", if it is set. | |
162 | ||
163 | FAIL_FORCED A forced expansion failure occurs, with the error message | |
164 | taken from "yield" if it is set. | |
165 | ||
166 | ERROR Same as FAIL, except that a panic log entry is written. | |
167 | ||
168 | When compiling a function that is to be used in this way with gcc, | |
169 | you need to add -shared to the gcc command. Also, in the Exim build-time | |
170 | configuration, you must add -export-dynamic to EXTRALIBS. | |
b5aea5e1 | 171 | |
7dbf77c9 PH |
172 | TF/01 $received_time is a new expansion variable containing the time and date |
173 | as a number of seconds since the start of the Unix epoch when the | |
174 | current message was received. | |
b5aea5e1 | 175 | |
7766a4f0 PH |
176 | PH/03 There is a new value for RADIUS_LIB_TYPE that can be set in |
177 | Local/Makefile. It is RADIUSCLIENTNEW, and it requests that the new API, | |
178 | in use from radiusclient 0.4.0 onwards, be used. It does not appear to be | |
179 | possible to detect the different versions automatically. | |
180 | ||
54cdb463 PH |
181 | PH/04 There is a new option called acl_not_smtp_mime that allows you to scan |
182 | MIME parts in non-SMTP messages. It operates in exactly the same way as | |
183 | acl_smtp_mime | |
184 | ||
cf00dad6 PH |
185 | PH/05 It is now possible to redefine a macro within the configuration file. |
186 | The macro must have been previously defined within the configuration (or | |
187 | an included file). A definition on the command line using the -D option | |
188 | causes all definitions and redefinitions within the file to be ignored. | |
189 | In other words, -D overrides any values that are set in the file. | |
190 | Redefinition is specified by using '==' instead of '='. For example: | |
191 | ||
192 | MAC1 = initial value | |
193 | ... | |
194 | MAC1 == updated value | |
195 | ||
196 | Redefinition does not alter the order in which the macros are applied to | |
197 | the subsequent lines of the configuration file. It is still the same | |
198 | order in which the macros were originally defined. All that changes is | |
199 | the macro's value. Redefinition makes it possible to accumulate values. | |
200 | For example: | |
201 | ||
202 | MAC1 = initial value | |
203 | ... | |
204 | MAC1 == MAC1 and something added | |
205 | ||
206 | This can be helpful in situations where the configuration file is built | |
207 | from a number of other files. | |
208 | ||
209 | PH/06 Macros may now be defined or redefined between router, transport, | |
210 | authenticator, or ACL definitions, as well as in the main part of the | |
211 | configuration. They may not, however, be changed within an individual | |
212 | driver or ACL, or in the local_scan, retry, or rewrite sections of the | |
213 | configuration. | |
214 | ||
475fe28a PH |
215 | PH/07 $acl_verify_message is now set immediately after the failure of a |
216 | verification in an ACL, and so is available in subsequent modifiers. In | |
217 | particular, the message can be preserved by coding like this: | |
218 | ||
219 | warn !verify = sender | |
220 | set acl_m0 = $acl_verify_message | |
221 | ||
222 | Previously, $acl_verify_message was set only while expanding "message" | |
223 | and "log_message" when a very denied access. | |
224 | ||
e4a89c47 PH |
225 | PH/08 The redirect router has two new options, sieve_useraddress and |
226 | sieve_subaddress. These are passed to a Sieve filter to specify the :user | |
227 | and :subaddress parts of an address. Both options are unset by default. | |
228 | However, when a Sieve filter is run, if sieve_useraddress is unset, the | |
229 | entire original local part (including any prefix or suffix) is used for | |
230 | :user. An unset subaddress is treated as an empty subaddress. | |
475fe28a | 231 | |
be22d70e PH |
232 | PH/09 Quota values can be followed by G as well as K and M. |
233 | ||
2e0c1448 PH |
234 | PH/10 $message_linecount is a new variable that contains the total number of |
235 | lines in the header and body of the message. Compare $body_linecount, | |
236 | which is the count for the body only. During the DATA and | |
237 | content-scanning ACLs, $message_linecount contains the number of lines | |
238 | received. Before delivery happens (that is, before filters, routers, and | |
239 | transports run) the count is increased to include the Received: header | |
240 | line that Exim standardly adds, and also any other header lines that are | |
241 | added by ACLs. The blank line that separates the message header from the | |
242 | body is not counted. Here is an example of the use of this variable in a | |
243 | DATA ACL: | |
244 | ||
245 | deny message = Too many lines in message header | |
246 | condition = \ | |
247 | ${if <{250}{${eval: $message_linecount - $body_linecount}}} | |
248 | ||
249 | In the MAIL and RCPT ACLs, the value is zero because at that stage the | |
250 | message has not yet been received. | |
251 | ||
d20976dc PH |
252 | PH/11 In a ${run expansion, the variable $value (which contains the standard |
253 | output) is now also usable in the "else" string. | |
254 | ||
2e2a30b4 PH |
255 | PH/12 In a pipe transport, although a timeout while waiting for the pipe |
256 | process to complete was treated as a delivery failure, a timeout while | |
257 | writing the message to the pipe was logged, but erroneously treated as a | |
258 | successful delivery. Such timeouts include transport filter timeouts. For | |
259 | consistency with the overall process timeout, these timeouts are now | |
260 | treated as errors, giving rise to delivery failures by default. However, | |
261 | there is now a new Boolean option for the pipe transport called | |
262 | timeout_defer, which, if set TRUE, converts the failures into defers for | |
263 | both kinds of timeout. A transport filter timeout is now identified in | |
264 | the log output. | |
265 | ||
7766a4f0 | 266 | |
f7b63901 | 267 | Version 4.50 |
35edf2ff PH |
268 | ------------ |
269 | ||
b9e40c51 | 270 | The documentation is up-to-date for the 4.50 release. |
495ae4b0 PH |
271 | |
272 | **** |