DKIM: fix non-debug build. Bug 1713
[exim.git] / doc / doc-txt / experimental-spec.txt
index c060a6c5a99856e2b7c77b9ccbbc767eaaced660..c93123c39f9df588872b97127bf789f076dce22a 100644 (file)
@@ -448,6 +448,17 @@ spf_guess = v=spf1 a/16 mx/16 ptr ?all
 would relax host matching rules to a broader network range.
 
 
 would relax host matching rules to a broader network range.
 
 
+A lookup expansion is also available. It takes an email
+address as the key and an IP address as the database:
+
+  $lookup (username@domain} spf {ip.ip.ip.ip}}
+
+The lookup will return the same result strings as they can appear in
+$spf_result (pass,fail,softfail,neutral,none,err_perm,err_temp).
+Currently, only IPv4 addresses are supported.
+
+
+
 SRS (Sender Rewriting Scheme) Support
 --------------------------------------------------------------
 
 SRS (Sender Rewriting Scheme) Support
 --------------------------------------------------------------
 
@@ -469,6 +480,7 @@ in your Local/Makefile.
 
 DCC Support
 --------------------------------------------------------------
 
 DCC Support
 --------------------------------------------------------------
+Distributed Checksum Clearinghouse; http://www.rhyolite.com/dcc/
 
 *) Building exim
 
 
 *) Building exim
 
@@ -623,10 +635,10 @@ exim will send these forensic emails.  It's also advised that you
 configure a dmarc_forensic_sender because the default sender address
 construction might be inadequate.
 
 configure a dmarc_forensic_sender because the default sender address
 construction might be inadequate.
 
-  control = dmarc_forensic_enable
+  control = dmarc_enable_forensic
 
 (AGAIN: You can choose not to send these forensic reports by simply
 
 (AGAIN: You can choose not to send these forensic reports by simply
-not putting the dmarc_forensic_enable control line at any point in
+not putting the dmarc_enable_forensic control line at any point in
 your exim config.  If you don't tell it to send them, it will not
 send them.)
 
 your exim config.  If you don't tell it to send them, it will not
 send them.)
 
@@ -755,94 +767,109 @@ b. Configure, somewhere before the DATA ACL, the control option to
 
   deny    dmarc_status   = reject
           !authenticated = *
 
   deny    dmarc_status   = reject
           !authenticated = *
-          message        = Message from $domain_used_domain failed sender's DMARC policy, REJECT
+          message        = Message from $dmarc_used_domain failed sender's DMARC policy, REJECT
 
 
 
 
 
 
-Transport post-delivery actions
+Event Actions
 --------------------------------------------------------------
 
 --------------------------------------------------------------
 
-An arbitrary per-transport string can be expanded on successful delivery,
-and (for SMTP transports) a second string on deferrals caused by a host error.
+(Renamed from TPDA, Transport post-delivery actions)
+
+An arbitrary per-transport string can be expanded upon various transport events.
+Additionally a main-section configuration option can be expanded on some
+per-message events.
 This feature may be used, for example, to write exim internal log information
 (not available otherwise) into a database.
 
 This feature may be used, for example, to write exim internal log information
 (not available otherwise) into a database.
 
-In order to use the feature, you must set
+In order to use the feature, you must compile with
 
 
-EXPERIMENTAL_TPDA=yes
+EXPERIMENTAL_EVENT=yes
 
 in your Local/Makefile
 
 
 in your Local/Makefile
 
