+However, it would be natural to want to use $1 etc in the found-string; this
+would be hard because of the lookup caching (if repeated, the lookup won't
+actually be done and therefore the numerical variables won't be set), and in
+any case, even without caching (and it could, I suppose, be disabled for this
+lookup) those variables are not in the right storage pool even if they were
+preserved after the lookup.
+
+An alternative approach might be to implement something like this:
+
+ ${scanfile{/some/file}{sub-expression}}
+
+where the sub-expression is expanded for every line in the file, with each line
+in turn being put into $value. This is like a conditional ${readfile, and in
+fact ${readfile could be written using ${scanfile. It would be nice to find a
+way of stopping the scan once something has happened. The only thing I can
+think of is to invent a variable that changes when scanning a line generates
+some non-null text, and then always to stop on a forced failure. That would
+allow expressions like this:
+
+ ${scanfile{/some/file}
+ {
+ ${if eq{$generated}{}{${if match{regex}{$value}{something}}} fail}
+ }}
+
+It's all rather clumsy. Once a line has matched and generated some text, the
+next iteration would stop the scan. Another thought: maybe use $scanline
+instead of $value (to save confusion) and have $scantext containing everything
+that's been generated so far. That sounds pretty flexible.
+------------------------------------------------------------------------------
+
+(344) 10-Oct-05 M Make debug_print work in authenticators
+------------------------------------------------------------------------------
+
+(345) 14-Oct-05 M Standardize rejection messages
+
+"The parsing for rejection lines is a bit of a mess, and fairly
+unmaintainable. Do you think it would be possible to standardise
+rejection/refusal log messages? How about something like:
+
+(<ID>|16 Spaces) *< (Connection|MAIL|RCPT|HELO|EHLO|DATA) rejected (from
+<Address>)?: <Reason> (\(<Detail>\))?"
+------------------------------------------------------------------------------
+
+(346) 20-Oct-05 S Set $domain and $local_part in retry matching
+
+Currently, these variables are unset. Make it like rewrite matching.
+------------------------------------------------------------------------------
+
+(347) 15-Nov-05 M Arrange to expand data from wildlsearch
+
+This would allow keys that are regular expressions to set up numerical
+variables that are included in the data. This has to be done inside the lookup
+code, because of caching. Probably means we have to invent ewildlsearch and
+enwildlsearch.
+------------------------------------------------------------------------------
+
+(351) 31-Mar-06 ? Allow some/all/a few internal variables to be set
+
+The original idea was to allow "set authenticated = x" to pretend a connection
+is authenticated after other conditions are true. This can, of course, be
+packaged up using macros in other ways. Setting other variables could cause
+problems.
+------------------------------------------------------------------------------
+
+(352) 04-Apr-06 S Add +accept_defer for host lists (and maybe others)
+
+At present, a defer causes a delivery defer. For non-critical ACLs there are
+times when it may be better to accept. See also 226 and 289.
+------------------------------------------------------------------------------
+
+(354) 30-Jun-06 ? Extensions to SMTP error codes
+
+A number of ideas arose following a discussion on the mailing list. I record
+them here so that they don't get lost. The motivations were to support the 551
+bounce code and enhanced status codes. Suggestions are to add a new ACL
+feature, possibly one of:
+
+ errorcode = 511
+ control = errorcode=551
+ message = 551 xxxx
+
+where in the last case, it's recognized by being 3 digits. In all cases, the
+first digit must be "right" for the circumstance - ignore or fault if not?
+
+To handle ESC, perhaps a new variable called $smtp_errorcode, settable by an
+option in a router when it fails, would do the trick. It could be used in any
+of the above modifiers.
+------------------------------------------------------------------------------
+
+(355) 30-Jun-06 ? Facility to permit experiments with SMTP extensions
+
+This is what was suggested:
+
+- adding some expansion variables: $ehlo_extensions (which will
+ hold the remote server supported smtp extensions announced
+ in the ehlo) and $rcpt_arguments with any RCPT extra argument
+
+- a main configuration option for adding ehlo extensions to the
+ ehlo response, like:
+
+ extra_ehlo_extensions = XFOO : XBAR
+
+- a extra option for the smtp transport to add arguments to
+ the RCPT TO command, like:
+
+ rcpt_args = FOO=BAR (will make exim issue RCPT TO:<a@b.c> FOO=BAR
+ when delivering that message)
+
+- a new acl for unknown smtp commands
+
+This should be very simple to implement and will allow to make
+some experiments and implement custom extensions, i.e. one to
+known if remote client will redirect on 551 or not. Also the acl
+for unknown smtp command could be used for other purposes, like
+to detect and react to some kiddies that send things like
+http://... on the smtp port.
git://git.exim.org / exim.git / blobdiff