imap_cache.c: fix memory leaks

[s-mailx.git] / TODO

TODO reminder.

Release S-nail v20 on 2018-03-25, the 40th anniversary of Mail.
With a clean, conforming and efficient codebase, then.

- Recipients specified on the command line should be added to those
  specified in the message when the -t option is set.

- At least optionally disallow silent discarding of invalid addresses,
  i.e., cause sending to be aborted if not all recipient addresses pass the
  validity test.

- Ditto if a resource file can't be found that has been explicitly set via
  environment variables there should be some feedback.

- I.e., it is fine to be silent unless an error occurs, but then please
  report errors and offer (in interactive mode) the possibility to act at
  a glance.  (See error ring topic around here.)

- POSIX says that, when written to DEAD: "If the file exists, the message
  shall be written to replace the contents of the file".  This is mentioned
  for ASYNCHRONOUS EVENTS, but it's the only description of what should be
  done in which way to DEAD.  savedeadletter() yet appends.  See ZOMBIE ,)

- It irritates me that a message with 5 visible lines but 115 header lines
  goes through the pager, even if i have *crt=*.

- We should possibly get away of using command line utilities for
  compression.  (At least optionally?)  Instead we should link against
  zlib(3), bz2lib(3) and lzma(3), if found.  Or we may use dlopen(3)
  instead, if found, to avoid linking (though those libraries don't need
  much linker work unless actually used afaik, 'should look in detail).
  We should also drop lzw.c, it is used for the IMAP cache.

- We should maybe turn -~ into the meaning "force interactive".
  We should extend cc-test.sh, then, to test some interactive things.

- We need a "void" box that can be jumped to, i.e., a state in which no box
  at all is active.

-- When a MBOX mailbox is removed while it is opened then changing the
  folder is not possible.  This is an inherent problem of the Berkeley
  Mail codebase, and we need to have a fully functional intermediate
  VOID box mechanism plus an object-based mailbox implementation to
  overcome it.

-- Also, when the folder was modified concurrently we should bail, or,
   in an interactive session, prompt the user what to do.

- IDNA decoding.  Needs a complete design change.

- Mail-Followup-To:.

- mutt(1) quotes all text parts of a message, not only the first one!
  This should at least be optionally available.

- If pipes fail for part viewers then at least the usual PART X.Y should be
  shown, maybe even including some error message.
  I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
  does not have lynx(1), and i thought i've found a S-nail(1) bug.

- Offer the possibility to work with certificate fingerprints instead of
  full certificates, in equal spirit to the current maintainers S-Postman
  and Mercurial.  S-nail(1) could simply offer something in equal spirit to
  the formers --fingerprint, so that no other tool is necessary for
  certificate management (for at least secure transport).

- It would be nice if it would be possible to define a format string for
  *quote*, like 'set quote="format=some formats"'.
  In general the current approach is somewhat messy IMO.  I.e., it would
  make more sense to act rather like mutt(1) and as written elsewhere in
  this document, i.e., have some toggles that act on the display and use it
  for multiple modes (show/reply/forward etc.)
  Otherwise introduce commands which include all the headers plus, e.g.,
  "hreply" or "freply", and then the ditto series, i.e., "hReply" ...

-- This would also mean that interactive message editing would work
  accordingly.  PleasE!

- Command line editing should gain possibility of context sensitive tab
  completion.

-- Note that the TTY is sick.  If ^C on input it simply jumps to next
   input, instead of saying "Interrupted, one more to die hard" or
   something (talking about ~@ charset selection prompts in particular).

- For those who use S-nail(1) only with a MTA it may be desirable to have
  some "smopts" expansion mechanism in equal spirit to NetBSD mailx(1).

- Maybe there should be an additional ZOMBIE directive that is served in
  equal spirit to DEAD, but that could be a valid MBOX... ?
  What i want is a *real* resend, best if possible from command line.
  Meaning, also the possibility to postpone a message.  In general.

- POP3 doesn't support "newmail" for real.  If implemented, should it sync?
  Look at POP3 impl. in general..

- Having a newsreader would be a really cool thing.  (RFC 977 and 2980)

- There should be a way to ignore the From_ line, as opposed to the From:
  line, i.e., distinctively.

- There should be a variable that controls wether leading and trailing
  empty lines of parts and/or messages as such should be printed or not.

- printhead()/hprf(): support %n newline format (%t tab?).
  Make it possible to use the *datefield* algorithm for plain From_ derived
  dates (needs a From_ parser, i.e., strptime()-alike).
  Once we have that, rename *datefield-markout-older* to
  *date-markout-older* ??
  Note that NetBSD's mail(1) has some other nice things.
  Note also that our code is quite unflexible.

-- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
   variables (though prefix and appendix or prefix and suffix, but..).
   Note that our code is quite unflexible.

- The "top" command should honour ignoretab, or there should be a very
  special "top" ignoretab.  It simply doesn't make sense to "top" 5 lines
  when all that you get are Received: lines...

- In the very end it is not that hard to add (optional) MTA
  functionality at a most simple level.
  Use sqlite for aliases (and possibly cache), then.

- We should support IMAP compression over the wire.

Low-Level
---------

- Improve name extraction rules.  And field parsing.  There
  are structured and unstructured fields.  There are quoted pairs and
  comments etc.  Rewrite the entire parsing mechanism to comply to RFC
  5322, and try to merge all those many subparsers around in the codebase,
  and accordingly.  So much duplicated work ...
  Name parsing has been improved a bit for v13, but it's still broken.
  yankword(), *extract(), etc.: RFC 5322 says that comments in address
  fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
  approbiate, even if that actually changes content!!?), and that full
  name-addr SHOULD be used.  Our functions are yet quite silly (i.e.,
  leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
  doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
  (bier6)", that becomes "<a6@b6.de>").
  Something silly like
    (co$mm1) abc@däf.de (cö,mm,2)   ('c'o"m"m.3)
  Should eventually become
    co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
  on the display, or, with IDNA decoding (and thus rather unlikely)
    co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
  It should NOT become this mutt(1)ism:
    "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
  Or?

-- Think about a name bypass hashmap cache, and whenever we have to skin or
   nalloc() or whatever, look in there.  Maybe even an additional link for
   non GFULL(/GSKIN) and fully skinned struct name objects.
   The amount of duplicated work in this codebase is frustrating, but the
   real healing would make necessary a complete rewrite of the name handling!
   Such a cache would work without touching the current code flow ... or
   allow a smooth transition to a new one anyway.

++  NOTE: 'alternates' tracking happens BEFORE we enter composing, this
    means that an account switch during message composing will NOT cause
    reevaluation of all that very very clumy
    elide/delete_alternates/gexpand/is_myname etc. handling.

- The char classification stuff can be improved; currently each character
  has exactly one classification bit set, even if multiple would apply
  (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK).  This would allow better
  testing using our own classification functions in quite some places.

- The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
  it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
  Webmail) create HTML parts which solely consist of a single line,
  created via soft linebreaks.
  To handle such mess we need to be able to break out of the input-line ==
  output line relationship that is still fixated in the codebase.
  I.e., it is not even sufficient to convert "rest" into an array, but best
  would be if we would be able to sequentially work what we have, and
  detect when it is safe to "dump that out".
  This MUST be part of the send/mime layer rewrite in 15.0.