-and define the expandable strings in the runtime config file, to
-be executed at end of delivery.
+and define one or both of
+- the event_action option in the transport
+- the event_action main option
+to be expanded when the event fires.
+
+A new variable, $event_name, is set to the event type when the
+expansion is done.  The current list of events is:
+
+ msg:complete          after  main       per message
+ msg:delivery          after  transport  per recipient
+ msg:host:defer                after  transport  per attempt
+ msg:fail:delivery     after  main       per recipient
+ msg:fail:internal     after  main       per recipient
+ tcp:connect           before transport  per connection
+ tcp:close             after  transport  per connection
+ tls:cert              before both       per certificate in verification chain
+ smtp:connect          after  transport  per connection
+
+The expansion is called for all event types, and should use the $event_name
+variable to decide when to act.  The value of the variable is a colon-separated
+list, defining a position in the tree of possible events; it may be used as
+a list or just matched on as a whole.  There will be no whitespace.
 
 
-Additionally, there are 6 more variables, available at end of
-delivery:
 
 
-tpda_delivery_ip             IP of host, which has accepted delivery
-tpda_delivery_port           Port of remote host which has accepted delivery
-tpda_delivery_fqdn           FQDN of host, which has accepted delivery
-tpda_delivery_local_part     local part of address being delivered
-tpda_delivery_domain         domain part of address being delivered
-tpda_delivery_confirmation   SMTP confirmation message
+There is an auxilary variable, $event_data, for which the
+content is event_dependent:
 
 
-In case of a deferral caused by a host-error:
-tpda_defer_errno             Error number
-tpda_defer_errstr            Error string possibly containing more details
+       msg:delivery            smtp confirmation mssage
+       msg:host:defer          error string
+       tls:cert                verification chain depth
+       smtp:connect            smtp banner
 
 
-The $router_name and $transport_name variables are also usable.
+The msg:host:defer event populates one extra variable, $event_defer_errno.
 
 
+The following variables are likely to be useful depending on the event type:
 
 
-To take action after successful deliveries, set the following option
-on any transport of interest.
+       router_name, transport_name
+       local_part, domain
+       host, host_address, host_port
+       tls_out_peercert
+       lookup_dnssec_authenticated, tls_out_dane
+       sending_ip_address, sending_port
+       message_exim_id, verify_mode
 
 
-tpda_delivery_action
 
 An example might look like:
 
 
 An example might look like:
 
-tpda_delivery_action = \
-${lookup pgsql {SELECT * FROM record_Delivery( \
+event_action = ${if eq {msg:delivery}{$event_name} \
+{${lookup pgsql {SELECT * FROM record_Delivery( \
     '${quote_pgsql:$sender_address_domain}',\
     '${quote_pgsql:${lc:$sender_address_local_part}}', \
     '${quote_pgsql:$sender_address_domain}',\
     '${quote_pgsql:${lc:$sender_address_local_part}}', \
-    '${quote_pgsql:$tpda_delivery_domain}', \
-    '${quote_pgsql:${lc:$tpda_delivery_local_part}}', \
-    '${quote_pgsql:$tpda_delivery_ip}', \
-    '${quote_pgsql:${lc:$tpda_delivery_fqdn}}', \
-    '${quote_pgsql:$message_exim_id}')}}
-
-The string is expanded after the delivery completes and any
-side-effects will happen.  The result is then discarded.
+    '${quote_pgsql:$domain}', \
+    '${quote_pgsql:${lc:$local_part}}', \
+    '${quote_pgsql:$host_address}', \
+    '${quote_pgsql:${lc:$host}}', \
+    '${quote_pgsql:$message_exim_id}')}} \
+} {}}
+
+The string is expanded when each of the supported events occur
+and any side-effects of the expansion will happen.
 Note that for complex operations an ACL expansion can be used.
 
 
 Note that for complex operations an ACL expansion can be used.
 
 
-In order to log host deferrals, add the following option to an SMTP
-transport:
+The expansion of the event_action option should normally
+return an empty string.  Should it return anything else the
+following will be forced:
 
 
-tpda_host_defer_action
+       msg:delivery    (ignored)
+       msg:host:defer  (ignored)
+       msg:fail:delivery (ignored)
+       tcp:connect     do not connect
+       tcp:close       (ignored)
+       tls:cert        refuse verification
+       smtp:connect    close connection
 
 
-This is a private option of the SMTP transport. It is intended to
-log failures of remote hosts. It is executed only when exim has
-attempted to deliver a message to a remote host and failed due to
-an error which doesn't seem to be related to the individual
-message, sender, or recipient address.
-See section 47.2 of the exim documentation for more details on how
-this is determined.
+No other use is made of the result string.
 
 
-Example:
 
 
-tpda_host_defer_action = \
-${lookup mysql {insert into delivlog set \
-    msgid = '${quote_mysql:$message_exim_id}', \
-    senderlp = '${quote_mysql:${lc:$sender_address_local_part}}', \
-    senderdom = '${quote_mysql:$sender_address_domain}', \
-    delivlp = '${quote_mysql:${lc:$tpda_delivery_local_part}}', \
-    delivdom = '${quote_mysql:$tpda_delivery_domain}', \
-    delivip = '${quote_mysql:$tpda_delivery_ip}', \
-    delivport = '${quote_mysql:$tpda_delivery_port}', \
-    delivfqdn = '${quote_mysql:$tpda_delivery_fqdn}', \
-    deliverrno = '${quote_mysql:$tpda_defer_errno}', \
-    deliverrstr = '${quote_mysql:$tpda_defer_errstr}' \
-    }}
+Known issues:
+- the tls:cert event is only called for the cert chain elements
+  received over the wire, with GnuTLS.  OpenSSL gives the entire
+  chain including those loaded locally.
 
 
 Redis Lookup
 
 
 Redis Lookup
