X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/3634fc257bd0667daef14d72005cd87c735bbb24..005ac57fce967bf7c31e29cd63199297fcda05df:/doc/doc-txt/experimental-spec.txt?ds=sidebyside diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index 1d290c26b..5dd6832b1 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -6,6 +6,66 @@ about experimenatal features, all of which are unstable and liable to incompatibile change. +OCSP Stapling support +-------------------------------------------------------------- + +X509 PKI certificates expire and can be revoked; to handle this, the +clients need some way to determine if a particular certificate, from a +particular Certificate Authority (CA), is still valid. There are three +main ways to do so. + +The simplest way is to serve up a Certificate Revocation List (CRL) with +an ordinary web-server, regenerating the CRL before it expires. The +downside is that clients have to periodically re-download a potentially +huge file from every certificate authority it knows of. + +The way with most moving parts at query time is Online Certificate +Status Protocol (OCSP), where the client verifies the certificate +against an OCSP server run by the CA. This lets the CA track all +usage of the certs. This requires running software with access to the +private key of the CA, to sign the responses to the OCSP queries. OCSP +is based on HTTP and can be proxied accordingly. + +The only widespread OCSP server implementation (known to this writer) +comes as part of OpenSSL and aborts on an invalid request, such as +connecting to the port and then disconnecting. This requires +re-entering the passphrase each time some random client does this. + +The third way is OCSP Stapling; in this, the server using a certificate +issued by the CA periodically requests an OCSP proof of validity from +the OCSP server, then serves it up inline as part of the TLS +negotiation. This approach adds no extra round trips, does not let the +CA track users, scales well with number of certs issued by the CA and is +resilient to temporary OCSP server failures, as long as the server +starts retrying to fetch an OCSP proof some time before its current +proof expires. The downside is that it requires server support. + +If Exim is built with EXPERIMENTAL_OCSP and it was built with OpenSSL, +then it gains one new option: "tls_ocsp_file". + +The file specified therein is expected to be in DER format, and contain +an OCSP proof. Exim will serve it as part of the TLS handshake. This +option will be re-expanded for SNI, if the tls_certificate option +contains $tls_sni, as per other TLS options. + +Exim does not at this time implement any support for fetching a new OCSP +proof. The burden is on the administrator to handle this, outside of +Exim. The file specified should be replaced atomically, so that the +contents are always valid. Exim will expand the "tls_ocsp_file" option +on each connection, so a new file will be handled transparently on the +next connection. + +Exim will check for a valid next update timestamp in the OCSP proof; +if not present, or if the proof has expired, it will be ignored. + +At this point in time, we're gathering feedback on use, to determine if +it's worth adding complexity to the Exim daemon to periodically re-fetch +OCSP files and somehow handling multiple files. There is no client support +for OCSP in Exim, this is feature expected to be used by mail clients. + + + + Brightmail AntiSpam (BMI) suppport -------------------------------------------------------------- @@ -461,6 +521,60 @@ EXPERIMENTAL_SRS=yes in your Local/Makefile. +DCC Support +-------------------------------------------------------------- + +*) Building exim + +In order to build exim with DCC support add + +EXPERIMENTAL_DCC=yes + +to your Makefile. (Re-)build/install exim. exim -d should show +EXPERIMENTAL_DCC under "Support for". + + +*) Configuration + +In the main section of exim.cf add at least + dccifd_address = /usr/local/dcc/var/dccifd +or + dccifd_address = + +In the DATA ACL you can use the new condition + dcc = * + +After that "$dcc_header" contains the X-DCC-Header. + +Returnvalues are: + fail for overall "R", "G" from dccifd + defer for overall "T" from dccifd + accept for overall "A", "S" from dccifd + +dcc = */defer_ok works as for spamd. + +The "$dcc_result" variable contains the overall result from DCC +answer. There will an X-DCC: header added to the mail. + +Usually you'll use + defer !dcc = * +to greylist with DCC. + +If you set, in the main section, + dcc_direct_add_header = true +then the dcc header will be added "in deep" and if the spool +file was already written it gets removed. This forces Exim to +write it again if needed. This helps to get the DCC Header +through to eg. SpamAssassin. + +If you want to pass even more headers in the middle of the +DATA stage you can set + $acl_m_dcc_add_header +to tell the DCC routines add more information; eg, you might set +this to some results from ClamAV. Be careful. Header syntax is +not checked and is added "as is". + + -------------------------------------------------------------- End of file --------------------------------------------------------------