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.
20 It all has to be converted to use a m_ prefix and follow the coding
21 style of the mentioned. Note n_(UN)?LIKELY() usage is yet a bit weird,
22 we should not use it for entire conditions but instead repeat its use
23 for each subcondition.
25 - We should have generic ENOMEM conditions, now that we have $!.
26 I.e., test overflow (e.g., nam-a-grp.c, whether an alias _can_ be
27 created / extended), like n_ENOMEM_CHECK(INTTYPE, SIZE1, SIZE2, NULL
28 or message), which returns m_bool (now bool_t).
29 Callers need to be aware of NULL returns and pass through errors,
32 - We need a "void" box that can be jumped to, i.e., a state in which no box
35 -- When a MBOX mailbox is removed while it is opened then changing the
36 folder is not possible. This is an inherent problem of the Berkeley
37 Mail codebase, and we need to have a fully functional intermediate
38 VOID box mechanism plus an object-based mailbox implementation to
41 -- Also, when the folder was modified concurrently we should bail, or,
42 in an interactive session, prompt the user what to do.
44 - IDNA decoding. Needs a complete design change.
45 (Unless wants to brute force decode anything before display, of course.)
47 - If pipes fail for part viewers then at least the usual PART X.Y should be
48 shown, maybe even including some error message.
49 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
50 does not have lynx(1), and i thought i've found a S-nail(1) bug.
52 - It would be nice if it would be possible to define a format string for
53 *quote*, like 'set quote="format=some formats"'.
55 - Line editing should gain possibility of context sensitive tab completion.
57 - Maybe there should be an additional ZOMBIE directive that is served in
58 equal spirit to DEAD, but that could be a valid MBOX... ?
59 What i want is a *real* resend, best if possible from command line.
60 Meaning, also the possibility to postpone a message. In general.
62 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
64 - printhead()/hprf(): support %n newline format (%t tab?).
65 Make it possible to use the *datefield* algorithm for plain From_ derived
66 dates (needs a From_ parser, i.e., strptime()-alike).
67 Once we have that, rename *datefield-markout-older* to
68 *date-markout-older* ??
69 Note that NetBSD's mail(1) has some other nice things.
70 Note also that our code is quite unflexible.
72 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
73 variables (though prefix and appendix or prefix and suffix, but..).
74 Note that our code is quite unflexible.
76 - headerpick: add resend-retain/ignore! (Ralph Corderoy, Norman Shapiro)
77 (Delivered-To thread on nmh. Will be hard to do because of
80 - -r should be the Sender:, which should automatically propagate to
81 From: if possible and/or necessary. It should be possible to suppress
82 -r stuff from From: and Sender:, but fallback to special -r arg as
88 - Improve name extraction rules. And field parsing. There
89 are structured and unstructured fields. There are quoted pairs and
90 comments etc. Rewrite the entire parsing mechanism to comply to RFC
91 5322, and try to merge all those many subparsers around in the codebase,
92 and accordingly. So much duplicated work ...
93 Name parsing has been improved a bit for v13, but it's still broken.
94 yankword(), *extract(), etc.: RFC 5322 says that comments in address
95 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
96 approbiate, even if that actually changes content!!?), and that full
97 name-addr SHOULD be used. Our functions are yet quite silly (i.e.,
98 leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
99 doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
100 (bier6)", that becomes "<a6@b6.de>").
102 (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3)
103 Should eventually become
104 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
105 on the display, or, with IDNA decoding (and thus rather unlikely)
106 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
107 It should NOT become this mutt(1)ism:
108 "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
111 - many uses of whitechar() should be spacechar(), and spacechar() should
112 be blankspacechar(), and blankspacechar() should be dropped. then
113 drop onlywhitechar() again, too. maybe reduce char_class bits then.
115 - In v15.0, when we can address attachments of a message individually,
116 it would be nice to provide even more access, just like nmh(1) does
117 (Johan Commelin: Are s-nail and mh related?).
119 - I never used anything but the *datefield* option, and it would really be
120 nice if the date strings would be parsed off into some 16 byte or what
121 storage when about to producing the summary, so that it would be directly
122 available and there would be no need to reread the mail. Moreover, or
123 even more than that - the m_date field exists and should possibly simply
124 be init, at least in these cases. (P.S.: this doesn't contradict the
125 statement somewhere else in this file that the structure should be
126 slacked; simply use multiple thereof or so)
128 - After I/O layer rework we should optionally be able to read RSS
129 (Atom?) feeds -- Expat should be available almost everywhere and
130 should be able to parse that?
131 Atom is harder because it may support html+.
132 I mean, yeah, it's stupid, but we could fill in header fields with
133 dummies and still use S-nail to look into the separated feeds as if
134 they were mail messages; anyway i would like to save me from using too
135 many tools -- three seems reasonable.
137 -- `sync'hronize commando -- robin@stjerndorff.org (Robin Stjerndorff):
138 Wondering how to update back to my Maildir, moving new read mails
139 in ~/Maildir from new to cur, without exiting the application.
140 Automation available? [And simply re-`[Ff]i' involves a lot of
143 -- Provide sync'ing options -- Jacob Gelbman <gelbman@gmail.com>:
144 If I open two instances of mailx, I then delete a message and then
145 quit in one. Then in the other one I read a message and quit, mailx
146 saves the status of the read message and the fact that a message was
147 deleted, even though it was opened before the other instance deleted
148 it. How is it doing that? [Of course he was using Maildir]
150 - Add TODO notes for those RFCs:
151 RFC 977 -> 3977 - Network News Transfer Protocol
152 RFC 1036 - Standard for USENET Messages
153 RFC 1524 - True support for mailcap files?
154 TODO YES! We really need to replace the pipe-TYPE/SUBTYPE mechanism
155 with something real. When we can work on the parsed MAIL DOM.
156 RFC 1939 - Post Office Protocol v3
157 RFC 2017 - URL External-Body Access-Type
158 RFC 2183 - The Content-Disposition Header
159 RFC 2369 - The Use of URLs as Meta-Syntax for Core Mail List Commands
160 and their Transport through Message Header Fields
161 (RFC 6068 - The 'mailto' URL scheme)
162 RFC 2384,1738 - I.e., Much better URL support
163 RFC 2387 - multipart/related -- yet handled like /alternative
164 RFC 2392 - Content-ID and Message-ID Uniform Resource Locators
165 RFC 2405 - The format of MIME message bodies.
166 RFC 2406 - Common multimedia types.
167 RFC 2407 - Encoding of non-ASCII text in message headers.
168 RFC 2449 - POP3 Extensions (including SASL)
169 RFC 2595 - TLS for POP3 (among others)
170 RFC 2980 - Common NNTP Extensions
171 RFC 3156 - MIME Security with OpenPGP
172 RFC 3207 - SMTP over TLS
174 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery
175 Status Notifications (DSNs),
176 An Extensible Message Format for Delivery Status Notifications
177 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
178 text (format=flowed). (Martin Neitzel)
179 rfc4315.txt Internet Message Access Protocol (IMAP) - UIDPLUS extension
180 RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
182 RFC 4551 IMAP Extension for Conditional STORE
183 RFC 4880 - OpenPGP Message Format
184 RFC 4954 - SMTP Authentication
185 rfc4959.txt IMAP Extension for Simple Authentication and Security
186 Layer (SASL) Initial Client Response
187 rfc4978.txt The IMAP COMPRESS Extension
188 rfc5161.txt The IMAP ENABLE Extension
189 rfc5198.txt Unicode Format for Network Interchange
190 RFC 5246 - Transport Layer Security (TLS)
191 RFC 5321 - Simple Mail Transfer Protocol.
192 RFC 5322 - The basic format of email messages.
193 RFC 5598 - Internet Mail Architecture
194 RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
195 TODO NOTE that our S/MIME support is extremely weak regarding
196 TODO understanding, we should not rely on OpenSSL but instead
197 TODO handle it ourselfs; the RFC says:
198 S/MIME is used to secure MIME entities. A MIME entity can be a sub-
199 part, sub-parts of a message, or the whole message with all its sub-
200 parts. A MIME entity that is the whole message includes only the
201 MIME message headers and MIME body, and does not include the RFC-822
202 header. Note that S/MIME can also be used to secure MIME entities
203 used in applications other than Internet mail. If protection of the
204 RFC-822 header is required, the use of the message/rfc822 media type
205 is explained later in this section.
206 RFC 6125 - Representation and Verification of Domain-Based Application
207 Service Identity within Internet Public Key Infrastructure Using
208 X.509 (PKIX) Certificates in the Context of Transport Layer Security
210 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
211 RFC 6409 - Message Submission for Mail
212 rfc6530.txt Overview and Framework for Internationalized Email
213 rfc6531.txt SMTP Extension for Internationalized Email
214 rfc6532.txt Internationalized Email Headers
215 rfc6854.txt Update to Internet Message Format to Allow Group Syntax in
216 the "From:" and "Sender:" Header Fields
217 rfc6855.txt IMAP Support for UTF-8
218 rfc6856.txt Post Office Protocol Version 3 (POP3) Support for UTF-8
219 rfc6857.txt Post-Delivery Message Downgrading for Internationalized
221 rfc6858.txt Simplified POP and IMAP Downgrading for Internationalized Email
222 RFC 7162 IMAP CONDSTORE & QRESYNC
223 RFC 8058 Signaling One-Click Functionality for List Email Headers
225 draft-ietf-uta-email-tls-certs-01.txt
226 SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-15
227 draft-melnikov-smime-header-signing
228 Considerations for protecting Email header with S/MIME
229 Read https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07.
230 Can we implement OCSP (see RFC 6066; -> RFC 6960)????
232 - This is how the codebase has to be reworked in respect to signals and
235 1. We introduce some environment/carrier structs: struct eval_ctx,
236 struct cmd_ctx, (struct send_ctx). All of these form lists.
237 eval_ctx gets a new instance every time evaluate() is entered; for
238 the interactive mode, commands() instantiates an outermost eval_ctx
239 that "cannot be left".
241 cmd_ctx knows about the eval_ctx in which it is was created; it is
242 created for each command that has an entry in cmd_tab and is passed
243 as the new argument of these kind of functions.
244 (send_ctx is the carrier for the MIME and send layer rewrite.)
245 2. cmd_tab handling becomes more intelligent: add bit fields so that
246 for some arguments (i.e., the first two or three) automatic
247 normalization can be specified, like whitespace trimming, like
248 automatic expansion of variables etc. For getrawlist.
249 It knows about the short synopsis and longer help of its program.
251 - and: commands that work only in interactive mode, and are
252 _silently_ ignored otherwise (no error).
253 I.e., commands which work on only with true user interaction
254 should not need to take care no more, but simply assume that
255 there will be true user interaction. And like that.
257 E.g., customhdr header field is always to be WS trimmed, just the
258 same as the body. shortcut at least should have trimmed name, etc.
259 To do that right, properly parse from left to right, take care
260 about backslash escaping, and (optionally) expand shell variables
261 and backtick substituations.
263 The cmd_ctx needs to carry around the cmd_tab structure so that the
264 commands can themselves print the synopsis in case of errors --
265 alternatively we need a return bit which should cause the command
266 callee to emit the synopsis as an error message, whatever is best.
267 Some (hopefully) duplicate occurrances of such strings can vanish.
268 2.1 We have some commands which offer "show" subcommands.
269 Those should only work in interactive mode OR SO.
270 This could be done with a flag, too. (Driven from the lexer.)
271 X. Offer a central "`[un]onevent' EVENT MACRO [conditions]" register.
272 Change all hooks to use that one, optimize the case where a single
273 macro is registered for a single event but with different
276 E.g., "on_interactive_mode_enter" could then be hooked to call
277 `bind' and set `colour's, for example. In conjunction with 2.
278 above those commands could simply be (silent, successful) no-ops
279 before we reach that state (and again after
280 on_interactive_mode_leave is processed).
282 X.x We should make the message accessible at least a bit on macro level.
283 I.e., so that message specification checks can be applied on the
285 if `message match-spec '@~t@bank.com'`
286 set smime-sign customhdr='X-BlahBlahBlah:Banks are monsters'
288 where `message' (or so) would refer to the currently active
289 message (in compose mode) or the "dot" (otherwise).
290 `message' would gain some keywords. Something like that.
291 `~^' for compose mode is a starter, but we need such access from
293 8. The line buffer used in evaluate() that is passed through to
294 commands (thus: in cmd_ctx, then) needs to become `const'.
295 (I tried to do so in the past, but some commands write into it,
296 thus i stopped and iirc even added some changes on my own which
297 take favour of reusing that buffer.)
298 + Macro execution then no longer needs to clone the macro content
299 lines before executing then.
300 + The command context also takes preparsed command array if so
301 specified in cmd_tab, and entries are cleaned up (see 2.)
302 9. We should unite all the un*() commands with their non-un*
303 versions, if they have one. They may take a different argument
304 list etc., but only one entry in the command table for such.
305 - The POSIX standard command abbreviations must remain, so maybe
306 outsource those in a hashtable or whatever that is checked first,
307 but detach command table order from that anyway.
308 - Offer a(n optional, and on/off switchable) Damerau-Levenshtein
309 mode for command completion;
310 10. We MUST switch the entire codebase to use SysV signal handling, don't
311 do the BSDish SA_RESTART, which is why we still suffer the way we
312 do and need jumps. I can't dig BSD signal handling, and never ever
313 did so myself until i got here.
314 20. The attachment charset selection loop can then be rewritten to
315 check whether an ^C occurred and treat that as end-of-loop
316 condition. In v14.6.3 this was introduced, but it should act
317 differently depending on whether the interrupt occurred during
318 character set selection or attachment filename input.
319 Also in respect whether the interrupt is "propagated" or not.
320 It's ugly, and documented accordingly.
321 30. Mail protocols and mail messages are accessed through a "VFS".
322 URL should then support file:// and maildir:// etc. Update manual!
324 . It should be considered to drop many variables in favour of
325 ?SEARCH usage for keys, or key=value pairs, e.g.
326 smtp://exam.ple?starttls=yes;smtp-hostname=;
327 etc. USER@HOST is neat, but that is possibly preferable?
328 We could then also extend *mta* and drop *smtp* as such, e.g.,
329 mta=smtp://dSDAS, mta=builtin://XZ, mta=bltin://XZ.
330 Question: what is with smtp-hostname and such??
331 31. Flag updates of individual messages must find their way through to
333 32. Use deque (on partial views).
334 34. We need a new abstraction: `vie[ws]'. I.e, viewset, viewclear,
335 view(show|look)? We will have (possibly readonly) boxes, a summary
336 cache file, which is created when a mailbox is read in, and all
337 that crap that we currently have (setptr(), setmsize(), etc.!) must
338 vanish. Instead there is another, in-memory abstraction, the view.
339 Some views are built-in and are somehow selectable (the "all" view,
340 for example, and the "new" view).
341 It is possible to make a view persistent by giving it a name, e.g.,
342 'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
343 or something must be capable to tag the last a.k.a current).
344 Switching to a named view would thus look over the entire current
345 view (!) for all messages that comply to the message-spec of the
346 view, then create a sorted/threaded display of that subset and
347 create a new anonymous "result" view. It must be possible to
348 specify that a view is to be applied to the entire mailbox instead
349 of the current view, via a simple easy understandable syntax.
352 We won't extend macros that much because it would require much too
353 much logic for no purpose, instead we'll (hopefully) add some
354 scriptable abstraction, with an optional built-in Lua binding.
355 E.g., it would be too complicated to create a language to access
356 individual message parts (headers etc.), add error handling etc.
357 Better to make it all directly accessible via language binding, and
358 offer commands which relinquish execution to such a binding, maybe
359 even with some arguments, as in "? lua ARG" - it should be possible
360 that ARG is a msgset, then.
361 On the other hand, ~^ text-protocol stuff isn't that bad, and if
362 a text-protocol command mode could be added, that would be cool.
363 Even things like 'create temporary file', write data until EOT in
364 descriptor / temporary file / etc. and such!
366 But what macros should be able to do is iterating over such
367 a msgset / view, as in
368 msgset create NAME :SPEC:
369 msgset add NAME :SPEC:
372 normal-cmd SOMEHOW-REFER-TO-ITER
373 if SOMEHOW-ACCESS-LAST-STATUS
377 msgset cmd NAME normal-cmd
380 in which case NAME should simply be treated as a SPEC, likely that
381 this requires a new trigger, though, e.g. {NAME}, [NAME] or !NAME...
382 I.e., the new namelist (likely a deque) should contain MsgRef
383 objects which point to a Message and a Mailbox (for cross-mailbox
384 msgset's and without the need for a Message to store a pointer to
385 the owning mailbox? Or make MsgRef a superclass that may have
386 a subclass which offers such cross-refs).
388 50. Support SASL, unite all GSS-API etc. under an abstraction!
389 Maybe even drop direct GSS-API and support only through SASL.
390 That is, we can very well provide our own little SASL-client
391 abstraction with what we have already by simply defining some
392 "readline" abstraction plus struct ccred for use by the
393 authentication layer: the protocols must set it up by passing in
394 a line of authentication mechanisms and a callback mechanism.
395 Possibly the user should be able to permit or forbid automatic
396 selection of GSS-API (to avoid useless round-trips) etc. etc.
397 80. The MIME rewrite: mime_parser <-> mime "DOM" analyzer <->
398 selectively create filter chains per part and do XY.
400 This also affects sending, and it will allow us to dig MIME
401 (multipart) mail for -t/-m _correctly_. Also in sofar as we can
402 hook a content-decoder before diving into the MIME structure, and
403 with a DOM, we can re-encode such things properly as we (re)send
404 such mails. All this is wrong at the time of this writing!
405 We still need to special treat things like, e.g., RFC 2046, 5.2.1.
406 But on top of we-can, as opposed to the opposite.
408 (Brezn Stangl, brezn DOT stangl AT yandex DOT com)
409 99. Now i'm dreaming some more: with the new object-based approach
410 multiple mailboxes could be in an open state. And it should be
411 possible to do so for the user (`file' and `folder' are required to
412 quit the current mailbox [first -- this not yet]), which is why we
413 either need new trigger characters or new commands.
414 The absolute sensation would be joinable operations over multiple
415 open mailboxes, e.g., views over multiple such!
416 100. If i say `p 3 2 1' then i mean `3 2 1' not `1 2 3'.
418 - The thread sort doesn't get
427 The current sort fails to recognize that F and the thread starting at
428 B are related, which results in a mess.
429 Tests: 41.bad-thread, 58.bad-thread ..
431 -- Being able to sort the outermost level of threads was a suggestion
432 of Rudolf Sykora, especially being able to sort the outermost level
433 according to the date of the newest message in a thread.
435 - Drop **use-starttls* in favour of something better: support 'auto',
436 'no' and 'yes' and act accordingly. For the former be smart enough on
437 the protocol side. (RFC 3207 describes man-in-the-middle attacks due
438 to 'auto' TLS, so explicit 'yes' should be favoured).
440 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
441 deal with IPv6 addresses (as in '[ADDR]:PORT'). Pimp url_parse().
444 - I had a connection collapse during a POP3 download, and neither was
445 there a chance to get access to the 22 yet downloaded mails (after
446 five minutes of waiting followed by CNTRL-C), nor did the layer
447 recognize this very well (got myriads of `POP3 connection already
448 closed.' messages, btw., the thirty-something messages which were not
449 yet downloaded caused (after CNTRL-C) this: ETC. ETC.
451 - I got an email in base64 that obviously used CRNL line endings, and once
452 i've replied the CR where quoted as *control* characters.
453 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
454 time, due to how we deal with I/O and Send layer etc).
456 - edit.c doesn't do NEED_BODY (but IMAP won't work anyway).
459 .. s-nail </dev/null should work interactively when STDERR_FILENO is
460 a terminal! (Built-in editor; how do editline and readline work?
461 should this be documented? What does NetBSD Mail do? Should we NOT
462 be interactive?? POSIX says for sh(1) (APPLICATION USAGE): 'sh
463 2>FILE' is not interactive, even though it accepts terminal input.)
464 . Just like the RFC 3676 link above, it would be nice if it would be
465 somehow possible to recognize links in a document; i don't know yet
466 how this could be achieved without losing formatting information (i
467 mean, we could enable this and inject terminal colour sequences, but
468 one should be able to say 'follow link x', starting an action
469 handler, and the 'x' must come from somwhere - simply injecting
470 '[NUMBER]' references distorts visual). Anyway, it's just a filter
471 that recognized the usual <SCHEME:/> stuff, and of course we can
472 simply have a buffer which records all such occurrences, so that
473 user can say '? xy NUMBER', but without the context it soon gets
475 . TTY layer: the tc*() family may fail with EINTR, which MUST be
476 handled; setting also generates SIGTTOU when we're not in foreground
477 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
478 resetting terminal attributes!
479 .. TTY "I guess it would be much better to create our own session via
480 setpgid(2) and then tcsetpgrp(3) any processes we run synchronously,
481 and properly deal with SIGTTOU, but it always has been like that and
482 i won't do that before other things have been changed.
483 .. NOTE: TTY: place (at least n_child_run()) childs which go over
484 terminal into own group.
485 Introduce global "terminal state" manager which tracks who
486 currently owns the terminal, so that we can gracefully switch it
487 on/off, check in main loop whether restore is necessary.
488 It that can deal with multiple "windows" then we could have open
489 multiple of those, i.e., multiple PAGER instances, and non-PAGER
490 instances (fflush() if there is FILE before switch off).
492 TTY thus: "needsterminal" could be driven gracefully EVEN IF
493 a PAGER is open because the current user action is "print*", since
494 we KNOW that there is a PAGER and can temporarily lay it down to
495 sleep, fflush()ing/adjusting as necessary, and wake it up again
496 afterwards (or, with some work, gracefully shut it down if ^C ^C).
497 This is of course also true for user questions ("really display
498 part XY?", "need decryption password:", etc.!!!)!!
499 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
500 global mbstate_t objects until the send / MIME layer rewrite is done and
501 has the carrier. Use flip states and add aux funs with only update the
502 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
504 P.S.: the standards do not allow that well at all.
505 Since we work so much with *ttycharset* we would need
506 a setlocale_from_charset(), but which does not exist (except
507 implicitly for UTF-8 locales). But we need char classification!
508 This task up to S-CText.
509 . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
510 Maybe our passed carrier should pass desired output newline (as
511 opposed to data-embedded newlines)
512 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
513 this <rude>SHIT</rude> must vanish and be replaced by a URL, and
514 a nice "VFS" mailbox object that carries all necessary state so that
515 one can work with it.
517 If not mentioned somewhere else: struct message should be splitted
518 into a tree of objects, with a base class that has as few fields as
519 possible; the global *message should be a deque, only accessible via
520 iterator; it should store pointers to (the actually used subtype of)
521 message structures instead; i.e., for maildir boxes the path is yet
522 allocated separately, then it could be part of the message object,
524 It should contain a ui8_t that tracks the number of contained parts,
525 so that the "fits-onto-the-screen" tests are more useful than today;
526 i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
527 . Given how many temporary files we use, it would make sense to
528 support a reusable single temporary file, as in singletmp_take() and
529 singletmp_release(), where singletmp_release() would close and thus
530 drop the file if it excesses a specific (configurable) size, and the
531 mainloop tick would close it (after X (configurable) unused ticks))
532 otherwise. I guess this would improve performance for searching
535 use GNU tools for extraction etc., and write a simple helper program
536 which converts these files to a serialized hashmap, just like we did
537 for the okeys (and *exactly* so); add a config check whether the ({})
538 extension is supported and finally use that for some ({static char
539 const *tr_res;}) injection optimization, then. (Think SFSYS)
540 . Searching body/text yet includes headers from attachments and
541 attachment data. This is shit. :)
542 . The "nifty" unregister_file()->_compress() mechanism that even
543 shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
544 *records* calls clearerr() on the descriptor before performing it's
545 action anyway. when we really make it even to the I/O rewrite, it
546 should be possible to dis-/allow such -- it doesn't make sense to
547 add something faulty to whatever was not faulty before!
548 . `dp' prints EOF at the end of a thread even if unread messages
550 . `resend' doesn't smime-sign.
551 . Really do extend the test already today; test S/MIME
552 signing/encryption/decryption with two pairs of identities, instead
554 . RFC 5751 describes a message multipart layout that also includes the
555 headers in the signature; it would be nice (for completeness sake)
556 to be able to support that. Note shutup@ietf.org.
557 . The capability to save a message under the name of a recipient is in
558 the standard etc., but i've never used it.
559 What would be cool, otoh, would be if there would be the possibility
560 to register a regular expression, and if just *any* recipient of
561 a message matches, store the message in the given folder instead.
562 I.e., if i send a message to s-nail-users@ then i most likely want
563 to get a copy to the corresponding box, regardless of whoever the
564 message was sent To: Cc: or Bcc: else..
565 . mutt list handling (`~') is very powerful
566 . We have some use of *at() functions, especially anything which
567 temporarily switches cwd.
568 . *newmail* is terrible. At some later time we need to do somethings
569 with timeouts etc. (for MBOX and Maildir it's not that bad, but for
570 anything over the network, yet the mentioned may come in over NFS).
571 Remove it until we have something better?
572 . The RFC 8098 *disposition-notification-send* mechanism is yet not
573 truly conforming (and works with *from*). Also, this is only the
574 sender side, there should be support for creating the MDN response.
575 (Maybe ternary option: off (default),
576 create-when-unread-flag-goes-away, ditto-but-also-strip-header)
577 .. Also, there is DSN as a SMTP extension, see the RFCs 3461, 346 (as
578 above) and 6522 (Wikipedia).
579 . The var_* series should return "const char*" not "char*".
580 This should already work today because otherwise we would get SEGV
582 .. While here: rename enum okeys to enum internal_variables, and the
583 ok_*() series to iv_(). And see below for env_*() series.
584 . fexpand() the 2nd: it should return structure because we need to
585 check for FEDIT_SYSBOX, which currently only checks whether the first
586 character of a file name is '%', not whether it is '%', '%:FILEPATH'
587 or '%VALIDUSER', because that is impossible to do!
588 . On the long run in-memory password storage should be zeroed after
589 use, possibly even encoded *during* use. After v15.
590 . We need a `spamcheck' command that is like `spamrate' but updates
591 the mail in-place, i.e., with the headers that the spam engine adds.
592 . __narrow_suffix() is wrong (for stateful encodings that we
593 don't support yet) and should inject a reset sequence if it shortens
595 . When a user edits a specific header, it should no longer be
596 modified. (Do not loose knowledge that collect() edited it.)
597 . Regular expression list resorting is no good; the user should be
598 able to specify a match order weight, as in:
599 mlist 10 a@b.org 8 c@d.org .*@else@org 0 almost@never.com
600 So: optional digit 0-10, where 0-4 are never relinked and always
601 placed at the tail, 6-10 are never relinked and always placed at
602 head (all in decreasing order, head to tail), and 5 is the implicit
603 value, placed in between and automatically resorted just as is the
604 sole algorithm we currently have.
605 .. And maybe we should have an event mechanism with one-shot etc..
606 Then install a resorter function when we actually have lookups and
607 one-shot sort the entire thing once (when the loop ticks).
608 Instead of busy resorting, that is.
609 . The new internal ~/$ expansion mechanism should get support
610 for POSIX parameter expansions ${[:]-} and ${[:]+} (and ${[:]?}).
611 There is no real way to get the functionality otherwise...
612 . Make S/MIME an option separate of SSL/TLS, i.e., optional.
613 . With very long input Heirloom mailx(1) / S-nail(1) can produce
614 encoded-words (RFC 2047) with incomplete multibyte sequences (i.e.,
615 non self-contained encoded-words).
616 . Group addresses, especially the undisclosed recipients but also
617 "Bla": addresses; are missing.
618 . Cleanup: mx_ is anything public / external,
619 mx__ is public/e but not really, FILENAME/ABBREV_symbol are statics,
620 FILENAME/ABBREV__symbol are helpers of a single other static
621 (function group) (-> colour.c, lex_input.c: done).
622 . Per-folder (S/MIME) en- and decryption key (Tarqi Kazan): if a xy
623 variable is set (that points to a key) add a transparent en- and
624 decryption layer on top of any per-message operation (for boxes for
625 which the variable is set).
626 . For v15.0: remember private thread with Tarqi Kazan (2015-05) and
627 try to improve situation with *record*, so that only messages enter
628 it which have really been sent. If we support postponing and have
629 a multi-process layout and add an intermediate *record-queue* we
630 may be able to improve the situation.
631 . [Dd]ecrypt should transport decryption errors, not silently be like
632 copy and copy undecrypted content, because this is what it's for?
633 ..We need atomic operations with rollback support in order to make
634 this happen, but i think maybe file truncation (decryption always
635 appends?) is enough provided that files are locked?
636 WE NEED ATOMIC OPERATION SUPPORT for quite some operations.
637 Man, are we far from that.
638 . `pipe' is total shit regarding MIME. We need some defined and
639 documented method to configure which parts are displayed and/or how
640 they are visually separated.
641 . The new n_err() facility is nice, but we need n_msg() too, maybe
642 more. Maybe à la Log:: and macro wrappers with priority unrolled,
643 then add user-settable treshold, too. Btw. C99 adds vararg macros.
644 .. We must handle embedded newlines properly
645 .. In PARTICULAR we MUST NOT use stdout when in batch mode:
646 ssh X "echo 'move * |cat' | s-nail -#f %" >> download
647 should do the right thing, but can't like that due to unwanted
648 noise in the stdout output! Best would be if it would be
649 possible to explicitly define a file/dev to be used, but falling
650 back to stderr in batch mode otherwise. (think S-Web42)
651 . Exit status handling is sick.
652 . *mime-allow-text-controls* is a no-brainer: instead we should
653 introduce something that allows us to switch and detect UTF-16 once
654 we run into the problematic situation, then start all over in an
655 Unicode mode? I.e.: continue to force the user to set such
656 a switch, but do it in a sensible fashion, because the UTF-16 data
657 stream may nonetheless contain control characters??
660 . We can "steal" features from msmtp(1) that make sense: SOCKS support
661 (primitive) and /etc/aliases ($mta_alias_file). At least postfix(1)
662 supports file and pipe addressees in the latter... It also
663 supports include files via :include:/filename but which i think
664 should be supported in a second step. Ditto caching (timestamp
665 check and a mechanism to support/disable caching.)
669 . smime_verify(): only dump the multipart that is signed into the file for
670 verification purposes. DOCUMENT that only the FIRST such part is verified.
671 Ditto, we don't decrypt but on toplevel. Sic.
673 . convert iconv so that it always "places the reset sequence" i.e.
674 finalizes the string properly. we don't do this at all right now!
676 . -:, *mimetypes-load-control*, ?, should honour the given load order; as
677 appropriate, add a "b" for built-in!
678 It happened to me that i searched for at least 30 minutes for a bug
679 that resulted in text/plain not text/x-diff only to find out that this
680 was because of ArchLinux's /etc/mime.types!
682 . getapproval() should support a TRUM1 return, meaning "cancel",
683 to be understood as appropriate.
685 . `mbox' _can_ be made usable anywhere with yet another PS_MBOX global
686 bypass! ditto touch,save,Save
688 . with *mime-alternative-favour-rich* it is possibly time to support GMAIL
689 style quotes, as well as class="quote" and such.
691 . We should be much smarter regarding when we allow a PAGER
692 etc. to be used, which is supposed to be a possibly useful thing in
693 $ s-nail -Scrt=0 >LOG 2>&1
695 . when doing Lreply we may ask for Reply-To:, but strip out the address
696 actively even if user said yes to the question. That should not
697 happen? It somehow matches the documentation however. unsure.
699 . if -t is used and the file includes Mail-Followup-To:, then we should
700 NOT add to it, OR we need to offer a way to get there!
702 . stale dotlock files should be removed - postfix has
703 a stale_lock_time=500s variable to configure that