@@ -1071,82 +1098,39 @@ QUIT
 221 mail.example.net closing connection
 
 
 221 mail.example.net closing connection
 
 
-DSN Support
---------------------------------------------------------------
-
-DSN Support tries to add RFC 3461 support to Exim. It adds support for
-*) the additional parameters for MAIL FROM and RCPT TO
-*) RFC complient MIME DSN messages for all of
-   success, failure and delay notifications
-*) dsn_advertise_hosts main option to select which hosts are able
-   to use the extension
-*) dsn_lasthop router switch to end DSN processing
-
-In case of failure reports this means that the last three parts, the message body
-intro, size info and final text, of the defined template are ignored since there is no
-logical place to put them in the MIME message.
-
-All the other changes are made without changing any defaults
-
-Building exim:
---------------
-
-Define
-EXPERIMENTAL_DSN=YES
-in your Local/Makefile.
-
-Configuration:
---------------
-All DSNs are sent in MIME format if you built exim with EXPERIMENTAL_DSN=YES
-No option needed to activate it, and no way to turn it off.
-
-Failure and delay DSNs are triggered as usual except a sender used NOTIFY=...
-to prevent them.
-
-Support for Success DSNs is added and activated by NOTIFY=SUCCESS by clients.
-
-Add
-dsn_advertise_hosts = *
-or a more restrictive host_list to announce DSN in EHLO answers
-
-Those hosts can then use NOTIFY,ENVID,RET,ORCPT options.
-
-If a message is relayed to a DSN aware host without changing the envelope
-recipient the options are passed along and no success DSN is generated.
 
 
-A redirect router will always trigger a success DSN if requested and the DSN
-options are not passed any further.
 
 
-A success DSN always contains the recipient address as submitted by the
-client as required by RFC. Rewritten addresses are never exposed.
+SOCKS
+------------------------------------------------------------
+Support for proxying outbound SMTP via a Socks 5 proxy
+(RFC 1928) is included if Exim is compiled with
+EXPERIMENTAL_SOCKS defined.
 
 
-If you used DSN patch up to 1.3 before remove all "dsn_process" switches from
-your routers since you don't need them anymore. There is no way to "gag"
-success DSNs anymore. Announcing DSN means answering as requested.
+If an smtp transport has a nonempty socks_proxy option
+defined, this is active.  The option is expanded and
+should be a list (colon-separated by default) of
+proxy specifiers.  Each proxy specifier is a list
+(space-separated by default) where the initial element
+is an IP address and any subsequent elements are options.
 
 
-You can prevent Exim from passing DSN options along to other DSN aware hosts by defining
-dsn_lasthop
-in a router. Exim will then send the success DSN himself if requested as if
-the next hop does not support DSN.
-Adding it to a redirect router makes no difference.
+Options are a string <name>=<value>.
+These options are currently defined:
+- "auth", with possible values "none" and "name".
+  Using "name" selects username/password authentication
+  per RFC 1929. Default is "none".
+- "name" sets the authentication username. Default is empty.
+- "pass" sets the authentication password. Default is empty.
+- "port" sets the tcp port number for the proxy. Default is 1080.
+- "tmo" sets a connection timeout in seconds for this proxy. Default is 5.
 
 
+Proxies from the list are tried in order until
+one responds.  The timeout for the overall connection
+applies to the set of proxied attempts.
 
 
-Certificate name checking
---------------------------------------------------------------
-The X509 certificates used for TLS are supposed be verified
-that they are owned by the expected host.  The coding of TLS
-support to date has not made these checks.
+If events are used, the remote IP/port during a
+tcp:connect event will be that of the proxy.
 
 
-If built with EXPERIMENTAL_CERTNAMES defined, code is
-included to do so, and a new smtp transport option
-"tls_verify_cert_hostname" supported which takes a list of
-names for which the checks must be made.  The host must
-also be in "tls_verify_hosts".
 
 
-Both Subject and Subject-Alternate-Name certificate fields
-are supported, as are wildcard certificates (limited to
-a single wildcard being the initial component of a 3-or-more
-component FQDN).
 
 
 DANE
 
 
 DANE