-- In v15.0, when we can address attachments of a message individually,
   it would be nice to provide even more access, just like nmh(1) does
   (Johan Commelin: Are s-nail and mh related?).

- I never used anything but the *datefield* option, and it would really be
  nice if the date strings would be parsed off into some 16 byte or what
  storage when about to producing the summary, so that it would be directly
  available and there would be no need to reread the mail.  Moreover, or
  even more than that - the m_date field exists and should possibly simply
  be init, at least in these cases.  (P.S.: this doesn't contradict the
  statement somewhere else in this file that the structure should be
  slacked; simply use multiple thereof or so)

- All error messages should not go to stderr but instead we should add our
  own n_warn() family and use that.  In the background we should have
  a ring of error messages (oldest fall off), and a command that is capable
  to display the ring.  The command loop should recognize whenever an error
  happened during the last command, and print something like "XY errors
  occurred", followed by a (truncated as necessary) error report.
  It simply doesn't make any sense to print errors on stderr if normal
  output goes to stdout and scrolls it off the screen.
  Note that yet some errors messages still go to stdout.

- It would be very nice if it would be possible to have
  account-specific macros that will be lost when a user switches off
  an account.

-- It would also be very nice if we could define macros while defining
   account, i.e., recursive definition of macros...

- At some later time extend the logic behind -# -- it should not have
  a current folder, but start in VOID mode (...), and unless one is
  explicitly chosen..  We need a reliable batch mode.

