TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto
TLS_INCLUDE=-I/usr/local/openssl/include/
.endd
+.new
+.cindex "pkg-config" "OpenSSL"
+If you have &'pkg-config'& available, then instead you can just use:
+.code
+SUPPORT_TLS=yes
+USE_OPENSSL_PC=openssl
+.endd
+.wen
.cindex "USE_GNUTLS"
If GnuTLS is installed, you should set
.code
TLS_LIBS=-L/usr/gnu/lib -lgnutls -ltasn1 -lgcrypt
TLS_INCLUDE=-I/usr/gnu/include
.endd
+.new
+.cindex "pkg-config" "GnuTLS"
+If you have &'pkg-config'& available, then instead you can just use:
+.code
+SUPPORT_TLS=yes
+USE_GNUTLS=yes
+USE_GNUTLS_PC=gnutls
+.endd
+.wen
+
You do not need to set TLS_INCLUDE if the relevant directory is already
specified in INCLUDE. Details of how to configure Exim to make use of TLS are
given in chapter &<<CHAPTLS>>&.
binary, attempts to configure Exim to use it cause run time configuration
errors.
+.new
+.cindex "pkg-config" "lookups"
+.cindex "pkg-config" "authenticators"
+Many systems now use a tool called &'pkg-config'& to encapsulate information
+about how to compile against a library; Exim has some initial support for
+being able to use pkg-config for lookups and authenticators. For any given
+makefile variable which starts &`LOOKUP_`& or &`AUTH_`&, you can add a new
+variable with the &`_PC`& suffix in the name and assign as the value the
+name of the package to be queried. The results of querying via the
+&'pkg-config'& command will be added to the appropriate Makefile variables
+with &`+=`& directives, so your version of &'make'& will need to support that
+syntax. For instance:
+.code
+LOOKUP_SQLITE=yes
+LOOKUP_SQLITE_PC=sqlite3
+AUTH_GSASL=yes
+AUTH_GSASL_PC=libgsasl
+AUTH_HEIMDAL_GSSAPI=yes
+AUTH_HEIMDAL_GSSAPI_PC=heimdal-gssapi
+.endd
+.wen
+
.cindex "Perl" "including support for"
Exim can be linked with an embedded Perl interpreter, allowing Perl
subroutines to be called during string expansion. To enable this facility,
the DB_UNKNOWN option. This enables it to handle any of the types of database
that the library supports, and can be useful for accessing DBM files created by
other applications. (For earlier DB versions, DB_HASH is always used.)
+.new
+.next
+.cindex "lookup" "dbmjz"
+.cindex "lookup" "dbm &-- embedded NULs"
+.cindex "sasldb2"
+.cindex "dbmjz lookup type"
+&(dbmjz)&: This is the same as &(dbm)&, except that the lookup key is
+interpreted as an Exim list; the elements of the list are joined together with
+ASCII NUL characters to form the lookup key. An example usage would be to
+authenticate incoming SMTP calls using the passwords from Cyrus SASL's
+&_/etc/sasldb2_& file with the &(gsasl)& authenticator or Exim's own
+&(cram_md5)& authenticator.
+.wen
.next
.cindex "lookup" "dbmnz"
.cindex "lookup" "dbm &-- terminating zero"
.cindex "binary zero" "in lookup key"
.cindex "Courier"
.cindex "&_/etc/userdbshadow.dat_&"
-.cindex "dmbnz lookup type"
+.cindex "dbmnz lookup type"
&(dbmnz)&: This is the same as &(dbm)&, except that a terminating binary zero
is not included in the key that is passed to the DBM library. You may need this
if you want to look up data in files that are created by or shared with some
command, which can be found in the separate document entitled &'Exim's
interfaces to mail filtering'&.
+.new
+.vitem &$tls_bits$&
+.vindex "&$tls_bits$&"
+Contains an approximation of the TLS cipher's bit-strength; the meaning of
+this depends upon the TLS implementation used.
+If TLS has not been negotiated, the value will be 0.
+The value of this is automatically fed into the Cyrus SASL authenticator
+when acting as a server, to specify the "external SSF" (a SASL term).
+.wen
+
.vitem &$tls_certificate_verified$&
.vindex "&$tls_certificate_verified$&"
This variable is set to &"1"& if a TLS certificate was verified when the
Note that this expansion explicitly forces failure if the lookup fails
because &$auth1$& contains an unknown user name.
+.new
+As another example, if you wish to re-use a Cyrus SASL sasldb2 file without
+using the relevant libraries, you need to know the realm to specify in the
+lookup and then ask for the &"userPassword"& attribute for that user in that
+realm, with:
+.code
+cyrusless_crammd5:
+ driver = cram_md5
+ public_name = CRAM-MD5
+ server_secret = ${lookup{$auth1:mail.example.org:userPassword}\
+ dbmjz{/etc/sasldb2}}
+ server_set_id = $auth1
+.endd
+.wen
.section "Using cram_md5 as a client" "SECID177"
.cindex "options" "&(cram_md5)& authenticator (client)"
server_set_id = $auth1
.endd
-.option server_realm cyrus_sasl string unset
+.new
+.option server_realm cyrus_sasl string&!! unset
This specifies the SASL realm that the server claims to be in.
+.wen
.option server_service cyrus_sasl string &`smtp`&
the &%server_condition%& option must be present.
.next
.cindex "authentication" "GSSAPI"
-GSSAPI: &$auth1$& will be set to the &'authorization id'&,
-&$auth2$& will be set to the &'GSSAPI Display Name'&;
+GSSAPI: &$auth1$& will be set to the &'GSSAPI Display Name'&;
+&$auth2$& will be set to the &'authorization id'&,
the &%server_condition%& option must be present.
.endlist
identifier; this is analogous to FTP anonymous authentication passing an
email address, or software-identifier@, as the "password".
+
+An example showing the password having the realm specified in the callback
+and demonstrating a Cyrus SASL to GSASL migration approach is:
+.code
+gsasl_cyrusless_crammd5:
+ driver = gsasl
+ public_name = CRAM-MD5
+ server_realm = imap.example.org
+ server_password = ${lookup{$auth1:$auth3:userPassword}\
+ dbmjz{/etc/sasldb2}{$value}fail}
+ server_set_id = ${quote:$auth1}
+ server_condition = yes
+.endd
+
.wen
. ////////////////////////////////////////////////////////////////////////////
.next
.vindex "&$auth2$&"
&$auth2$&: the &'authorization id'&, sent within SASL encapsulation after
-authentication.
+authentication. If that was empty, this will also be set to the
+GSS Display Name.
.endlist
.wen
git://git.exim.org / users / heiko / exim.git / blobdiff