@@ -1171,6 +1155,10 @@ admins of the target server.   The attack surface presented
 by (a) is thought to be smaller than that of the set
 of root CAs.
 
 by (a) is thought to be smaller than that of the set
 of root CAs.
 
+It also allows the server to declare (implicitly) that
+connections to it should use TLS.  An MITM could simply
+fail to pass on a server's STARTTLS.
+
 DANE scales better than having to maintain (and
 side-channel communicate) copies of server certificates
 for every possible target server.  It also scales
 DANE scales better than having to maintain (and
 side-channel communicate) copies of server certificates
 for every possible target server.  It also scales
@@ -1195,12 +1183,12 @@ There are no changes to Exim specific to server-side
 operation of DANE.
 
 The TLSA record for the server may have "certificate
 operation of DANE.
 
 The TLSA record for the server may have "certificate
-usage" of DANE_TA(2) or DANE_EE(3).  The latter specifies
+usage" of DANE-TA(2) or DANE-EE(3).  The latter specifies
 the End Entity directly, i.e. the certificate involved
 is that of the server (and should be the sole one transmitted
 during the TLS handshake); this is appropriate for a
 single system, using a self-signed certificate.
 the End Entity directly, i.e. the certificate involved
 is that of the server (and should be the sole one transmitted
 during the TLS handshake); this is appropriate for a
 single system, using a self-signed certificate.
-  DANE_TA usage is effectively declaring a specific CA
+  DANE-TA usage is effectively declaring a specific CA
 to be used; this might be a private CA or a public,
 well-known one.  A private CA at simplest is just
 a self-signed certificate which is used to sign
 to be used; this might be a private CA or a public,
 well-known one.  A private CA at simplest is just
 a self-signed certificate which is used to sign
@@ -1212,7 +1200,7 @@ the entire certificate chain from CA to server-certificate.
 If a public CA is used then all clients must be primed with it
 (losing one advantage of DANE) - but the attack surface is
 reduced from all public CAs to that single CA.
 If a public CA is used then all clients must be primed with it
 (losing one advantage of DANE) - but the attack surface is
 reduced from all public CAs to that single CA.
-DANE_TA is commonly used for several services and/or
+DANE-TA is commonly used for several services and/or
 servers, each having a TLSA query-domain CNAME record,
 all of which point to a single TLSA record.
 
 servers, each having a TLSA query-domain CNAME record,
 all of which point to a single TLSA record.
 
@@ -1229,31 +1217,32 @@ is useful for quickly generating TLSA records; and commands like
 
 are workable for 4th-field hashes.
 
 
 are workable for 4th-field hashes.
 
-For use with the DANE_TA model, server certificates
+For use with the DANE-TA model, server certificates
 must have a correct name (SubjectName or SubjectAltName).
 
 The use of OCSP-stapling should be considered, allowing
 for fast revocation of certificates (which would otherwise
 be limited by the DNS TTL on the TLSA records).  However,
 must have a correct name (SubjectName or SubjectAltName).
 
 The use of OCSP-stapling should be considered, allowing
 for fast revocation of certificates (which would otherwise
 be limited by the DNS TTL on the TLSA records).  However,
-this is likely to only be usable with DANE_TA.  NOTE: the
-default is to request OCSP for all hosts; the certificate
-chain in DANE_EE usage will be insufficient to validate
-the OCSP proof and verification will fail.  Either disable
-OCSP completely or use the (new) variable $tls_out_tlsa_usage
-like so:
-
-  hosts_request_ocsp = ${if or { {= {4}{$tls_out_tlsa_usage}} \
-                                {= {0}{$tls_out_tlsa_usage}} } \
+this is likely to only be usable with DANE-TA.  NOTE: the
+default of requesting OCSP for all hosts is modified iff
+DANE is in use, to:
+
+  hosts_request_ocsp = ${if or { {= {0}{$tls_out_tlsa_usage}} \
+                                {= {4}{$tls_out_tlsa_usage}} } \
                          {*}{}}
                          {*}{}}