- (Support for mailcap files?  As of RFC 1524?  Unlikely.  Though the
  % expansions would be very helpful, especially once we can address
  individuals parts as of v15.0!)

- After I/O layer rework we should optionally be able to read RSS
  (Atom?) feeds -- Expat should be available almost everywhere and
  should be able to parse that?
  Atom is harder because it may support html+.
  I mean, yeah, it's stupid, but we could fill in header fields with
  dummies and still use S-nail to look into the separated feeds as if
  they were mail messages; anyway i would like to save me from using too
  many tools -- three seems reasonable.

- Add TODO notes for those RFCs:
  RFC 5322 - The basic format of email messages.
  MIME (Multimeda) email extensions
  RFC 2405 - The format of MIME message bodies.
  RFC 2406 - Common multimedia types.
  RFC 2017 - URL External-Body Access-Type
  RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
    text (format=flowed).   (Martin Neitzel)
  RFC 2407 - Encoding of non-ASCII text in message headers.
  RFC 2183 - The Content-Disposition Header
  RFC 2231 - Encoding of character set and language information in MIME
    parameter values.
  SMTP (Simple Mail Transfer Protocol)
  RFC 5321 - Simple Mail Transfer Protocol.
  RFC 6409 - Message Submission for Mail
  RFC 4954 - SMTP Authentication
  RFC 3207 - SMTP over TLS
  RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
  Post Office Protocol (POP)
  RFC 1939 - Post Office Protocol v3
  RFC 2449 - POP3 Extensions (including SASL)
  RFC 2595 - TLS for POP3 (among others)
  Security
  RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
            (Tarqi Kazan)
  RFC 5246 - Transport Layer Security (TLS)
  RFC 977 -> 3977 - Network News Transfer Protocol
  RFC 1036 - Standard for USENET Messages
  RFC 2980 - Common NNTP Extensions
  RFC 2387 - multipart/related
  RFC 2384,1738 - I.e., Much better URL support
  RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
  RFC 6125 - Representation and Verification of Domain-Based Application
    Service Identity within Internet Public Key Infrastructure Using
    X.509 (PKIX) Certificates in the Context of Transport Layer Security
    (TLS)

