n_getdeadletter(): CID 1376996 !
[s-mailx.git] / TODO
blob58b7ca02e976770dd766cc377e07f13186a6dd16
1 TODO reminder.
3 Rename S-nail to S-mailx in v15.0, change things i've messed with
4 a single, massively backward incompatible change.
6 Release S-mailx v20 on 2020-03-25, the 42nd anniversary of BSD Mail.
7 With a clean, conforming and efficient codebase, then.
9 In general the code is in a pretty bad shape due to the signal handling.
10 I should have sat back in 2012/13 and consider what i am doing.
11 My fault.  If i would, we would have a blocked signal mask anywhere in
12 this software except in a few cases where it is necessary and/or
13 possible to deal with signals, and possibly we would not even have to
14 consider to switch the entire codebase to (the much superior, and the
15 only sane approach) SysV signal handling, without SA_RESTART.
17 But some things are already pretty good, except for normal iterations
18 and a review once we have a better signal handling, and can be taken
19 with us.  For example termcap.c, most of tty.c, shexp.c, memory.c, for
20 example.
22 - If a resource file can't be found that has been explicitly set via
23   environment variables there should be some feedback.
25 - We should possibly get away of using command line utilities for
26   compression.  (At least optionally?)  Instead we should link against
27   zlib(3), bz2lib(3) and lzma(3), if found.  Or we may use dlopen(3)
28   instead, if found, to avoid linking (though those libraries don't need
29   much linker work unless actually used afaik, 'should look in detail).
30   We should also drop lzw.c, it is used for the IMAP cache.
32 - We should maybe turn -~ into the meaning "force interactive".
33   We should extend cc-test.sh, then, to test some interactive things.
34   E.g., via (tcl(1) or, better.., perl(1) (CPAN)) expect.
36 - We need a "void" box that can be jumped to, i.e., a state in which no box
37   at all is active.
39 -- When a MBOX mailbox is removed while it is opened then changing the
40   folder is not possible.  This is an inherent problem of the Berkeley
41   Mail codebase, and we need to have a fully functional intermediate
42   VOID box mechanism plus an object-based mailbox implementation to
43   overcome it.
45 -- Also, when the folder was modified concurrently we should bail, or,
46    in an interactive session, prompt the user what to do.
48 - IDNA decoding.  Needs a complete design change.
49   (Unless wants to brute force decode anything before display, of course.)
51 - If pipes fail for part viewers then at least the usual PART X.Y should be
52   shown, maybe even including some error message.
53   I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
54   does not have lynx(1), and i thought i've found a S-nail(1) bug.
56 -- Also, when we run a pipe handler asynchronously there should possible
57    written something like [pipe-handler xy started] or something
59 - It would be nice if it would be possible to define a format string for
60   *quote*, like 'set quote="format=some formats"'.
61   In general the current approach is somewhat messy IMO.  I.e., it would
62   make more sense to act rather like mutt(1) and as written elsewhere in
63   this document, i.e., have some toggles that act on the display and use it
64   for multiple modes (show/reply/forward etc.)
65   Otherwise introduce commands which include all the headers plus, e.g.,
66   "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
68 -- This would also mean that interactive message editing would work
69   accordingly.  PleasE!
71 - Line editing should gain possibility of context sensitive tab completion.
73 - Maybe there should be an additional ZOMBIE directive that is served in
74   equal spirit to DEAD, but that could be a valid MBOX... ?
75   What i want is a *real* resend, best if possible from command line.
76   Meaning, also the possibility to postpone a message.  In general.
78 - Having a newsreader would be a really cool thing.  (RFC 977 and 2980)
80 - There should be a variable that controls whether leading and trailing
81   empty lines of parts and/or messages as such should be printed or not.
83 - printhead()/hprf(): support %n newline format (%t tab?).
84   Make it possible to use the *datefield* algorithm for plain From_ derived
85   dates (needs a From_ parser, i.e., strptime()-alike).
86   Once we have that, rename *datefield-markout-older* to
87   *date-markout-older* ??
88   Note that NetBSD's mail(1) has some other nice things.
89   Note also that our code is quite unflexible.
91 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
92    variables (though prefix and appendix or prefix and suffix, but..).
93    Note that our code is quite unflexible.
95 Low-Level
96 ---------
98 - Improve name extraction rules.  And field parsing.  There
99   are structured and unstructured fields.  There are quoted pairs and
100   comments etc.  Rewrite the entire parsing mechanism to comply to RFC
101   5322, and try to merge all those many subparsers around in the codebase,
102   and accordingly.  So much duplicated work ...
103   Name parsing has been improved a bit for v13, but it's still broken.
104   yankword(), *extract(), etc.: RFC 5322 says that comments in address
105   fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
106   approbiate, even if that actually changes content!!?), and that full
107   name-addr SHOULD be used.  Our functions are yet quite silly (i.e.,
108   leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
109   doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
110   (bier6)", that becomes "<a6@b6.de>").
111   Something silly like
112     (co$mm1) abc@däf.de (cö,mm,2)   ('c'o"m"m.3)
113   Should eventually become
114     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
115   on the display, or, with IDNA decoding (and thus rather unlikely)
116     co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
117   It should NOT become this mutt(1)ism:
118     "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
119   Or?
121 ++  NOTE: 'alternates' tracking happens BEFORE we enter composing, this
122     means that an account switch during message composing will NOT cause
123     reevaluation of all that very very clumy
124     elide/delete_alternates/gexpand/is_myname etc. handling.
126 - many uses of whitechar() should be spacechar(), and spacechar() should
127   be blankspacechar(), and blankspacechar() should be dropped.  then
128   drop onlywhitechar() again, too.  maybe reduce char_class bits then.
130 - In v15.0, when we can address attachments of a message individually,
131   it would be nice to provide even more access, just like nmh(1) does
132   (Johan Commelin: Are s-nail and mh related?).
134 - I never used anything but the *datefield* option, and it would really be
135   nice if the date strings would be parsed off into some 16 byte or what
136   storage when about to producing the summary, so that it would be directly
137   available and there would be no need to reread the mail.  Moreover, or
138   even more than that - the m_date field exists and should possibly simply
139   be init, at least in these cases.  (P.S.: this doesn't contradict the
140   statement somewhere else in this file that the structure should be
141   slacked; simply use multiple thereof or so)
143 - At some later time extend the logic behind -# -- it should not have
144   a current folder, but start in VOID mode (...), and unless one is
145   explicitly chosen..  We need a reliable batch mode.
146   P.S.: then drop again the special casing of /dev/null.
148 - After I/O layer rework we should optionally be able to read RSS
149   (Atom?) feeds -- Expat should be available almost everywhere and
150   should be able to parse that?
151   Atom is harder because it may support html+.
152   I mean, yeah, it's stupid, but we could fill in header fields with
153   dummies and still use S-nail to look into the separated feeds as if
154   they were mail messages; anyway i would like to save me from using too
155   many tools -- three seems reasonable.
157 -- `sync'hronize commando -- robin@stjerndorff.org (Robin Stjerndorff):
158     Wondering how to update back to my Maildir, moving new read mails
159     in ~/Maildir from new to cur, without exiting the application.
160     Automation available?  [And simply re-`[Ff]i' involves a lot of
161     unnecessary work]
163 -- Provide sync'ing options -- Jacob Gelbman <gelbman@gmail.com>:
164     If I open two instances of mailx, I then delete a message and then
165     quit in one. Then in the other one I read a message and quit, mailx
166     saves the status of the read message and the fact that a message was
167     deleted, even though it was opened before the other instance deleted
168     it. How is it doing that?  [Of course he was using Maildir]
170 - Add TODO notes for those RFCs:
171   RFC 977 -> 3977 - Network News Transfer Protocol
172   RFC 1036 - Standard for USENET Messages
173   RFC 1524 - True support for mailcap files?
174     TODO YES!  We really need to replace the pipe-TYPE/SUBTYPE mechanism
175     with something real.  When we can work on the parsed MAIL DOM.
176   RFC 1939 - Post Office Protocol v3
177   RFC 2017 - URL External-Body Access-Type
178   RFC 2183 - The Content-Disposition Header
179   RFC 2369 - The Use of URLs as Meta-Syntax for Core Mail List Commands
180              and their Transport through Message Header Fields
181              (RFC 6068 - The 'mailto' URL scheme)
182   RFC 2384,1738 - I.e., Much better URL support
183   RFC 2387 - multipart/related  -- yet handled like /alternative
184   RFC 2392 - Content-ID and Message-ID Uniform Resource Locators
185   RFC 2405 - The format of MIME message bodies.
186   RFC 2406 - Common multimedia types.
187   RFC 2407 - Encoding of non-ASCII text in message headers.
188   RFC 2449 - POP3 Extensions (including SASL)
189   RFC 2595 - TLS for POP3 (among others)
190   RFC 2980 - Common NNTP Extensions
191   RFC 3156 - MIME Security with OpenPGP
192   RFC 3207 - SMTP over TLS
193   RFC 3461, 3464 -
194     Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery
195       Status Notifications (DSNs),
196     An Extensible Message Format for Delivery Status Notifications
197   RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
198     text (format=flowed).   (Martin Neitzel)
199   RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
200             (Tarqi Kazan)
201   RFC 4880 - OpenPGP Message Format
202   RFC 4954 - SMTP Authentication
203   rfc5198.txt Unicode Format for Network Interchange
204   RFC 5246 - Transport Layer Security (TLS)
205   RFC 5321 - Simple Mail Transfer Protocol.
206   RFC 5322 - The basic format of email messages.
207   RFC 5598 - Internet Mail Architecture
208   RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
209     TODO NOTE that our S/MIME support is extremely weak regarding
210     TODO understanding, we should not rely on OpenSSL but instead
211     TODO handle it ourselfs; the RFC says:
212     S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
213        part, sub-parts of a message, or the whole message with all its sub-
214        parts.  A MIME entity that is the whole message includes only the
215        MIME message headers and MIME body, and does not include the RFC-822
216        header.  Note that S/MIME can also be used to secure MIME entities
217        used in applications other than Internet mail.  If protection of the
218        RFC-822 header is required, the use of the message/rfc822 media type
219        is explained later in this section.
220   RFC 6125 - Representation and Verification of Domain-Based Application
221     Service Identity within Internet Public Key Infrastructure Using
222     X.509 (PKIX) Certificates in the Context of Transport Layer Security
223     (TLS)
224   RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
225   RFC 6409 - Message Submission for Mail
226   rfc6530.txt Overview and Framework for Internationalized Email
227   rfc6531.txt SMTP Extension for Internationalized Email
228   rfc6532.txt Internationalized Email Headers
229   rfc6854.txt Update to Internet Message Format to Allow Group Syntax in
230     the "From:" and "Sender:" Header Fields
231   rfc6855.txt IMAP Support for UTF-8
232   rfc6856.txt Post Office Protocol Version 3 (POP3) Support for UTF-8
233   rfc6857.txt Post-Delivery Message Downgrading for Internationalized
234     Email Messages
235   rfc6858.txt Simplified POP and IMAP Downgrading for Internationalized Email
236   RFC 8058 Signaling One-Click Functionality for List Email Headers
238   draft-ietf-uta-email-tls-certs-01.txt
239    SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-15
240   draft-melnikov-smime-header-signing
241    Considerations for protecting Email header with S/MIME
242   Read https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07.
243     Can we implement OCSP (see RFC 6066; -> RFC 6960)????
245 - This is how the codebase has to be reworked in respect to signals and
246   jumping:
248   1. We introduce some environment/carrier structs: struct eval_ctx,
249      struct cmd_ctx, (struct send_ctx).  All of these form lists.
250      eval_ctx gets a new instance every time evaluate() is entered; for
251      the interactive mode, commands() instantiates an outermost eval_ctx
252      that "cannot be left".
254      cmd_ctx knows about the eval_ctx in which it is was created; it is
255      created for each command that has an entry in cmd_tab and is passed
256      as the new argument of these kind of functions.
257      (send_ctx is the carrier for the MIME and send layer rewrite.)
258   2. cmd_tab handling becomes more intelligent: add bit fields so that
259      for some arguments (i.e., the first two or three) automatic
260      normalization can be specified, like whitespace trimming, like
261      automatic expansion of variables etc.  For getrawlist.
263       - and: commands that work only in interactive mode, and are
264         _silently_ ignored otherwise (no error).
265         I.e., commands which work on only with true user interaction
266         should not need to take care no more, but simply assume that
267         there will be true user interaction.  And like that.
269      E.g., customhdr header field is always to be WS trimmed, just the
270      same as the body.  shortcut at least should have trimmed name, etc.
271      To do that right, properly parse from left to right, take care
272      about backslash escaping, and (optionally) expand shell variables
273      and backtick substituations.
275      The cmd_ctx needs to carry around the cmd_tab structure so that the
276      commands can themselves print the synopsis in case of errors --
277      alternatively we need a return bit which should cause the command
278      callee to emit the synopsis as an error message, whatever is best.
279      Some (hopefully) duplicate occurrances of such strings can vanish.
280   2.1 We have some commands which offer "show" subcommands.
281       Those should only work in interactive mode OR SO.
282       This could be done with a flag, too.
283   X. Offer a central "`[un]onevent' EVENT MACRO [conditions]" register.
284      Change all hooks to use that one, optimize the case where a single
285      macro is registered for a single event but with different
286      preconditions.
288      E.g., "on_interactive_mode_enter" could then be hooked to call
289      `bind' and set `colour's, for example.  In conjunction with 2.
290      above those commands could simply be (silent, successful) no-ops
291      before we reach that state (and again after
292      on_interactive_mode_leave is processed).
294   X.x We should make the message accessible at least a bit on macro level.
295       I.e., so that message specification checks can be applied on the
296       macro level, as in
297         if `message match-spec '@~t@bank.com'`
298           set smime-sign customhdr='X-BlahBlahBlah:Banks are monsters'
299         endif
300       where `message' (or so) would refer to the currently active
301       message (in compose mode) or the "dot" (otherwise).
302       `message' would gain some keywords.  Something like that.
303   8. The line buffer used in evaluate() that is passed through to
304      commands (thus: in cmd_ctx, then) needs to become `const'.
305      (I tried to do so in the past, but some commands write into it,
306      thus i stopped and iirc even added some changes on my own which
307      take favour of reusing that buffer.)
308      + Macro execution then no longer needs to clone the macro content
309      lines before executing then.
310      + The temporary hack which duplicates the line buffer in order to
311      place the original content in history can be removed again.
312      + The command context also takes preparsed command array if so
313      specified in cmd_tab, and entries are cleaned up (see 2.)
314   9. We should unite all the un*() commands with their non-un*
315      versions, if they have one.  They may take a different argument
316      list etc., but only one entry in the command table for such.
317      - The POSIX standard command abbreviations must remain, so maybe
318        outsource those in a hashtable or whatever that is checked first,
319        but detach command table order from that anyway.
320      - Offer a(n optional, and on/off switchable) Damerau-Levenshtein
321        mode for command completion;
322  10. We MUST switch the entire codebase to use SysV signal handling, don't
323      do the BSDish SA_RESTART, which is why we still suffer the way we
324      do and need jumps.  I can't dig BSD signal handling, and never ever
325      did so myself until i got here.
326  11. Macro execution is potentially recursive.  Meaning that
327      `undefine', etc. can occur while macros are executing.
328      The simplemost approach would be to have some recursion counter for
329      each macro and a delete_later flag that gets honoured when the
330      recursion counter gets zero.  It would be already possible to
331      immediately remove the macro from the hashtable, so that deeper
332      levels wouldn't find it anymore.  To avoid leaks (which *are*) we
333      need to have a jump location for our upcoming signal handler
334      anyway.  (Also to get rid of the temporary_localopts_free() hack.
335      + The same is true for `account's.  Here things are complicated by
336      the global `account_name', i.e., the account could be the current
337      one.
338      + That also is: redefinition of names that have yet-pending
339      deletion requests are possible.
340  12. It is annoying that you cannot `source' your MAILRC multiple times.
341      Defining a macro/account/xy should overwrite the current thing,
342      just as it does anyway for normal variables!
343      This is no different than 11. plus additional re-addition.
344      (Same exception: what if the currently active account is
345      overwritten?  Same answer, plus a message "new settings take effect
346      when account is switched to the next time".)
347  20. The attachment charset selection loop can then be rewritten to
348      check whether an ^C occurred and treat that as end-of-loop
349      condition.  In v14.6.3 this was introduced, but it should act
350      differently depending on whether the interrupt occurred during
351      character set selection or attachment filename input.
352      Also in respect whether the interrupt is "propagated" or not.
353      It's ugly, and documented accordingly.
354  30. Mail protocols and mail messages are accessed through a "VFS".
355      URL should then support file:// and maildir:// etc.  Update manual!
357      . It should be considered to drop many variables in favour of
358        ?SEARCH usage for keys, or key=value pairs, e.g.
359         smtp://exam.ple?starttls=yes;smtp-hostname=;
360        etc.   USER@HOST is neat, but that is possibly preferable?
361        We could then also extend *mta* and drop *smtp* as such, e.g.,
362        mta=smtp://dSDAS, mta=builtin://XZ, mta=bltin://XZ.
363        Question: what is with smtp-hostname and such??
364  31. Flag updates of individual messages must find their way through to
365      the protocol.
366  32. Use deque (on partial views).
367  34. We need a new abstraction: `vie[ws]'.  I.e, viewset, viewclear,
368      view(show|look)?  We will have (possibly readonly) boxes, a summary
369      cache file, which is created when a mailbox is read in, and all
370      that crap that we currently have (setptr(), setmsize(), etc.!) must
371      vanish.  Instead there is another, in-memory abstraction, the view.
372      Some views are builtin and are somehow selectable (the "all" view,
373      for example, and the "new" view).
374      It is possible to make a view persistent by giving it a name, e.g.,
375      'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
376      or something must be capable to tag the last a.k.a current).
377      Switching to a named view would thus look over the entire current
378      view (!) for all messages that comply to the message-spec of the
379      view, then create a sorted/threaded display of that subset and
380      create a new anonymous "result" view.  It must be possible to
381      specify that a view is to be applied to the entire mailbox instead
382      of the current view, via a simple easy understandable syntax.
384      Or name it "msgset".
385      We won't extend macros that much because it would require much too
386      much logic for no purpose, instead we'll (hopefully) add some
387      scriptable abstraction, with an optional builtin Lua binding.
388      E.g., it would be too complicated to create a language to access
389      individual message parts (headers etc.), add error handling etc.
390      Better to make it all directly accessible via language binding, and
391      offer commands which relinquish execution to such a binding, maybe
392      even with some arguments, as in "? lua ARG" - it should be possible
393      that ARG is a msgset, then.
395      But what macros should be able to do is iterating over such
396      a msgset / view, as in
397         msgset create NAME :SPEC:
398         msgset add NAME :SPEC:
399       and then either
400         for[-each] NAME
401           normal-cmd SOMEHOW-REFER-TO-ITER
402           if SOMEHOW-ACCESS-LAST-STATUS
403           endif
404         endfor
405       as well as
406         msgset cmd NAME normal-cmd
407       and even
408         normal-cmd NAME
409       in which case NAME should simply be treated as a SPEC, likely that
410       this requires a new trigger, though, e.g. {NAME}, [NAME] or !NAME...
411       I.e., the new namelist (likely a deque) should contain MsgRef
412       objects which point to a Message and a Mailbox (for cross-mailbox
413       msgset's and without the need for a Message to store a pointer to
414       the owning mailbox?  Or make MsgRef a superclass that may have
415       a subclass which offers such cross-refs).
417  50. Support SASL, unite all GSS-API etc. under an abstraction!
418      Maybe even drop direct GSS-API and support only through SASL.
419      That is, we can very well provide our own little SASL-client
420      abstraction with what we have already by simply defining some
421      "readline" abstraction plus struct ccred for use by the
422      authentication layer: the protocols must set it up by passing in
423      a line of authentication mechanisms and a callback mechanism.
424      Possibly the user should be able to permit or forbid automatic
425      selection of GSS-API (to avoid useless round-trips) etc. etc.
426  80. The MIME rewrite: mime_parser <-> mime "DOM" analyzer <->
427      selectively create filter chains per part and do XY.
429      This also affects sending, and it will allow us to dig MIME
430      (multipart) mail for -t/-m _correctly_.  Also in sofar as we can
431      hook a content-decoder before diving into the MIME structure, and
432      with a DOM, we can re-encode such things properly as we (re)send
433      such mails.  All this is wrong at the time of this writing!
434      We still need to special treat things like, e.g., RFC 2046, 5.2.1.
435      But on top of we-can, as opposed to the opposite.
436  99. Now i'm dreaming some more: with the new object-based approach
437      multiple mailboxes could be in an open state.  And it should be
438      possible to do so for the user (`file' and `folder' are required to
439      quit the current mailbox [first -- this not yet]), which is why we
440      either need new trigger characters or new commands.
441      The absolute sensation would be joinable operations over multiple
442      open mailboxes, e.g., views over multiple such!
443 100. If i say `p 3 2 1' then i mean `3 2 1' not `1 2 3'.
444 1000. Extend macros and provide language bindings.  See item 34.
445      Additionally there was:
446     I want *pipemac* (or *pipe-hookXY*).  This requires v15.0
447     infrastructure (pseudo: evaluate() returns enum eval_retval{OK=0,
448     ERR=1, ISMAC=0x80, MACOK=ISMAC|OK, MACERR=ISMAC|ERR}; new `return'
449     command which only works in an executing macro (care: recursion);
450     macro arguments in pseudo variables $1...$x (works?); `return' can
451     "return" a list (simply keep argument list around); macro execution
452     can then simply check the return value to decide what to do (no
453     jumping); btw.: where is our `clone' command which clones WHATEVER?):
454       define pipemac {
455         clone name=$1 base=$2 ext=$3 ACTION=$4([SEND_]MBOX|DISPLAY|etc)
456         if $name =~ 'README|INSTALL|TODO|COPYING|*.(txt|rc|cfg|conf)$'
457           return 'text/plain'
458         elif $ext =~ 'gz$'
459           return 'application/gzip'
460         elif $ext =~ '*.\.nim$'
461           return 'text/x-nimrod'
462         else
463           varshell i /usr/bin/file --preserve-date $name
464           return $i
465         endif
466       }
467     Also interesting would be the possibility to let a macro BE the
468     (forked+exec, I/O redirected) external handler, "returning the
469     output I/O handle".
470     Inspired by Gavin Troy and Bob Tennent.
472 -- Also (?same problem?) the thread sort doesn't get
474     [A is deleted]
475     B answers A
476       C answers B
477       D answers B
478     E is unrelated
479     F answers A
481   The current sort fails to recognize that F and the thread starting at
482   B are related, which results in a mess.
484 --- Being able to sort the outermost level of threads was a suggestion
485     of Rudolf Sykora, especially being able to sort the outermost level
486     according to the date of the newest message in a thread.
488 - Drop **use-starttls* in favour of something better: support 'auto',
489   'no' and 'yes' and act accordingly.  For the former be smart enough on
490   the protocol side.  (RFC 3207 describes man-in-the-middle attacks due
491   to 'auto' TLS, so explicit 'yes' should be favoured).
493 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
494   deal with IPv6 addresses (as in '[ADDR]:PORT').  Pimp url_parse().
495   And socket I/O.
497 - I had a connection collapse during a POP3 download, and neither was
498   there a chance to get access to the 22 yet downloaded mails (after
499   five minutes of waiting followed by CNTRL-C), nor did the layer
500   recognize this very well (got myriads of `POP3 connection already
501   closed.' messages, btw., the thirty-something messages which were not
502   yet downloaded caused (after CNTRL-C) this: ETC. ETC.
504 - Add a value-duplication command, i.e.,
505     clone _x header
506     unset header
507     ...
508     clone header _x
509     unset _x
511 - I got an email in base64 that obviously used CRNL line endings, and once
512   i've replied the CR where quoted as *control* characters.
513   Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
514   time, due to how we deal with I/O and Send layer etc).
516 - edit.c doesn't do NEED_BODY (but IMAP won't work anyway).
518 - Stuff
519   .. s-nail </dev/null should work interactively when STDERR_FILENO is
520     a terminal!  (Builtin editor; how do editline and readline work?
521     should this be documented?  What does NetBSD Mail do?  Should we NOT
522     be interactive??  POSIX says for sh(1) (APPLICATION USAGE): 'sh
523     2>FILE' is not interactive, even though it accepts terminal input.)
524   . It would be cool if ghosts, shortcuts, alternates could
525     (optionally?) be tracked via localopts.  And macros.  And inner macros.
526     (Additional entry on xy-local xy somewhere above)
527     And / or local to a macro/account if defined in one.
528     Should be per-carrier copy-on-write environments.
529     Just like TeX with def / gdef ...
530   . Just like the RFC 3676 link above, it would be nice if it would be
531     somehow possible to recognize links in a document; i don't know yet
532     how this could be achieved without loosing formatting information (i
533     mean, we could enable this and inject terminal colour sequences, but
534     one should be able to say 'follow link x', starting an action
535     handler, and the 'x' must come from somwhere - simply injecting
536     '[NUMBER]' references distorts visual).  Anyway, it's just a filter
537     that recognized the usual <SCHEME:/> stuff, and of course we can
538     simply have a buffer which records all such occurrences, so that
539     user can say '? xy NUMBER', but without the context it soon gets
540     hard.
541   . TTY layer: the tc*() family may fail with EINTR, which MUST be
542     handled; setting also generates SIGTTOU when we're not in foreground
543     pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
544     resetting terminal attributes!
545   .. TTY "I guess it would be much better to create our own session via
546      setpgid(2) and then tcsetpgrp(3) any processes we run synchronously,
547      and properly deal with SIGTTOU, but it always has been like that and
548      i won't do that before other things have been changed.
549   .. NOTE: TTY: place (at least n_child_run()) childs which go over
550      terminal into own group.
551      Introduce global "terminal state" manager which tracks who
552      currently owns the terminal, so that we can gracefully switch it
553      on/off, check in main loop whether restore is necessary.
554      It that can deal with multiple "windows" then we could have open
555      multiple of those, i.e., multiple PAGER instances, and non-PAGER
556      instances (fflush() if there is FILE before switch off).
558      TTY thus: "needsterminal" could be driven gracefully EVEN IF
559      a PAGER is open because the current user action is "print*", since
560      we KNOW that there is a PAGER and can temporarily lay it down to
561      sleep, fflush()ing/adjusting as necessary, and wake it up again
562      afterwards (or, with some work, gracefully shut it down if ^C ^C).
563      This is of course also true for user questions ("really display
564      part XY?", "need decryption password:", etc.!!!)!!
565   . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
566     global mbstate_t objects until the send / MIME layer rewrite is done and
567     has the carrier.  Use flip states and add aux funs with only update the
568     state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
569     HANDLED!!
570   . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
571     Maybe our passed carrier should pass desired output newline (as
572     opposed to data-embedded newlines)
573   . which_protocol(), *newmail* mechanism, displayname, mailname: all of
574     this <rude>SHIT</rude> must vanish and be replaced by a URL, and
575     a nice "VFS" mailbox object that carries all necessary state so that
576     one can work with it.
578     If not mentioned somewhere else: struct message should be splitted
579     into a tree of objects, with a base class that has as few fields as
580     possible; the global *message should be a deque, only accessible via
581     iterator; it should store pointers to (the actually used subtype of)
582     message structures instead; i.e., for maildir boxes the path is yet
583     allocated separately, then it could be part of the message object,
584     etc.
585     It should contain a ui8_t that tracks the number of contained parts,
586     so that the "fits-onto-the-screen" tests are more useful than today;
587     i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
588   . Given how many temporary files we use, it would make sense to
589     support a reusable single temporary file, as in singletmp_take() and
590     singletmp_release(), where singletmp_release() would close and thus
591     drop the file if it excesses a specific (configurable) size, and the
592     mainloop tick would close it (after X (configurable) unused ticks))
593     otherwise.  I guess this would improve performance for searching
594     etc. etc.
595   . _(), N_(), V_():
596     use GNU tools for extraction etc., and write a simple helper program
597     which converts these files to a serialized hashmap, just like we did
598     for the okeys (and *exactly* so); add a config check whether the ({})
599     extension is supported and finally use that for some ({static char
600     const *tr_res;}) injection optimization, then.  (Think SFSYS)
601   . Searching body/text yet includes headers from attachments and
602     attachment data.  This is shit.  :)
603   . The "nifty" unregister_file()->_compress() mechanism that even
604     shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
605     *records* calls clearerr() on the descriptor before performing it's
606     action anyway.  when we really make it even to the I/O rewrite, it
607     should be possible to dis-/allow such -- it doesn't make sense to
608     add something faulty to whatever was not faulty before!
609   . `dp' prints EOF at the end of a thread even if unread messages
610     follow
611   . When doing `~w FILE' and FILE cannot be written to (was a directory)
612     then the composed mail is lost completely, it seems we jump to the
613     very main loop!
614   . `resend' doesn't smime-sign.
615   . Really do extend the test already today; test S/MIME
616     signing/encryption/decryption with two pairs of identities, instead
617     of of one.
618   . RFC 5751 describes a message multipart layout that also includes the
619     headers in the signature; it would be nice (for completeness sake)
620     to be able to support that.  Note shutup@ietf.org.
621   . The capability to save a message under the name of a recipient is in
622     the standard etc., but i've never used it.
623     What would be cool, otoh, would be if there would be the possibility
624     to register a regular expression, and if just *any* recipient of
625     a message matches, store the message in the given folder instead.
626     I.e., if i send a message to s-nail-users@ then i most likely want
627     to get a copy to the corresponding box, regardless of whoever the
628     message was sent To: Cc: or Bcc: else..
629   . why not simply sucking in complete MIME messages via -t?  In a way
630     that parses it as a MIME message, that is!
631     (Brezn Stangl, brezn DOT stangl AT yandex DOT com)
632   . mutt list handling (`~') is very powerful
633   . We have some use of *at() functions, especially anything which
634     temporarily switches cwd.
635   . *newmail* is terrible.  At some later time we need to do somethings
636     with timeouts etc. (for MBOX and Maildir it's not that bad, but for
637     anything over the network, yet the mentioned may come in over NFS).
638     Remove it until we have something better?
639   . The RFC 3798 *disposition-notification-send* mechanism is yet not
640     truly conforming (and works with *from*).  Also, this is only the
641     sender side, there should be support for creating the MDN response.
642     (Maybe ternary option: off (default),
643     create-when-unread-flag-goes-away, ditto-but-also-strip-header)
644   .. Also, there is DSN as a SMTP extension, see the RFCs 3461, 346 (as
645      above) and 6522 (Wikipedia).
646   . The var_* series should return "const char*" not "char*".
647     This should already work today because otherwise we would get SEGV
648     all through the way.
649   .. While here: rename enum okeys to enum internal_variables, and the
650      ok_*() series to iv_().  And see below for env_*() series.
651   . fexpand() the 2nd: it should return structure because we need to
652      check for FEDIT_SYSBOX, which currently only checks whether the first
653      character of a file name is '%', not whether it is '%', '%:FILEPATH'
654      or '%VALIDUSER', because that is impossible to do!
655   . On the long run in-memory password storage should be zeroed after
656     use, possibly even encoded *during* use.  After v15.
657   . We need a `spamcheck' command that is like `spamrate' but updates
658     the mail in-place, i.e., with the headers that the spam engine adds.
659   . __narrow_suffix() is wrong (for stateful encodings that we
660     don't support yet) and should inject a reset sequence if it shortens
661     the string.
662   .. THAT IS TO SAY: the entire codebase doesn't really support stateful
663     encodings, including the bidi_ things that i've done (but the MLE
664     does iirc?  what is this??).  We should have a global string that
665     has the multibyte reset sequence plus length available for easy
666     access.
667   . When a user edits a specific header, it should no longer be
668     modified.
669   . Regular expression list resorting is no good; the user should be
670     able to specify a match order weight, as in:
671       mlist 10 a@b.org 8 c@d.org .*@else@org 0 almost@never.com
672     So: optional digit 0-10, where 0-4 are never relinked and always
673     placed at the tail, 6-10 are never relinked and always placed at
674     head (all in decreasing order, head to tail), and 5 is the implicit
675     value, placed in between and automatically resorted just as is the
676     sole algorithm we currently have.
677   .. And maybe we should have an event mechanism with one-shot etc..
678      Then install a resorter function when we actually have lookups and
679      one-shot sort the entire thing once (when the loop ticks).
680      Instead of busy resorting, that is.
681   . Some pieces of cake (e.g. usermap()) don't perform actions on
682     addresse(e)s if the first character is a backslash.  Others do.
683     And do we really support that notion all through the codebase.
684     And, even more: should we support that at all?
685   . We need more hooks: on-leave, on-connect.. whatever
686   . The new internal ~/$ expansion mechanism should possibly get support
687      for POSIX parameter expansions ${[:]-} and ${[:]+} (and ${[:]?}).
688      There is no real way to get the functionality otherwise...
689   . Make S/MIME an option separate of SSL/TLS, i.e., optional.
690   . With very long input Heirloom mailx(1) / S-nail(1) can produce
691     encoded-words (RFC 2047) with incomplete multibyte sequences (i.e.,
692     non self-contained encoded-words).
693   . Group addresses, especially the undisclosed recipients but also
694     "Bla": addresses; are missing.
695   . It is terrible that -S sets variables twice, at once and after the
696     resource files have been loaded.  Instead we should set a bit
697   . Cleanup:  n_ is anything public / external,
698     _n_ is public/e but not really, FILENAME/ABBREV_symbol are statics,
699     FILENAME/ABBREV__symbol are helpers of a single other static
700     (function group) (-> colour.c, lex_input.c: done).
701   . Per-folder (S/MIME) en- and decryption key (Tarqi Kazan): if a xy
702     variable is set (that points to a key) add a transparent en- and
703     decryption layer on top of any per-message operation (for boxes for
704     which the variable is set).
705   . For v15.0: remember private thread with Tarqi Kazan (2015-05) and
706     try to improve situation with *record*, so that only messages enter
707     it which have really been sent.  If we support postponing and have
708     a multi-process layout and add an intermediate *record-queue* we
709     may be able to improve the situation.
710   . I like "SMTP and SUBMISSION Service Extensions For Address Query",
711     for which we need
712       if (!SSL_set_tlsext_host_name(con, servername))
713         error
714   . [Dd]ecrypt should transport decryption errors, not silently be like
715     copy and copy undecrypted content, because this is what it's for?
716     ..We need atomic operations with rollback support in order to make
717       this happen, but i think maybe file truncation (decryption always
718       appends?) is enough provided that files are locked?
719       WE NEED ATOMIC OPERATION SUPPORT for quite some operations.
720       Man, are we far from that.
721   . `pipe' is total shit regarding MIME.  We need some defined and
722      documented method to configure which parts are displayed and/or how
723      they are visually separated.
724   . The new n_err() facility is nice, but we need n_msg() too, maybe
725     more.  Maybe à la Log:: and macro wrappers with priority unrolled,
726     then add user-settable treshold, too.  Btw. C99 adds vararg macros.
727     .. We must handle embedded newlines properly
728     .. In PARTICULAR we MUST NOT use stdout when in batch mode:
729          ssh X "echo 'move * |cat' | s-nail -#f %" >> download
730        should do the right thing, but can't like that due to unwanted
731        noise in the stdout output!  Best would be if it would be
732        possible to explicitly define a file/dev to be used, but falling
733        back to stderr in batch mode otherwise. (think S-Web42)
734   . Exit status handling is sick.
735   . Especially in interactive mode MIME classification should count
736     (non-NUL) control characters and the number of different thereof,
737     giving users an option to treat something as text nonetheless.
738     E.g., roff files often use controls as separators in conditionals,
739     some shell scripts use controls for $IFS field separation, and that
740     will end up with charset=binary.
741   .. *mime-allow-text-controls* is a no-brainer: instead we should
742      introduce something that allows us to switch and detect UTF-16 once
743      we run into the problematic situation, then start all over in an
744      Unicode mode?  I.e.: continue to force the user to set such
745      a switch, but do it in a sensible fashion, because the UTF-16 data
746      stream may nonetheless contain control characters??
749   . We can "steal" features from msmtp(1) that make sense: SOCKS support
750     (primitive) and /etc/aliases ($mta_alias_file).  At least postfix(1)
751     supports file and pipe addressees in the latter...  It also
752     supports include files via :include:/filename but which i think
753     should be supported in a second step.  Ditto caching (timestamp
754     check and a mechanism to support/disable caching.)
756 # s-ts-mode