-The variable is a bitfield with numbered bits set for TLSA
-record usage codes. The zero above means DANE was not in use,
-the four means that only DANE_TA usage TLSA records were
-found. If the definition of hosts_require_ocsp or
-hosts_request_ocsp includes the string "tls_out_tlsa_usage",
-they are re-expanded in time to control the OCSP request.
 
 
-[ All a bit complicated.  Should we make that definition
-the default?  Should we override the user's definition? ]
+The (new) variable $tls_out_tlsa_usage is a bitfield with
+numbered bits set for TLSA record usage codes.
+The zero above means DANE was not in use,
+the four means that only DANE-TA usage TLSA records were
+found. If the definition of hosts_request_ocsp includes the
+string "tls_out_tlsa_usage", they are re-expanded in time to
+control the OCSP request.
+
+This modification of hosts_request_ocsp is only done if
+it has the default value of "*".  Admins who change it, and
+those who use hosts_require_ocsp, should consider the interaction
+with DANE in their OCSP settings.
 
 
 For client-side DANE there are two new smtp transport options,
 
 
 For client-side DANE there are two new smtp transport options,
@@ -1263,15 +1252,26 @@ hosts_try_dane and hosts_require_dane.  They do the obvious thing.
 DANE will only be usable if the target host has DNSSEC-secured
 MX, A and TLSA records.
 
 DANE will only be usable if the target host has DNSSEC-secured
 MX, A and TLSA records.
 
+A TLSA lookup will be done if either of the above options match
+and the host-lookup succeded using dnssec.
+If a TLSA lookup is done and succeeds, a DANE-verified TLS connection
+will be required for the host.
+
 (TODO: specify when fallback happens vs. when the host is not used)
 
 (TODO: specify when fallback happens vs. when the host is not used)
 
-If dane is in use the following transport options are ignored:
+If DANE is requested and useable (see above) the following transport
+options are ignored:
+  hosts_require_tls
   tls_verify_hosts
   tls_try_verify_hosts
   tls_verify_certificates
   tls_crl
   tls_verify_cert_hostnames
 
   tls_verify_hosts
   tls_try_verify_hosts
   tls_verify_certificates
   tls_crl
   tls_verify_cert_hostnames
 
+If DANE is not usable, whether requested or not, and CA-anchored
+verification evaluation is wanted, the above variables should be set
+appropriately.
+
 Currently dnssec_request_domains must be active (need to think about that)
 and dnssec_require_domains is ignored.
 
 Currently dnssec_request_domains must be active (need to think about that)
 and dnssec_require_domains is ignored.
 
@@ -1280,10 +1280,151 @@ in the delivery log line will show as "CV=dane".
 
 There is a new variable $tls_out_dane which will have "yes" if
 verification succeeded using DANE and "no" otherwise (only useful
 
 There is a new variable $tls_out_dane which will have "yes" if
 verification succeeded using DANE and "no" otherwise (only useful
-in combination with EXPERIMENTAL_TPDA), and a new variable
+in combination with EXPERIMENTAL_EVENT), and a new variable
 $tls_out_tlsa_usage (detailed above).
 
 
 $tls_out_tlsa_usage (detailed above).
 
 
+
+INTERNATIONAL
+------------------------------------------------------------
+SMTPUTF8
+Internationalised mail name handling.
+RFCs 6530, 6533, 5890
+
+Compile with EXPERIMENTAL_INTERNATIONAL and libidn.
+
+New main config option smtputf8_advertise_hosts, default '*',
+a host list.  If this matches the sending host and
+accept_8bitmime is true (the default) then the ESMTP option
+SMTPUTF8 will be advertised.
+
+If the sender specifies the SMTPUTF8 option on a MAIL command
+international handling for the message is enabled and
+the expansion variable $message_smtputf8 will have value TRUE.
+
+The option allow_utf8_domains is set to true for this
+message. All DNS lookups are converted to a-label form
+whatever the setting of allow_utf8_domains.
+
+Both localparts and domain are maintained as the original
+utf8 form internally; any matching or regex use will
+require appropriate care.  Filenames created, eg. by
+the appendfile transport, will have utf8 name.
+
+Helo names sent by the smtp transport will have any utf8
+components expanded to a-label form.
+
+Any certificate name checks will be done using the a-label
+form of the name.
+
+Log lines and Received-by: header lines will aquire a "utf8"
+prefix on the protocol element, eg. utf8esmtp.
+
+New expansion operators:
+       ${utf8_domain_to_alabel:str}
+       ${utf8_domain_from_alabel:str}
+       ${utf8_localpart_to_alabel:str}
+       ${utf8_localpart_from_alabel:str}
+
+New "control = utf8_downconvert" ACL modifier,
+sets a flag requiring that addresses are converted to
+a-label form before smtp delivery, for use in a
+Message Submission Agent context.  Can also be
+phrased as "control = utf8_downconvert/1" and is
+mandatory.  The flag defaults to zero and can be cleared
+by "control = utf8_downconvert/0".  The value "-1"
+may also be used, to use a-label for only if the
+destination host does not support SMTPUTF8.
+
+If mua_wrapper is set, the utf8_downconvert control
+defaults to -1 (convert if needed).
+
+
+There is no explicit support for VRFY and EXPN.
+Configurations supporting these should inspect
+$smtp_command_argument for an SMTPUTF8 argument.
+
+There is no support for LMTP on Unix sockets.
+Using the "lmtp" protocol option on an smtp transport,
+for LMTP over TCP, should work as expected.
+
+Known issues:
+ - DSN unitext handling is not present
+ - no provision for converting logging from or to UTF-8
+
+----
+IMAP folder names
+
+New expansion operator:
+
+${imapfolder {<string>} {<sep>} {<specials>}}
+
+The string is converted from the charset specified by the headers charset 
+command (in a filter file) or headers_charset global option, to the
+modified UTF-7 encoding specified by RFC 2060, with the following
+exception: All occurences of <sep> (which has to be a single character)
+are replaced with periods ("."), and all periods and slashes that aren't
+<sep> and are not in the <specials> string are BASE64 encoded.
+
+The third argument can be omitted, defaulting to an empty string.
+The second argument can be omitted, defaulting to "/".
+
+This is the encoding used by Courier for Maildir names on disk, and followed
+by many other IMAP servers.
+
+   Example 1: ${imapfolder {Foo/Bar}}       yields "Foo.Bar".
+   Example 2: ${imapfolder {Foo/Bar}{.}{/}} yields "Foo&AC8-Bar".
+   Example 3: ${imapfolder {Räksmörgås}}    yields "R&AOQ-ksm&APY-rg&AOU-s".
+
+Note that the source charset setting is vital, and also that characters
+must be representable in UTF-16.
+
+
+
+DSN extra information
+---------------------
+If compiled with EXPERIMENTAL_DSN_INFO extra information will be added
+to DSN fail messages ("bounces"), when available.  The intent is to aid
+tracing of specific failing messages, when presented with a "bounce"
+complaint and needing to search logs.
+
+
+The remote MTA IP address, with port number if nonstandard.
+Example:
+  Remote-MTA: X-ip; [127.0.0.1]:587
+Rationale:
+  Several addresses may correspond to the (already available)
+  dns name for the remote MTA.
+
+The remote MTA connect-time greeting.
+Example:
+  X-Remote-MTA-smtp-greeting: X-str; 220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000
+Rationale:
+  This string sometimes presents the remote MTA's idea of its
+  own name, and sometimes identifies the MTA software.
+
+The remote MTA response to HELO or EHLO.
+Example:
+  X-Remote-MTA-helo-response: X-str; 250-the.local.host.name Hello localhost [127.0.0.1]
+Limitations:
+  Only the first line of a multiline response is recorded.
+Rationale:
+  This string sometimes presents the remote MTA's view of
+  the peer IP connecting to it.
+
+The reporting MTA detailed diagnostic.
+Example:
+  X-Exim-Diagnostic: X-str; SMTP error from remote mail server after RCPT TO:<d3@myhost.test.ex>: 550 hard error
+Rationale:
+  This string somtimes give extra information over the
+  existing (already available) Diagnostic-Code field.
+
+
+Note that non-RFC-documented field names and data types are used.
+
+
+
+
 --------------------------------------------------------------
 End of file
 --------------------------------------------------------------
 --------------------------------------------------------------
 End of file
 --------------------------------------------------------------