- This is how the codebase has to be reworked in respect to signals and
  jumping:

  1. We introduce some environment/carrier structs: struct eval_ctx,
     struct cmd_ctx, (struct send_ctx).  All of these form lists.
     eval_ctx gets a new instance every time evaluate() is entered; for
     the interactive mode, commands() instantiates an outermost eval_ctx
     that "cannot be left".
     cmd_ctx knows about the eval_ctx in which it is was created; it is
     created for each command that has an entry in cmd_tab and is passed
     as the new argument of these kind of functions.
     (send_ctx is the carrier for the MIME and send layer rewrite.)
  2. We'll get a signal manager.  This is a global layer which is the
     sole object-in-charge for signals.  We'll install a complete set of
     handlers once -- those will only set has-occurred bits.
     All interested parties have to peek at the signal manager when they
     are in the position to deal with signals, via a series of
     "ha(s|ve)_occurred", "needs_action", "would_raise" or whatever, as
     well as "doact".
  3. We need a sort of non-local return, everything else would require
     a totally different way of programming.  Also, non-local returns
     are not *that* bad, generally speaking.  We'll be easy and add the
     possibility to define a jump target location in eval_ctx and
     cmd_ctx, by peeking at the signal manager (for object design
     reasons, though done by a macro, say), just like saying "i need to
     have the chance to perform some actions shall a jump be necessary".
  4. So, somewhere deep down the still recursive codebase, shall the
     necessity to honour a jump request occur, we peek the signal
     manager to "unroll" the current cmd_ctx/eval_ctx chain(s), which
     will result in none-to-multiple jumps to locations which require
     cleanup actions, ultimately ending in the non-leavable commands()
     eval_ctx or whatever.
  6. Hot: we save us from thousands of syscalls, and get rid of the
     fucking sig* shit.  It rhymes, it rhymes :)
     Should we even be able to go the non-blocking select(2) way in the
     end -- that would be fantastic!
 10. The line buffer used in evaluate() that is passed through to
     commands (thus: in cmd_ctx, then) needs to become `const'.
     (I tried to do so in the past, but some commands write into it,
     thus i stopped and iirc even added some changes on my own which
     take favour of reusing that buffer.)
     + Macro execution then no longer needs to clone the macro content
     lines before executing then.
 11. Macro execution is potentially recursive.  Meaning that
     `undefine', etc. can occur while macros are executing.
     The simplemost approach would be to have some recursion counter for
     each macro and a delete_later flag that gets honoured when the
     recursion counter gets zero.  It would be already possible to
     immediately remove the macro from the hashtable, so that deeper
     levels wouldn't find it anymore.  To avoid leaks (which *are*) we
     need to have a jump location for our upcoming signal handler
     anyway.  (Also to get rid of the temporary_localopts_free() hack.
     + The same is true for `account's.  Here things are complicated by
     the global `account_name', i.e., the account could be the current
     one.
 12. It is annoying that you cannot `source' your MAILRC multiple times.
     Defining a macro/account/xy should overwrite the current thing,
     just as it does anyway for normal variables!
     This is no different than 11. plus additional re-addition.
     (Same exception: what if the currently active account is
     overwritten?  Same answer, plus a message "new settings take effect
     when account is switched to the next time".)
 20. The attachment charset selection loop can then be rewritten to
     check wether an ^C occurred and treat that as end-of-loop
     condition.  In v14.6.3 this was introduced, but it should act
     differently depending on wether the interrupt occurred during
     character set selection or attachment filename input.
     Also in respect wether the interrupt is "propagated" or not.
     It's ugly, and documented accordingly.
 30. Mail protocols and mail messages are accessed through a "VFS".
 31. Flag updates of individual messages must find their way through to
     the protocol.
 32. Use deque (on partial views).
 33. It must be possible to open individual boxes read-only, new command
     `cfile' (and `cfolder') as a last resort.
 34. We need a new abstraction: `vie[ws]'.  I.e, viewset, viewclear,
     view(show|look)?  We will have (possibly readonly) boxes, a summary
     cache file, which is created when a mailbox is read in, and all
     that crap that we currently have (setptr(), setmsize(), etc.!) must
     vanish.  Instead there is another, in-memory abstraction, the view.
     Some views are builtin and are somehow selectable (the "all" view,
     for example, and the "new" view).
     It is possible to make a view persistent by giving it a name, e.g.,
     'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
     or something must be capable to tag the last a.k.a current).
     Switching to a named view would thus look over the entire current
     view (!) for all messages that comply to the message-spec of the
     view, then create a sorted/threaded display of that subset and
     create a new anonymous "result" view.  It must be possible to
     specify that a view is to be applied to the entire mailbox instead
     of the current view, via a simple easy understandable syntax.
 50. Support SASL, unite all GSS-API etc. under an abstraction!
     Maybe even drop direct GSS-API and support only through SASL.
     That is, we can very well provide our own little SASL-client
     abstraction with what we have already by simply defining some
     "readline" abstraction plus struct ccred for use by the
     authentication layer: the protocols must set it up by passing in
     a line of authentication mechanisms and a callback mechanism.
     Possibly the user should be able to permit or forbid automatic
     selection of GSS-API (to avoid useless round-trips) etc. etc.
 99. Now i'm dreaming some more: with the new object-based approach
     multiple mailboxes could be in an open state.  And it should be
     possible to do so for the user (`file' and `folder' are required to
     quit the current mailbox [first -- this not yet]), which is why we
     either need new trigger characters or new commands (then also in
     a readonly version, again, it gets lengthy).
     The absolute sensation would be joinable operations over multiple
     open mailboxes, e.g., views over multiple such!

TODO S-nail 14.7:
-----------------

- Deal with faulty message selection that may occur when selecting threads
  via & (when at least mixed with other selectors).

-- Also (?same problem?) the thread sort doesn't get

    [A is deleted]
    B answers A
      C answers B
      D answers B
    E is unrelated
    F answers A

  The current sort fails to recognize that F and the thread starting at
  B are related, which results in a mess.

- Drop **use-starttls* in favour of something better: support 'auto',
  'no' and 'yes' and act accordingly.  For the former be smart enough on
  the protocol side.  (RFC 3207 describes man-in-the-middle attacks due
  to 'auto' TLS, so explicit 'yes' should be favoured).

