Notes about things in progress or in the work queue, and about "wish list" things I intend to do at some point, and about things that need fixing. There are several wish lists distinguished by how much I'd like to see the items in them; those are not meant to be clues about how soon these things might appear, although one would expect some kind of correlation. (See also FLAWS file) ==================== IN THE QUEUE ==================== 20070725 use {bounces,request,owner} as prefixes and suffixes (with hyphen) to test in the return-path to disallow autoreplies for (rather than just owner- and -request as now). 20061118 consider using sysexits.h exit codes 20060615 given the recent sendmail issue, I suppose it would be a good idea to limit the nesting level of MIME... hopefully via parameter. 20060521 variant of @include that doesn't include if the file has been included before. Maybe extend @include syntax to add flags like "once" and "multiple" and "noerr" 20060206 Still some non-standard things about vacation to fix: - script is supposed to fail if more than one vacation action is attempted; - likewise, a mix of vacation/refuse/reject is supposed to fail; - vacation without :handle is supposed to synthesize a handle. I don't really like this and still may not do it. 20060206 script is supposed to fail if vacation + reject (or refuse) is done. Need to do that. 20051231 make dnsbl follow CNAMEs (just like $dns_query does) 20050629 Document mvmda exit codes in the man page 20041128 Ability to add new message parts, e.g.: - a new multipart parent to existing parts (including entire message); - a new sibling part to existing child parts. 20041219 More work on pipes. Currently if the target of "fileinto" begins with "|" it's treated as a pipe request, which is only allowed if the user has been granted "pipe_allow" status. Plan is to: a) Allow the admin to install commands into a plug-in area; these commands could be piped into regardless of the "pipe_allow" status (perhaps have a "plugin_allow"?). b) Flesh out the msg_pipe implementation. Currently it's just a quick&dirty popen() implementation, which is probably OK if the operator knows the limitations. But it needs a better implementation. Among other things, the output should not be allowed to go to stdout/stderr; such output should be captured and handled. Also, popen() requires an intermediate shell; perhaps direct exec would be better. 20050131 An SMTP daemon that interfaces with the mvmda delivery agent 20050131 An LMTP engine for the mvmda delivery agent ==================== THINGS REQUESTED ==================== ==================== HOT WISH LIST ==================== Script access to envelope and mime parts, perhaps both via built-in function and sieve primitives (first via functions). Better script access to mime parts / msgparts RFC2047/RFC2231 header decoding/encoding Probably need =.^ etc for case-insensitive regex ==================== WARM WISH LIST ==================== 20060811 How about a hook to augment the "is autoreplyable" function? 20060811 And a way for MFL script to call the "is autoreplyable" function 20060614 xmtp.c has some strict email address/mailbox parsing; the address parsing in msgpart.c is rather looser. Should probably coalesce these. 20060421 maildir quotas, ugly as they are http://www.inter7.com/courierimap/README.maildirquota.html note that '0' quota value means unlimited 20060420 I/O speed, especially reading messages, should be improved. Maybe use BIO stuff. When originating bounce messages: some mail transport systems can give different priority or different queue lifetimes to bounce or low-priority messages. Should probably support that at least for qmail-queue with Ian Taylor's "lifetime" patch. Might want to have a "neverfree" option that a user can set to inhibit deallocation of memory. It can be a kind of a waste of CPU cycles for a short-running process. Look at fuzzy matching (e.g. the TRE regex library) Latest "editheader" draft made a couple of significant changes: - add header at beginning not end, - keyword :last to alter that behaviour - if message changed, duplicate actions must succeed. Must ponder these and deal with them. Probably want to support the "variables" draft. Built-in functions for: - rolling history (e.g. de-dup message-id) - transforms and interpolations (soundex, de-punctuating, word normalizing, and the like) unbounded array .. int x[]; would specify an array that can be grown indefinitely. Views: ability to create an alternate view of a message to operate on, e.g. a view might remove a specific mime part or have headers added or changed. rolling mailboxes (keep last n messages, discard older) alternatively, discard new messages if folder has a certain size :header-only option for fileinto, keep, redirect; (views would handle this better) plug-ins via external script and interface definition When doing "From " [de]quoting should probably do reversible method (so-called "mboxrd" style) by adding/removing > on any "From " line that is preceded by zero or more > characters. Maybe add ,S=nnnn size tag to maildir filenames Would like to have a way to distinguish any "From " header (aka "From_", mbox separator, often inserted by the MTA/MDA interface) from the other headers. Programs have to set up some minimum set of global variables in order to use even some general-purpose library functions. This is a common side-effect of one program evolving into a set of programs, but some work should be done to undo some of that. ==================== GENERAL WISH LIST ==================== 20060805 it might be nice to add the concept of a null string, as opposed to an empty string. a null string could be used to indicate the lack of a string value. Currently, string pointers are used when this distinction is necessary, but wouldn't it be good not to have to do that. One would have to have some notation for the null string (for comparisons), or I suppose simply compare to an uninitialized string variable. But we already have a TC_VOID value type, why not use it. 20060630 in clamdif, support connecting to clamd over unix socket. maybe. Does anybody really want this? Too bad clamd doesn't do both unix and tcp at the same time. (although as of 0.90rc2 it can) In xmtp dialog, give the admin/installer/operator a choice of how to handle naked CR or LF line endings. RFC2821 says they must not be taken, but in the actual world, accepting naked LFs is usually an unfortunate necessity. (We take naked LF by default.) Some kind of tagging "processed by mvmda version x.x.x" at least a "Received" line. Deliver-To cleanup prevent zero-size data types from being included in aggregates local variables (function-local or block-local) 20070102 make indirect functions (ptr-to-function) work. One can currently declare them: int (*x)(int a, int b); but one can not assign to x or call *x. 20070102 lambda expressions. Would go hand-in-hand with making indirect functions work. typeof or similar, e.g. to avoid hardwired casts persistent storage (e.g. persistent arrays) ==================== NOTES/MAYBES ==================== biff support? dnotify/fam ? Perhaps a "responsible email address" to email script errors/warnings to? Might be nice if all of the published mfl function names started with 'mfl_' just for neatness sake. This might never happen. ==================== FIXES and STUFF ==================== (See also "FLAWS" file) Document extensions to literal text (e.g. \0xxx in quoted strings). mvmda scans the messagepart headers to grab some info about each part or about the message in general. However, there's the ability in the scripts to change headers. mvmda doesn't re-notice things when they have been changed by a script. This needs to be addressed. Similarly, perhaps some headers should not be eligible for changing, e.g. "Content-Type" or other mime headers. One could damage mime structure by allowing primitive naive changes to them. OTOH, am I the script writers' mother? If you mark all sibling mime parts for deletion (at some level), the parent should not be written. e.g.: consider a structure: multipart/alternative text/plain text/html If the two text subparts are marked for deletion, the multipart header should not be written. Perhaps need two delete flags, one soft flag for a mark/scan preprocess before writing the parts. The messagepart reading stuff uses generic i/o and string handling functions. Should probably change some of those things to speed up the reading of the input message. It's not a big deal, but with a few hundred thousand invocations a day (as there are here) it adds up.