+
+(332) 03-Jun-05 S A "receive time taken" log selector
+
+This suggestion is to at an RT= item to the <= line, giving the time it
+actually took to receive the message.
+------------------------------------------------------------------------------
+
+(333) 06-Jun-05 L Re-think and re-implement header handling
+
+There are a number of items related to headers above. Better facilities for
+handling headers at ACL time are needed. The whole way in which Exim handles
+headers should be re-planned and re-implemented in a more consistent manner.
+
+These are the main previous items:
+
+Exim 3 Wish List: 41, 85, 149, 187.
+Exim 4 Wish List: 55, 62, 63, 160, 212, 270, 314, 328.
+------------------------------------------------------------------------------
+
+(334) 07-Jun-05 M Support for messages larger than 2G
+
+This is probably a longish-term thing at the moment. Quotas over 2G are now
+supported, but not individual messages; no doubt one day this will be wanted.
+------------------------------------------------------------------------------
+
+(336) 16-Jun-05 M Show recipient(s) after header check failure
+
+The mainlog line for "There is no valid sender in any header line" shows the
+sending host and the envelope sender, but does not show any recipients. There
+has been a request to show recipients. Presumably this should be on some new
+log selector, and it must have a cutoff maximum number of recipients. NOTE: the
+data in the reject log does show the envelope recipients as part of its
+additional data.
+------------------------------------------------------------------------------
+
+(337) 29-Jun-05 S Add "defer" to $recipient_verify_failure
+
+This is for when defer_ok was set when verifying recipients. Since this isn't
+for a failure, we probably also need "ok" for the non-fail case.
+------------------------------------------------------------------------------
+
+(338) 14-Jul-05 M Change to Bind 9 API
+
+Exim uses the original API for calling the DNS resolver. There is a newer API
+available, and noises are being made in some OS that compatibility with the old
+API is going to be dropped. Nevertheless, there are sure to be systems about
+for ages that require the use of the old API. Therefore, we will have to
+implement not only an interface to the new API, but a backwards compatibility
+feature. It would be nice if this was automatic.
+------------------------------------------------------------------------------
+
+(339) 28-Jul-05 S Log name of maildir file
+
+This wish is for an option to log the name of the file that is written in
+maildir format (e.g. time.pid.host).
+------------------------------------------------------------------------------
+
+(340) 30-Aug-05 M Match more than one item
+
+match_address, for instance, matches one address to a list. The wish is to be
+able to supply two lists; for each address in the first list, search the
+second. Maybe something like ${match_any{...}{...}} is needed.
+------------------------------------------------------------------------------
+
+(341) 15-Sep-05 S Add /return_path_retain to submission mode
+
+This would re-instate the behaviour prior to change 4.52/PH/04.
+------------------------------------------------------------------------------
+
+(342) 26-Sep-05 T Log and maybe defer odd values for condition pre-condition
+
+Odd values for "condition" in an ACL cause it to defer. In a router, they are
+treated as "true". At least they should be logged in a router, and perhaps they
+should also defer, for compatibility with ACLs.
+------------------------------------------------------------------------------
+
+(343) 03-Oct-05 M A query-style lookup for scanning flat files
+
+The natural syntax for this would be to use a regex, like this:
+${lookup regex{/some/file regex}{found-string}{not-found-string}}
+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.
+------------------------------------------------------------------------------
+--- HWM 350 ------------------------------------------------------------------
git://git.exim.org / exim.git / blobdiff