- NOTE: we do not really support IPv6 sofar in that we are not prepared to
  deal with IPv6 addresses (as in '[ADDR]:PORT').  Pimp url_parse().
  And socket I/O.

- mutt(1) dotlock ..., "mbox" command doesn'T work?

- ARGH!  Should `folders' auto-login if *folder* is an IMAP account that is
  not active?  Why does _expand() use *mailname* to expand `@', not
  getfold() (care: res may point into cbuf, savestr() or so!).
  Why does demail() etc. treat *mailname* as a file (more or less), why do
  we need *mailname* at all;  we should have Folder objects, multiple of
  which concurrently, one the active; a Folder may not become *folder*
  unless it has write (store) capabilities).  Maybe then `mbox' works fine
  if connected to a POP3 server with a *MBOX* on an IMAP account that yet
  never was connected and needs to read a password on the terminal before
  the login works ... note the latter situation yet kills us since i think
  INT is blocked during all that ;-((

- I had a connection collapse during a POP3 download, and neither was
  there a chance to get access to the 22 yet downloaded mails (after
  five minutes of waiting followed by CNTRL-C), nor did the layer
  recognize this very well (got myriads of `POP3 connection already
  closed.' messages, btw., the thirty-something messages which were not
  yet downloaded caused (after CNTRL-C) this: ETC. ETC.

- Add a value-duplication command, i.e.,
    clone _x header
    unset header
    ...
    clone header _x
    unset _x

