Commit | Line | Data |
---|---|---|
7bafa7d9 TK |
1 | From time to time, experimental features may be added to Exim. |
2 | While a feature is experimental, there will be a build-time | |
3 | option whose name starts "EXPERIMENTAL_" that must be set in | |
4 | order to include the feature. This file contains information | |
5 | about experimenatal features, all of which are unstable and | |
ee161e8f PH |
6 | liable to incompatibile change. |
7 | ||
8 | ||
3f7eeb86 PP |
9 | OCSP Stapling support |
10 | -------------------------------------------------------------- | |
11 | ||
12 | X509 PKI certificates expire and can be revoked; to handle this, the | |
13 | clients need some way to determine if a particular certificate, from a | |
14 | particular Certificate Authority (CA), is still valid. There are three | |
15 | main ways to do so. | |
16 | ||
17 | The simplest way is to serve up a Certificate Revocation List (CRL) with | |
18 | an ordinary web-server, regenerating the CRL before it expires. The | |
19 | downside is that clients have to periodically re-download a potentially | |
20 | huge file from every certificate authority it knows of. | |
21 | ||
22 | The way with most moving parts at query time is Online Certificate | |
23 | Status Protocol (OCSP), where the client verifies the certificate | |
24 | against an OCSP server run by the CA. This lets the CA track all | |
25 | usage of the certs. This requires running software with access to the | |
26 | private key of the CA, to sign the responses to the OCSP queries. OCSP | |
27 | is based on HTTP and can be proxied accordingly. | |
28 | ||
29 | The only widespread OCSP server implementation (known to this writer) | |
30 | comes as part of OpenSSL and aborts on an invalid request, such as | |
31 | connecting to the port and then disconnecting. This requires | |
32 | re-entering the passphrase each time some random client does this. | |
33 | ||
34 | The third way is OCSP Stapling; in this, the server using a certificate | |
35 | issued by the CA periodically requests an OCSP proof of validity from | |
36 | the OCSP server, then serves it up inline as part of the TLS | |
37 | negotiation. This approach adds no extra round trips, does not let the | |
38 | CA track users, scales well with number of certs issued by the CA and is | |
39 | resilient to temporary OCSP server failures, as long as the server | |
40 | starts retrying to fetch an OCSP proof some time before its current | |
41 | proof expires. The downside is that it requires server support. | |
42 | ||
43 | If Exim is built with EXPERIMENTAL_OCSP and it was built with OpenSSL, | |
44 | then it gains one new option: "tls_ocsp_file". | |
45 | ||
46 | The file specified therein is expected to be in DER format, and contain | |
47 | an OCSP proof. Exim will serve it as part of the TLS handshake. This | |
48 | option will be re-expanded for SNI, if the tls_certificate option | |
49 | contains $tls_sni, as per other TLS options. | |
50 | ||
51 | Exim does not at this time implement any support for fetching a new OCSP | |
52 | proof. The burden is on the administrator to handle this, outside of | |
53 | Exim. The file specified should be replaced atomically, so that the | |
54 | contents are always valid. Exim will expand the "tls_ocsp_file" option | |
55 | on each connection, so a new file will be handled transparently on the | |
56 | next connection. | |
57 | ||
98a3b527 | 58 | Exim will check for a valid next update timestamp in the OCSP proof; |
3f7eeb86 PP |
59 | if not present, or if the proof has expired, it will be ignored. |
60 | ||
61 | At this point in time, we're gathering feedback on use, to determine if | |
62 | it's worth adding complexity to the Exim daemon to periodically re-fetch | |
98a3b527 PP |
63 | OCSP files and somehow handling multiple files. There is no client support |
64 | for OCSP in Exim, this is feature expected to be used by mail clients. | |
3f7eeb86 PP |
65 | |
66 | ||
67 | ||
68 | ||
0b23848a | 69 | Brightmail AntiSpam (BMI) suppport |
ee161e8f PH |
70 | -------------------------------------------------------------- |
71 | ||
72 | Brightmail AntiSpam is a commercial package. Please see | |
73 | http://www.brightmail.com for more information on | |
74 | the product. For the sake of clarity, we'll refer to it as | |
75 | "BMI" from now on. | |
76 | ||
77 | ||
78 | 0) BMI concept and implementation overview | |
79 | ||
80 | In contrast to how spam-scanning with SpamAssassin is | |
81 | implemented in exiscan-acl, BMI is more suited for per | |
82 | -recipient scanning of messages. However, each messages is | |
83 | scanned only once, but multiple "verdicts" for multiple | |
84 | recipients can be returned from the BMI server. The exiscan | |
85 | implementation passes the message to the BMI server just | |
86 | before accepting it. It then adds the retrieved verdicts to | |
87 | the messages header file in the spool. These verdicts can then | |
88 | be queried in routers, where operation is per-recipient | |
89 | instead of per-message. To use BMI, you need to take the | |
90 | following steps: | |
91 | ||
92 | 1) Compile Exim with BMI support | |
3ec3e3bb | 93 | 2) Set up main BMI options (top section of Exim config file) |
ee161e8f PH |
94 | 3) Set up ACL control statement (ACL section of the config |
95 | file) | |
96 | 4) Set up your routers to use BMI verdicts (routers section | |
97 | of the config file). | |
98 | 5) (Optional) Set up per-recipient opt-in information. | |
99 | ||
8ff3788c | 100 | These four steps are explained in more details below. |
ee161e8f PH |
101 | |
102 | 1) Adding support for BMI at compile time | |
103 | ||
104 | To compile with BMI support, you need to link Exim against | |
105 | the Brighmail client SDK, consisting of a library | |
106 | (libbmiclient_single.so) and a header file (bmi_api.h). | |
107 | You'll also need to explicitly set a flag in the Makefile to | |
108 | include BMI support in the Exim binary. Both can be achieved | |
109 | with these lines in Local/Makefile: | |
110 | ||
111 | EXPERIMENTAL_BRIGHTMAIL=yes | |
47bbda99 | 112 | CFLAGS=-I/path/to/the/dir/with/the/includefile |
ee161e8f | 113 | EXTRALIBS_EXIM=-L/path/to/the/dir/with/the/library -lbmiclient_single |
8ff3788c | 114 | |
ee161e8f PH |
115 | If you use other CFLAGS or EXTRALIBS_EXIM settings then |
116 | merge the content of these lines with them. | |
117 | ||
7c0c8547 | 118 | Note for BMI6.x users: You'll also have to add -lxml2_single |
ee161e8f PH |
119 | to the EXTRALIBS_EXIM line. Users of 5.5x do not need to do |
120 | this. | |
8ff3788c | 121 | |
ee161e8f PH |
122 | You should also include the location of |
123 | libbmiclient_single.so in your dynamic linker configuration | |
124 | file (usually /etc/ld.so.conf) and run "ldconfig" | |
125 | afterwards, or else the produced Exim binary will not be | |
126 | able to find the library file. | |
127 | ||
128 | ||
3ec3e3bb | 129 | 2) Setting up BMI support in the Exim main configuration |
ee161e8f | 130 | |
3ec3e3bb | 131 | To enable BMI support in the main Exim configuration, you |
ee161e8f PH |
132 | should set the path to the main BMI configuration file with |
133 | the "bmi_config_file" option, like this: | |
8ff3788c | 134 | |
ee161e8f | 135 | bmi_config_file = /opt/brightmail/etc/brightmail.cfg |
8ff3788c | 136 | |
3ec3e3bb | 137 | This must go into section 1 of Exim's configuration file (You |
ee161e8f PH |
138 | can put it right on top). If you omit this option, it |
139 | defaults to /opt/brightmail/etc/brightmail.cfg. | |
140 | ||
141 | Note for BMI6.x users: This file is in XML format in V6.xx | |
142 | and its name is /opt/brightmail/etc/bmiconfig.xml. So BMI | |
143 | 6.x users MUST set the bmi_config_file option. | |
8ff3788c | 144 | |
ee161e8f PH |
145 | |
146 | 3) Set up ACL control statement | |
147 | ||
148 | To optimize performance, it makes sense only to process | |
149 | messages coming from remote, untrusted sources with the BMI | |
150 | server. To set up a messages for processing by the BMI | |
151 | server, you MUST set the "bmi_run" control statement in any | |
152 | ACL for an incoming message. You will typically do this in | |
153 | an "accept" block in the "acl_check_rcpt" ACL. You should | |
154 | use the "accept" block(s) that accept messages from remote | |
155 | servers for your own domain(s). Here is an example that uses | |
3ec3e3bb | 156 | the "accept" blocks from Exim's default configuration file: |
8ff3788c | 157 | |
ee161e8f PH |
158 | |
159 | accept domains = +local_domains | |
160 | endpass | |
161 | verify = recipient | |
162 | control = bmi_run | |
163 | ||
164 | accept domains = +relay_to_domains | |
165 | endpass | |
166 | verify = recipient | |
167 | control = bmi_run | |
8ff3788c | 168 | |
ee161e8f PH |
169 | If bmi_run is not set in any ACL during reception of the |
170 | message, it will NOT be passed to the BMI server. | |
171 | ||
172 | ||
173 | 4) Setting up routers to use BMI verdicts | |
174 | ||
175 | When a message has been run through the BMI server, one or | |
176 | more "verdicts" are present. Different recipients can have | |
177 | different verdicts. Each recipient is treated individually | |
178 | during routing, so you can query the verdicts by recipient | |
3ec3e3bb | 179 | at that stage. From Exim's view, a verdict can have the |
ee161e8f | 180 | following outcomes: |
8ff3788c | 181 | |
ee161e8f PH |
182 | o deliver the message normally |
183 | o deliver the message to an alternate location | |
184 | o do not deliver the message | |
8ff3788c | 185 | |
ee161e8f PH |
186 | To query the verdict for a recipient, the implementation |
187 | offers the following tools: | |
8ff3788c TK |
188 | |
189 | ||
ee161e8f PH |
190 | - Boolean router preconditions. These can be used in any |
191 | router. For a simple implementation of BMI, these may be | |
192 | all that you need. The following preconditions are | |
193 | available: | |
8ff3788c | 194 | |
ee161e8f | 195 | o bmi_deliver_default |
8ff3788c | 196 | |
ee161e8f PH |
197 | This precondition is TRUE if the verdict for the |
198 | recipient is to deliver the message normally. If the | |
199 | message has not been processed by the BMI server, this | |
200 | variable defaults to TRUE. | |
8ff3788c | 201 | |
ee161e8f | 202 | o bmi_deliver_alternate |
8ff3788c | 203 | |
ee161e8f PH |
204 | This precondition is TRUE if the verdict for the |
205 | recipient is to deliver the message to an alternate | |
206 | location. You can get the location string from the | |
207 | $bmi_alt_location expansion variable if you need it. See | |
208 | further below. If the message has not been processed by | |
209 | the BMI server, this variable defaults to FALSE. | |
8ff3788c | 210 | |
ee161e8f | 211 | o bmi_dont_deliver |
8ff3788c | 212 | |
ee161e8f PH |
213 | This precondition is TRUE if the verdict for the |
214 | recipient is NOT to deliver the message to the | |
215 | recipient. You will typically use this precondition in a | |
216 | top-level blackhole router, like this: | |
8ff3788c | 217 | |
ee161e8f PH |
218 | # don't deliver messages handled by the BMI server |
219 | bmi_blackhole: | |
220 | driver = redirect | |
221 | bmi_dont_deliver | |
222 | data = :blackhole: | |
8ff3788c | 223 | |
ee161e8f PH |
224 | This router should be on top of all others, so messages |
225 | that should not be delivered do not reach other routers | |
226 | at all. If the message has not been processed by | |
227 | the BMI server, this variable defaults to FALSE. | |
8ff3788c TK |
228 | |
229 | ||
ee161e8f PH |
230 | - A list router precondition to query if rules "fired" on |
231 | the message for the recipient. Its name is "bmi_rule". You | |
232 | use it by passing it a colon-separated list of rule | |
233 | numbers. You can use this condition to route messages that | |
234 | matched specific rules. Here is an example: | |
8ff3788c | 235 | |
ee161e8f PH |
236 | # special router for BMI rule #5, #8 and #11 |
237 | bmi_rule_redirect: | |
238 | driver = redirect | |
239 | bmi_rule = 5:8:11 | |
240 | data = postmaster@mydomain.com | |
8ff3788c TK |
241 | |
242 | ||
ee161e8f PH |
243 | - Expansion variables. Several expansion variables are set |
244 | during routing. You can use them in custom router | |
245 | conditions, for example. The following variables are | |
246 | available: | |
8ff3788c | 247 | |
ee161e8f | 248 | o $bmi_base64_verdict |
8ff3788c | 249 | |
ee161e8f PH |
250 | This variable will contain the BASE64 encoded verdict |
251 | for the recipient being routed. You can use it to add a | |
252 | header to messages for tracking purposes, for example: | |
8ff3788c | 253 | |
ee161e8f PH |
254 | localuser: |
255 | driver = accept | |
256 | check_local_user | |
257 | headers_add = X-Brightmail-Verdict: $bmi_base64_verdict | |
258 | transport = local_delivery | |
8ff3788c | 259 | |
ee161e8f PH |
260 | If there is no verdict available for the recipient being |
261 | routed, this variable contains the empty string. | |
8ff3788c | 262 | |
ee161e8f | 263 | o $bmi_base64_tracker_verdict |
8ff3788c | 264 | |
ee161e8f PH |
265 | This variable will contain a BASE64 encoded subset of |
266 | the verdict information concerning the "rules" that | |
267 | fired on the message. You can add this string to a | |
268 | header, commonly named "X-Brightmail-Tracker". Example: | |
8ff3788c | 269 | |
ee161e8f PH |
270 | localuser: |
271 | driver = accept | |
272 | check_local_user | |
273 | headers_add = X-Brightmail-Tracker: $bmi_base64_tracker_verdict | |
274 | transport = local_delivery | |
8ff3788c | 275 | |
ee161e8f PH |
276 | If there is no verdict available for the recipient being |
277 | routed, this variable contains the empty string. | |
8ff3788c | 278 | |
ee161e8f | 279 | o $bmi_alt_location |
8ff3788c | 280 | |
ee161e8f PH |
281 | If the verdict is to redirect the message to an |
282 | alternate location, this variable will contain the | |
283 | alternate location string returned by the BMI server. In | |
284 | its default configuration, this is a header-like string | |
285 | that can be added to the message with "headers_add". If | |
286 | there is no verdict available for the recipient being | |
287 | routed, or if the message is to be delivered normally, | |
288 | this variable contains the empty string. | |
8ff3788c | 289 | |
ee161e8f | 290 | o $bmi_deliver |
8ff3788c | 291 | |
ee161e8f PH |
292 | This is an additional integer variable that can be used |
293 | to query if the message should be delivered at all. You | |
294 | should use router preconditions instead if possible. | |
8ff3788c | 295 | |
ee161e8f PH |
296 | $bmi_deliver is '0': the message should NOT be delivered. |
297 | $bmi_deliver is '1': the message should be delivered. | |
8ff3788c TK |
298 | |
299 | ||
ee161e8f PH |
300 | IMPORTANT NOTE: Verdict inheritance. |
301 | The message is passed to the BMI server during message | |
302 | reception, using the target addresses from the RCPT TO: | |
303 | commands in the SMTP transaction. If recipients get expanded | |
304 | or re-written (for example by aliasing), the new address(es) | |
305 | inherit the verdict from the original address. This means | |
306 | that verdicts also apply to all "child" addresses generated | |
307 | from top-level addresses that were sent to the BMI server. | |
8ff3788c TK |
308 | |
309 | ||
ee161e8f PH |
310 | 5) Using per-recipient opt-in information (Optional) |
311 | ||
312 | The BMI server features multiple scanning "profiles" for | |
313 | individual recipients. These are usually stored in a LDAP | |
314 | server and are queried by the BMI server itself. However, | |
315 | you can also pass opt-in data for each recipient from the | |
316 | MTA to the BMI server. This is particularly useful if you | |
3ec3e3bb | 317 | already look up recipient data in Exim anyway (which can |
ee161e8f PH |
318 | also be stored in a SQL database or other source). This |
319 | implementation enables you to pass opt-in data to the BMI | |
320 | server in the RCPT ACL. This works by setting the | |
321 | 'bmi_optin' modifier in a block of that ACL. If should be | |
322 | set to a list of comma-separated strings that identify the | |
323 | features which the BMI server should use for that particular | |
324 | recipient. Ideally, you would use the 'bmi_optin' modifier | |
325 | in the same ACL block where you set the 'bmi_run' control | |
326 | flag. Here is an example that will pull opt-in data for each | |
327 | recipient from a flat file called | |
328 | '/etc/exim/bmi_optin_data'. | |
8ff3788c | 329 | |
ee161e8f | 330 | The file format: |
8ff3788c | 331 | |
ee161e8f PH |
332 | user1@mydomain.com: <OPTIN STRING1>:<OPTIN STRING2> |
333 | user2@thatdomain.com: <OPTIN STRING3> | |
8ff3788c TK |
334 | |
335 | ||
ee161e8f | 336 | The example: |
8ff3788c | 337 | |
ee161e8f PH |
338 | accept domains = +relay_to_domains |
339 | endpass | |
340 | verify = recipient | |
341 | bmi_optin = ${lookup{$local_part@$domain}lsearch{/etc/exim/bmi_optin_data}} | |
8ff3788c TK |
342 | control = bmi_run |
343 | ||
ee161e8f | 344 | Of course, you can also use any other lookup method that |
3ec3e3bb | 345 | Exim supports, including LDAP, Postgres, MySQL, Oracle etc., |
ee161e8f PH |
346 | as long as the result is a list of colon-separated opt-in |
347 | strings. | |
8ff3788c | 348 | |
ee161e8f PH |
349 | For a list of available opt-in strings, please contact your |
350 | Brightmail representative. | |
ee161e8f | 351 | |
8ff3788c TK |
352 | |
353 | ||
354 | ||
0b23848a | 355 | Sender Policy Framework (SPF) support |
ee161e8f PH |
356 | -------------------------------------------------------------- |
357 | ||
f413481d | 358 | To learn more about SPF, visit http://www.openspf.org. This |
ee161e8f PH |
359 | document does not explain the SPF fundamentals, you should |
360 | read and understand the implications of deploying SPF on your | |
361 | system before doing so. | |
362 | ||
8ff3788c | 363 | SPF support is added via the libspf2 library. Visit |
ee161e8f PH |
364 | |
365 | http://www.libspf2.org/ | |
8ff3788c | 366 | |
ee161e8f PH |
367 | to obtain a copy, then compile and install it. By default, |
368 | this will put headers in /usr/local/include and the static | |
369 | library in /usr/local/lib. | |
370 | ||
3ec3e3bb | 371 | To compile Exim with SPF support, set these additional flags in |
ee161e8f PH |
372 | Local/Makefile: |
373 | ||
374 | EXPERIMENTAL_SPF=yes | |
375 | CFLAGS=-DSPF -I/usr/local/include | |
376 | EXTRALIBS_EXIM=-L/usr/local/lib -lspf2 | |
377 | ||
378 | This assumes that the libspf2 files are installed in | |
379 | their default locations. | |
380 | ||
381 | You can now run SPF checks in incoming SMTP by using the "spf" | |
382 | ACL condition in either the MAIL, RCPT or DATA ACLs. When | |
383 | using it in the RCPT ACL, you can make the checks dependend on | |
384 | the RCPT address (or domain), so you can check SPF records | |
385 | only for certain target domains. This gives you the | |
386 | possibility to opt-out certain customers that do not want | |
387 | their mail to be subject to SPF checking. | |
388 | ||
389 | The spf condition takes a list of strings on its right-hand | |
390 | side. These strings describe the outcome of the SPF check for | |
391 | which the spf condition should succeed. Valid strings are: | |
392 | ||
393 | o pass The SPF check passed, the sending host | |
394 | is positively verified by SPF. | |
395 | o fail The SPF check failed, the sending host | |
396 | is NOT allowed to send mail for the domain | |
397 | in the envelope-from address. | |
398 | o softfail The SPF check failed, but the queried | |
399 | domain can't absolutely confirm that this | |
400 | is a forgery. | |
401 | o none The queried domain does not publish SPF | |
402 | records. | |
403 | o neutral The SPF check returned a "neutral" state. | |
404 | This means the queried domain has published | |
405 | a SPF record, but wants to allow outside | |
406 | servers to send mail under its domain as well. | |
407 | o err_perm This indicates a syntax error in the SPF | |
408 | record of the queried domain. This should be | |
409 | treated like "none". | |
410 | o err_temp This indicates a temporary error during all | |
3ec3e3bb | 411 | processing, including Exim's SPF processing. |
ee161e8f | 412 | You may defer messages when this occurs. |
8ff3788c | 413 | |
ee161e8f PH |
414 | You can prefix each string with an exclamation mark to invert |
415 | is meaning, for example "!fail" will match all results but | |
416 | "fail". The string list is evaluated left-to-right, in a | |
417 | short-circuit fashion. When a string matches the outcome of | |
418 | the SPF check, the condition succeeds. If none of the listed | |
419 | strings matches the outcome of the SPF check, the condition | |
420 | fails. | |
421 | ||
f413481d TK |
422 | Here is an example to fail forgery attempts from domains that |
423 | publish SPF records: | |
ee161e8f PH |
424 | |
425 | /* ----------------- | |
f413481d TK |
426 | deny message = $sender_host_address is not allowed to send mail from ${if def:sender_address_domain {$sender_address_domain}{$sender_helo_name}}. \ |
427 | Please see http://www.openspf.org/Why?scope=${if def:sender_address_domain {mfrom}{helo}};identity=${if def:sender_address_domain {$sender_address}{$sender_helo_name}};ip=$sender_host_address | |
ee161e8f PH |
428 | spf = fail |
429 | --------------------- */ | |
430 | ||
431 | You can also give special treatment to specific domains: | |
432 | ||
433 | /* ----------------- | |
434 | deny message = AOL sender, but not from AOL-approved relay. | |
435 | sender_domains = aol.com | |
436 | spf = fail:neutral | |
437 | --------------------- */ | |
438 | ||
439 | Explanation: AOL publishes SPF records, but is liberal and | |
440 | still allows non-approved relays to send mail from aol.com. | |
441 | This will result in a "neutral" state, while mail from genuine | |
442 | AOL servers will result in "pass". The example above takes | |
443 | this into account and treats "neutral" like "fail", but only | |
444 | for aol.com. Please note that this violates the SPF draft. | |
445 | ||
446 | When the spf condition has run, it sets up several expansion | |
447 | variables. | |
448 | ||
449 | $spf_header_comment | |
450 | This contains a human-readable string describing the outcome | |
451 | of the SPF check. You can add it to a custom header or use | |
452 | it for logging purposes. | |
8ff3788c | 453 | |
ee161e8f | 454 | $spf_received |
8fe685ad | 455 | This contains a complete Received-SPF: header that can be |
ee161e8f PH |
456 | added to the message. Please note that according to the SPF |
457 | draft, this header must be added at the top of the header | |
458 | list. Please see section 10 on how you can do this. | |
8ff3788c | 459 | |
65a7d8c3 NM |
460 | Note: in case of "Best-guess" (see below), the convention is |
461 | to put this string in a header called X-SPF-Guess: instead. | |
462 | ||
ee161e8f PH |
463 | $spf_result |
464 | This contains the outcome of the SPF check in string form, | |
465 | one of pass, fail, softfail, none, neutral, err_perm or | |
466 | err_temp. | |
8ff3788c | 467 | |
ee161e8f PH |
468 | $spf_smtp_comment |
469 | This contains a string that can be used in a SMTP response | |
470 | to the calling party. Useful for "fail". | |
8ff3788c | 471 | |
65a7d8c3 NM |
472 | In addition to SPF, you can also perform checks for so-called |
473 | "Best-guess". Strictly speaking, "Best-guess" is not standard | |
474 | SPF, but it is supported by the same framework that enables SPF | |
475 | capability. Refer to http://www.openspf.org/FAQ/Best_guess_record | |
476 | for a description of what it means. | |
477 | ||
478 | To access this feature, simply use the spf_guess condition in place | |
479 | of the spf one. For example: | |
480 | ||
481 | /* ----------------- | |
482 | deny message = $sender_host_address doesn't look trustworthy to me | |
483 | spf_guess = fail | |
484 | --------------------- */ | |
485 | ||
486 | In case you decide to reject messages based on this check, you | |
487 | should note that although it uses the same framework, "Best-guess" | |
488 | is NOT SPF, and therefore you should not mention SPF at all in your | |
489 | reject message. | |
490 | ||
491 | When the spf_guess condition has run, it sets up the same expansion | |
492 | variables as when spf condition is run, described above. | |
493 | ||
494 | Additionally, since Best-guess is not standarized, you may redefine | |
495 | what "Best-guess" means to you by redefining spf_guess variable in | |
496 | global config. For example, the following: | |
497 | ||
498 | /* ----------------- | |
499 | spf_guess = v=spf1 a/16 mx/16 ptr ?all | |
500 | --------------------- */ | |
501 | ||
502 | would relax host matching rules to a broader network range. | |
8ff3788c | 503 | |
ee161e8f | 504 | |
0b23848a | 505 | SRS (Sender Rewriting Scheme) Support |
ee161e8f PH |
506 | -------------------------------------------------------------- |
507 | ||
508 | Exiscan currently includes SRS support via Miles Wilton's | |
8ff3788c | 509 | libsrs_alt library. The current version of the supported |
ee161e8f PH |
510 | library is 0.5. |
511 | ||
512 | In order to use SRS, you must get a copy of libsrs_alt from | |
513 | ||
514 | http://srs.mirtol.com/ | |
515 | ||
516 | Unpack the tarball, then refer to MTAs/README.EXIM | |
517 | to proceed. You need to set | |
518 | ||
519 | EXPERIMENTAL_SRS=yes | |
520 | ||
521 | in your Local/Makefile. | |
522 | ||
523 | ||
0e1ccf44 PP |
524 | DCC Support |
525 | -------------------------------------------------------------- | |
526 | ||
527 | *) Building exim | |
528 | ||
529 | In order to build exim with DCC support add | |
530 | ||
531 | EXPERIMENTAL_DCC=yes | |
532 | ||
533 | to your Makefile. (Re-)build/install exim. exim -d should show | |
534 | EXPERIMENTAL_DCC under "Support for". | |
535 | ||
536 | ||
537 | *) Configuration | |
538 | ||
539 | In the main section of exim.cf add at least | |
540 | dccifd_address = /usr/local/dcc/var/dccifd | |
541 | or | |
542 | dccifd_address = <ip> <port> | |
543 | ||
544 | In the DATA ACL you can use the new condition | |
545 | dcc = * | |
546 | ||
547 | After that "$dcc_header" contains the X-DCC-Header. | |
548 | ||
549 | Returnvalues are: | |
550 | fail for overall "R", "G" from dccifd | |
551 | defer for overall "T" from dccifd | |
552 | accept for overall "A", "S" from dccifd | |
553 | ||
554 | dcc = */defer_ok works as for spamd. | |
555 | ||
556 | The "$dcc_result" variable contains the overall result from DCC | |
557 | answer. There will an X-DCC: header added to the mail. | |
558 | ||
559 | Usually you'll use | |
560 | defer !dcc = * | |
561 | to greylist with DCC. | |
562 | ||
563 | If you set, in the main section, | |
564 | dcc_direct_add_header = true | |
565 | then the dcc header will be added "in deep" and if the spool | |
566 | file was already written it gets removed. This forces Exim to | |
567 | write it again if needed. This helps to get the DCC Header | |
568 | through to eg. SpamAssassin. | |
569 | ||
570 | If you want to pass even more headers in the middle of the | |
571 | DATA stage you can set | |
572 | $acl_m_dcc_add_header | |
573 | to tell the DCC routines add more information; eg, you might set | |
574 | this to some results from ClamAV. Be careful. Header syntax is | |
575 | not checked and is added "as is". | |
576 | ||
577 | ||
ee161e8f PH |
578 | -------------------------------------------------------------- |
579 | End of file | |
580 | -------------------------------------------------------------- |