DCC Support
--------------------------------------------------------------
+Distributed Checksum Clearinghouse; http://www.rhyolite.com/dcc/
*) Building exim
msg:complete after main per message
msg:delivery after transport per recipient
+ msg:rcpt:host:defer after transport per recipient per host
+ msg:rcpt:defer 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
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.
+New event types may be added in the future.
+
There is an auxilary variable, $event_data, for which the
content is event_dependent:
msg:delivery smtp confirmation mssage
+ msg:rcpt:host:defer error string
+ msg:rcpt:defer error string
msg:host:defer error string
tls:cert verification chain depth
smtp:connect smtp banner
-The msg:host:defer event populates one extra variable, $event_defer_errno.
+The :defer events populate one extra variable, $event_defer_errno.
The following variables are likely to be useful depending on the event type:
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,
+however due to the multiple contexts the Exim operates in
+a) variables set in events raised from transports will not
+ be visible outside that transport call.
+b) acl_m variables in a server context are lost on a new connection,
+ and after helo/ehlo/mail/starttls/rset commands
+
The expansion of the event_action option should normally
+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