- Add a boolify() function, so that things like `localopts' and yorn()
  may be less strict on user input

- Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
  relationship, too)!  EOF conditions in general!

-- NCL / current expand-on-tab: fexpand() should take additional size_t* to
   store the number of the results OR should "return char** array", so that
   individual results can be addressed.
   Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
   line if the result is ambiguous, i.e., we have more than one possible
   expansion.
   However, we would then need something to print the results page-wise,
   in case we have so many of them that they don't fit on the screen.
   ...  Etc. ...

- IMAP: if i `d' a message then this is a local change (in the meanwhile);
  yet, when i `u' it, that will go through the server, needlessly.

- I got an email in base64 that obviously used CRNL line endings, and once
  i've replied the CR where quoted as *control* characters.
  Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
  time, due to how we deal with I/O and Send layer etc).

- edit.c doesn't do NEED_BODY (but IMAP won't work anyway).

- Stuff
  .. s-nail </dev/null should work interactively when STDERR_FILENO is
    a terminal!  (Builtin editor; how do editline and readline work?
    should this be documented?  What does NetBSD Mail do?  Should we NOT
    be interactive??  POSIX says for sh(1) (APPLICATION USAGE): 'sh
    2>FILE' is not interactive, even though it accepts terminal input.)
  . Automatically track message attachments when switching off the
    folder.
    NOTE: 'alternates' tracking happens BEFORE we enter composing, this
    means that an account switch during message composing will NOT cause
    reevaluation of all that very very clumy
    elide/delete_alternates/gexpand/is_myname etc. handling.
    We REALLY need an object based rework of all that.
  . It would be cool if ghosts, shortcuts, alternates could
    (optionally?) be tracked via localopts.
    (Additional entry on xy-local xy somewhere above)
  . The spam* series (spam.c:_spam_action()) should abort if the command
    execution failed, instead of iterating the entire list.  Look into
    that.
  . DESTDIR= should not be taken into account when deciding wether
    a rebuild is necessary (not wrong to give that to Gaetan Bisson).
  . Just like the RFC 3676 link above, it would be nice if it would be
    somehow possible to recognize links in a document; i don't know yet
    how this could be achieved without loosing formatting information (i
    mean, we could enable this and inject terminal colour sequences, but
    one should be able to say 'follow link x', starting an action
    handler, and the 'x' must come from somwhere - simply injecting
    '[NUMBER]' references distorts visual).  Anyway, it's just a filter
    that recognized the usual <SCHEME:/> stuff, and of course we can
    simply have a buffer which records all such occurrences, so that
    user can say '? xy NUMBER', but without the context it soon gets
    hard.
  . TTY layer: the tc*() family may fail with EINTR, which MUST be
    handled; setting also generates SIGTTOU when we're not in foreground
    pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
    resetting terminal attributes!
  . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
    global mbstate_t objects until the send / MIME layer rewrite is done and
    has the carrier.  Use flip states and add aux funs with only update the
    state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
    HANDLED!!
  . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
    cache we have some kind of UID validity check -- couldn't that be
    used to perform some kind of automatic reconnection when we get that
    much-too-frequent connection breaks in IMAP mode??
    Also, and also for POP3, don't let the ALARM based (ugh!  I'm
    starting to dream wet from select(2), almost truly) timer blindly
    tick, but restart it with a full interval when we did regular
    conversation with a server.  Don't forget the SSL timeouts (300
    seconds) and their interaction with normal (user) keepalives.
    Add a global *keepalive*, add *keepalive-USER@HOST*.  (Add and use
    a generic, single function to get the value for either protocol.)
  . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
    mk-conf.sh yet always tests anything, i.e., we could fail due to
    history related stuff even though the user doesn't WANT_HISTORY.
  .. We should in fact convert our NCL history to a shared history
     implementation, and only hook editline(3) and readline(3) so that
     ^R and Cursor-(Up|Down) work as expected everywhere.
     Like that we would have duplicate elimination for readline(3), too.
  .. tty_addhist() should take a struct str.  Anyway, evaluate() should
     enter a history entry if the caller allows so, and it should trim
     also trailing whitespace; also, the expanded command should be
     stored, not the abbreviation, so that 'sst' and 'sstats' will no
     longer produce two separate entries.
  . getprompt() is not multibyte safe in that it should mbrtowc() before
    calling expand_shell_escape() (i.e., only call that if ASCII,
    otherwise pass through if fits as such).
  . Make S/MIME an option separate of SSL/TLS
  . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
  . send.c:_print_part_info(): the filename is truncated to a maximum of
    25 characters, which of course may mess up multibyte encodings!
    We need a multibyte safe clamp function, even if this means that
    an already encoded string is again parsed...  We can take advantage
    of UTF-8 here, however.
    FURTHERMORE: don't go and separate ISO C90 Amend. 1 and wcwidth(3);
    only support wide and multibyte stuff if we have them all.
    Alternatively we could support ONLY UTF-8 locales via ISO C90 and
    implement our own wcwidth(3) IFF it's only the latter is missing.
    Though that sounds crappy.

    v14.7 MUST use only mbrtowc() and have solved all these multibyte
    problems (that i've introduced, mostly, and mostly for new
    features).  It has to last for well over a year!
  . which_protocol(), *newmail* mechanism, displayname, mailname: all of
    this <rude>SHIT</rude> must be rewritten completely and can be
    overcome by an object-based mailbox implementation that carries all
    the necessary state (user given path, expanded realpath(3),
    abbreviated display path, box-protocol, etc.).  Once we have this,
    we may as well also re-introduce automatic detection of compressed
    file-based folders based upon .gz/.bz2/.xz extension.

    If not mentioned somehwere else: struct message should be splitted
    into a tree of objects, with a base class that has as few fields as
    possible; the global *message should be a deque, only accessible via
    iterator; it should store pointers to (the actually used subtype of)
    message structures instead; i.e., for maildir boxes the path is yet
    allocated separately, then it could be part of the message object,
    etc.
    It should contain a ui8_t that tracks the number of contained parts,
    so that the "fits-onto-the-screen" tests are more useful than today;
    i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
  . Given how many temporary files we use, it would make sense to
    support a reusable single temporary file, as in singletmp_take() and
    singletmp_release(), where singletmp_release() would close and thus
    drop the file if it excesses a specific (configurable) size, and the
    mainloop tick would close it (after X (configurable) ticks))
    otherwise.  I guess this would improve performance for searching
    etc. etc.
  . Searching code *could* perform a prepass, joining stuff together,
    dropping useless cases etc.
    But anyway: if there are multiple search expressions, it shouldn't
    be an error if at least one of them matches at least one message.
  . catset(3) is plain shit, and ever was.  Remove IDs from all tr()s,
    use GNU tools for extraction etc., and write a simple helper program
    which converts these files to a serialized hashmap, just like we did
    for the okeys (and *exactly* so); add a config check wether the ({})
    extension is supported and finally use that for some ({static char
    const *tr_res;}) injection optimization, then.  (Think SFSYS)
  . Searching body/text yet includes headers from attachments and
    attachment data.  This is shit.  :)
  . Btw.: (with IMAP) when opening a folder the hook gets executed after
    the flags but before the headers are loaded, but for `newmail' it is
    *after* the headers have been loaded.
  .      /* TODO *batch-exit-on-error*: sourcing and loading MUST BE FLAGS!
          * TODO the current behaviour is suboptimal AT BEST! */
  . There MUST be a way to specify that a single SPECIFIC box has to be
    opened readonly.  only the global -R flag is NOT ENOUGH!
  . The "nifty" unregister_file()->_compress() mechanism that even
    shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
    *records* calls clearerr() on the descriptor before performing it's
    action anyway.  when we really make it even to the I/O rewrite, it
    should be possible to dis-/allow such -- it doesn't make sense to
    add something faulty to whatever was not faulty before!
  . The message from Andy Switala on nail-devel made me think about some
    mechanism that invokes a macro after a message has been sent.
    Unless macros can have args (or do we introduce $*/$@/$1..).
    Even if the codebase will at some future time be stable and really
    reliable, sending a message via multiple channels will never be
    atomic, so that it would make sense for a user to be able to restore
    *the complete message* in a save place if any of the sends failed,
    but to remove it from our temporary place otherwise.  A simple
    version of this would be a matter of five minutes, but since
    mightrecord() may internally (via _compress()) instantiate
    a complete IMAP session and try to send incomplete data etc.,
    and all that may jump, i refrained from doing so.
  . SMTPS never became a standard and :465 was already reassigned
    (thanks, carriers), but if a user says SMTPS and doesn't specify
    a port also then we could simply assume :465 because except NetBSD
    noone has SMTPS in their /etc/services?
    Or at least automatically restart a failed getaddrinfo() in the
    SMPTS case (if EAI_SERVICE)?
    (Ooops - i think this should go to Gianluca Ramunno!)
  . `dp' prints EOF at the end of a thread even if unread messages
    follow
  . [-- #2 : 41/2761, text/plain, 0001-Israel-DST-transitio --]
    If not fit, it should do `...'
    It is not multibyte safe anyway, implement a generic function (or
    two, one that takes an iconv_t) to trim a string into a buffer
  . When doing `~w FILE' and FILE cannot be written to (was a directory)
    then the composed mail is lost completely, it seems we jump to the
    very main loop!
  . `resend' doesn't smime-sign.
  . Really do extend the test already today; test S/MIME
    signing/encryption/decryption with two pairs of identities, instead
    of of one.
  . RFC 5751 describes a message multipart layout that also includes the
    headers in the signature; it would be nice (for completeness sake)
    to be able to support that.
  . The capability to save a message under the name of a recipient is in
    the standard etc., but i've never used it.
    What would be cool, otoh, would be if there would be the possibility
    to register a regular expression, and if just *any* recipient of
    a message matches, store the message in the given folder instead.
    I.e., if i send a message to s-nail-users@ then i most likely want
    to get a copy to the corresponding box, regardless of whoever the
    message was sent To: Cc: or Bcc: else..
  . In my ~xother with *nohold* if at the begin i have many large
    messages i ended up with a truncated *mbox*? what was that?
  . We should support ~/.netrc for account / password storage!
  . Things like colalign(), makeprint(), colour*, as well as
    possibly even cmd1.c:(__hprf|putindent)(), etc. belong into a cui.c,
    display.c or the like, but not into auxlily.c etc. for sure.
    Also writing a range of headers should be done through an
    iterator-thing with setup/finalize init/destroy life cycle, which
    would encapsulate the entire cmd1.c:_print_head() in the single
    iterator setup function!
  . Using -t should still optionally offer an option to enter editing.
    Also we should support command line arguments on top.
    Add a -T flag for that.  Drop -q, let -T mean the same if no header
    fields are given (i.e., header fields are not mandatory as with -t).
    ANYWAY: -t and -q are mutual, enforce that (yet done?)
  . Add manual section for URL and the (*v15-compat*) proto, user and
    password chains, just as done in the s-nail-users mail.
  . mutt list handling (`~') is very powerful
  . Check what happens if an account switch or a network connection is
    done while we are loading the resource files...

vim:set fenc=utf-8:s-ts-mode