3 Rename S-nail to S-mailx in v15.0, change things i've messed with
4 a single, massively backward incompatible change.
6 In general the code is in a pretty bad shape due to the signal handling.
7 I should have sat back in 2012/13 and consider what i am doing.
8 My fault. If i would, we would have a blocked signal mask anywhere in
9 this software except in a few cases where it is necessary and/or
10 possible to deal with signals, and possibly we would not even have to
11 consider to switch the entire codebase to (the much superior, and the
12 only sane approach) SysV signal handling, without SA_RESTART.
14 But a few things are already pretty good, except for normal iterations
15 and a review once we have a better signal handling, and can be taken
18 - We should have generic ENOMEM conditions, now that we have $!.
19 I.e., test overflow (e.g., nam-a-grp.c, whether an alias _can_ be
20 created / extended), like n_ENOMEM_CHECK(INTTYPE, SIZE1, SIZE2, NULL
21 or message), which returns m_bool (now bool_t).
22 Callers need to be aware of NULL returns and pass through errors,
25 - We need a "void" box that can be jumped to, i.e., a state in which no box
28 -- When a MBOX mailbox is removed while it is opened then changing the
29 folder is not possible. This is an inherent problem of the Berkeley
30 Mail codebase, and we need to have a fully functional intermediate
31 VOID box mechanism plus an object-based mailbox implementation to
34 -- Also, when the folder was modified concurrently we should bail, or,
35 in an interactive session, prompt the user what to do.
37 - IDNA decoding. Needs a complete design change.
38 (Unless wants to brute force decode anything before display, of course.)
40 - If pipes fail for part viewers then at least the usual PART X.Y should be
41 shown, maybe even including some error message.
42 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
43 does not have lynx(1), and i thought i've found a S-nail(1) bug.
45 - Line editing should gain possibility of context sensitive tab completion.
47 - Maybe there should be an additional ZOMBIE directive that is served in
48 equal spirit to DEAD, but that could be a valid MBOX... ?
49 What i want is a *real* resend, best if possible from command line.
50 Meaning, also the possibility to postpone a message. In general.
52 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
54 - printhead()/hprf(): support %n newline format (%t tab?).
55 Make it possible to use the *datefield* algorithm for plain From_ derived
56 dates (needs a From_ parser, i.e., strptime()-alike).
57 Once we have that, rename *datefield-markout-older* to
58 *date-markout-older* ??
59 Note that NetBSD's mail(1) has some other nice things.
60 Note also that our code is quite unflexible.
62 - headerpick: add resend-retain/ignore! (Ralph Corderoy, Norman Shapiro)
63 (Delivered-To thread on nmh. Will be hard to do because of
66 - -r should be the Sender:, which should automatically propagate to
67 From: if possible and/or necessary. It should be possible to suppress
68 -r stuff from From: and Sender:, but fallback to special -r arg as
74 - Improve name extraction rules. And field parsing. There
75 are structured and unstructured fields. There are quoted pairs and
76 comments etc. Rewrite the entire parsing mechanism to comply to RFC
77 5322, and try to merge all those many subparsers around in the codebase,
78 and accordingly. So much duplicated work ...
79 Name parsing improved a bit for v13 and v14.9, but it's still broken.
80 yankword(), *extract(), etc.: RFC 5322 says that comments in address
81 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
82 approbiate, even if that actually changes content!!?), and that full
83 name-addr SHOULD be used.
85 - After I/O layer rework we should optionally be able to read RSS
86 (Atom?) feeds -- Expat should be available almost everywhere and
87 should be able to parse that?
88 Atom is harder because it may support html+.
89 I mean, yeah, it's stupid, but we could fill in header fields with
90 dummies and still use S-nail to look into the separated feeds as if
91 they were mail messages; anyway i would like to save me from using too
92 many tools -- three seems reasonable.
94 - `sync'hronize commando -- robin@stjerndorff.org (Robin Stjerndorff):
95 Wondering how to update back to my Maildir, moving new read mails
96 in ~/Maildir from new to cur, without exiting the application.
97 Automation available? [And simply re-`[Ff]i' involves a lot of
100 -- Provide sync'ing options -- Jacob Gelbman <gelbman@gmail.com>:
101 If I open two instances of mailx, I then delete a message and then
102 quit in one. Then in the other one I read a message and quit, mailx
103 saves the status of the read message and the fact that a message was
104 deleted, even though it was opened before the other instance deleted
105 it. How is it doing that? [Of course he was using Maildir]
107 - Add TODO notes for those RFCs:
108 RFC 977 -> 3977 - Network News Transfer Protocol
109 RFC 1036 - Standard for USENET Messages
110 RFC 1939 - Post Office Protocol v3
111 RFC 2017 - URL External-Body Access-Type
112 RFC 2183 - The Content-Disposition Header
113 RFC 2369 - The Use of URLs as Meta-Syntax for Core Mail List Commands
114 and their Transport through Message Header Fields
115 (RFC 6068 - The 'mailto' URL scheme)
116 RFC 2384,1738 - I.e., Much better URL support
117 RFC 2387 - multipart/related -- yet handled like /alternative
118 RFC 2392 - Content-ID and Message-ID Uniform Resource Locators
119 RFC 2405 - The format of MIME message bodies.
120 RFC 2406 - Common multimedia types.
121 RFC 2407 - Encoding of non-ASCII text in message headers.
122 RFC 2449 - POP3 Extensions (including SASL)
123 RFC 2595 - TLS for POP3 (among others)
124 RFC 2980 - Common NNTP Extensions
125 RFC 3156 - MIME Security with OpenPGP
126 RFC 3207 - SMTP over TLS
128 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery
129 Status Notifications (DSNs),
130 An Extensible Message Format for Delivery Status Notifications
131 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
132 text (format=flowed). (Martin Neitzel)
133 rfc4315.txt Internet Message Access Protocol (IMAP) - UIDPLUS extension
134 RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
136 RFC 4551 IMAP Extension for Conditional STORE
137 RFC 4880 - OpenPGP Message Format
138 RFC 4954 - SMTP Authentication
139 rfc4959.txt IMAP Extension for Simple Authentication and Security
140 Layer (SASL) Initial Client Response
141 rfc4978.txt The IMAP COMPRESS Extension
142 rfc5161.txt The IMAP ENABLE Extension
143 rfc5198.txt Unicode Format for Network Interchange
144 RFC 5246 - Transport Layer Security (TLS)
145 RFC 5321 - Simple Mail Transfer Protocol.
146 RFC 5322 - The basic format of email messages.
147 RFC 5598 - Internet Mail Architecture
148 RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
149 TODO NOTE that our S/MIME support is extremely weak regarding
150 TODO understanding, we should not rely on OpenSSL but instead
151 TODO handle it ourselfs; the RFC says:
152 S/MIME is used to secure MIME entities. A MIME entity can be a sub-
153 part, sub-parts of a message, or the whole message with all its sub-
154 parts. A MIME entity that is the whole message includes only the
155 MIME message headers and MIME body, and does not include the RFC-822
156 header. Note that S/MIME can also be used to secure MIME entities
157 used in applications other than Internet mail. If protection of the
158 RFC-822 header is required, the use of the message/rfc822 media type
159 is explained later in this section.
160 RFC 6125 - Representation and Verification of Domain-Based Application
161 Service Identity within Internet Public Key Infrastructure Using
162 X.509 (PKIX) Certificates in the Context of Transport Layer Security
164 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
165 RFC 6409 - Message Submission for Mail
166 rfc6530.txt Overview and Framework for Internationalized Email
167 rfc6531.txt SMTP Extension for Internationalized Email
168 rfc6532.txt Internationalized Email Headers
169 rfc6854.txt Update to Internet Message Format to Allow Group Syntax in
170 the "From:" and "Sender:" Header Fields
171 rfc6855.txt IMAP Support for UTF-8
172 rfc6856.txt Post Office Protocol Version 3 (POP3) Support for UTF-8
173 rfc6857.txt Post-Delivery Message Downgrading for Internationalized
175 rfc6858.txt Simplified POP and IMAP Downgrading for Internationalized Email
176 RFC 7162 IMAP CONDSTORE & QRESYNC
177 RFC 8058 Signaling One-Click Functionality for List Email Headers
178 RFC 8460 on SMTP TLS Reporting
179 RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)
180 RFC 8474 IMAP Extension for Object Identifiers
181 RFC 8484 on DNS Queries over HTTPS (DoH)
182 RFC 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME)
183 Version 4.0 Certificate Handling
184 RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
185 4.0 Message Specification
186 RFC 8601 Message Header Field for Indicating Message Authentication Status
187 RFC 8616 Email Authentication for Internationalized Mail
188 RFC 8621 The JSON Meta Application Protocol (JMAP) for Mail
189 RFC 8689 SMTP Require TLS Option
191 draft-ietf-uta-email-tls-certs-01.txt
192 SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-15
193 draft-melnikov-smime-header-signing
194 Considerations for protecting Email header with S/MIME
196 Read https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07.
197 Can we implement OCSP (see RFC 6066; -> RFC 6960)????
199 - This is how the codebase has to be reworked in respect to signals and
202 1. We introduce some environment/carrier structs: struct eval_ctx,
203 struct cmd_ctx, (struct send_ctx). All of these form lists.
204 eval_ctx gets a new instance every time evaluate() is entered; for
205 the interactive mode, commands() instantiates an outermost eval_ctx
206 that "cannot be left".
208 cmd_ctx knows about the eval_ctx in which it is was created; it is
209 created for each command that has an entry in cmd_tab and is passed
210 as the new argument of these kind of functions.
211 (send_ctx is the carrier for the MIME and send layer rewrite.)
212 2. cmd_tab handling becomes more intelligent: it should be able to
213 perform argument checks of subcommands, e.g., should learn about
214 subcommands, and their very own argument types / number / etc.
216 The cmd_ctx needs to carry around the cmd_tab structure so that the
217 commands can themselves print the synopsis in case of errors --
218 alternatively we need a return bit which should cause the command
219 callee to emit the synopsis as an error message, whatever is best.
220 Some (hopefully) duplicate occurrences of such strings can vanish.
221 2.1 We have some commands which offer "show" subcommands.
222 Those should only work in interactive mode OR SO.
223 This could be done with a flag, too. (Driven from the lexer.)
224 X. Offer a central "`[un]onevent' EVENT MACRO [conditions]" register.
225 Change all hooks to use that one, optimize the case where a single
226 macro is registered for a single event but with different
229 E.g., "on_interactive_mode_enter" could then be hooked to call
230 `bind' and set `colour's, for example. In conjunction with 2.
231 above those commands could simply be (silent, successful) no-ops
232 before we reach that state (and again after
233 on_interactive_mode_leave is processed).
235 8. The line buffer used in evaluate() that is passed through to
236 commands (thus: in cmd_ctx, then) needs to become `const'.
237 (I tried to do so in the past, but some commands write into it,
238 thus i stopped and iirc even added some changes on my own which
239 take favour of reusing that buffer.)
240 + Macro execution then no longer needs to clone the macro content
241 lines before executing then.
242 + The command context also takes preparsed command array if so
243 specified in cmd_tab, and entries are cleaned up (see 2.)
244 9. We should unite all the un*() commands with their non-un*
245 versions, if they have one. They may take a different argument
246 list etc., but only one entry in the command table for such.
247 - The POSIX standard command abbreviations must remain, so maybe
248 outsource those in a hashtable or whatever that is checked first,
249 but detach command table order from that anyway.
250 - Offer a(n optional, and on/off switchable) Damerau-Levenshtein
251 mode for command completion;
252 10. We MUST switch the entire codebase to use SysV signal handling, don't
253 do the BSDish SA_RESTART, which is why we still suffer the way we
254 do and need jumps. I can't dig BSD signal handling, and never ever
255 did so myself until i got here.
256 20. The attachment charset selection loop can then be rewritten to
257 check whether an ^C occurred and treat that as end-of-loop
258 condition. In v14.6.3 this was introduced, but it should act
259 differently depending on whether the interrupt occurred during
260 character set selection or attachment filename input.
261 Also in respect whether the interrupt is "propagated" or not.
262 It's ugly, and documented accordingly.
263 30. It should be considered to drop many variables in favour of
264 URL ?SEARCH usage for keys, or key=value pairs, e.g.
265 smtp://exam.ple?starttls=yes;smtp-hostname=;
266 etc. USER@HOST is neat, but that is possibly preferable?
267 Question: what is with smtp-hostname and such??
268 31. Flag updates of individual messages must find their way through to
270 32. Use deque (on partial views).
271 34. We need a new abstraction: `vie[ws]'. I.e, viewset, viewclear,
272 view(show|look)? We will have (possibly readonly) boxes, a summary
273 cache file, which is created when a mailbox is read in, and all
274 that crap that we currently have (setptr(), setmsize(), etc.!) must
275 vanish. Instead there is another, in-memory abstraction, the view.
276 Some views are built-in and are somehow selectable (the "all" view,
277 for example, and the "new" view).
278 It is possible to make a view persistent by giving it a name, e.g.,
279 'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
280 or something must be capable to tag the last a.k.a current).
281 Switching to a named view would thus look over the entire current
282 view (!) for all messages that comply to the message-spec of the
283 view, then create a sorted/threaded display of that subset and
284 create a new anonymous "result" view. It must be possible to
285 specify that a view is to be applied to the entire mailbox instead
286 of the current view, via a simple easy understandable syntax.
289 We won't extend macros that much because it would require much too
290 much logic for no purpose, instead we'll (hopefully) add some
291 scriptable abstraction, with an optional built-in Lua binding.
292 50. Support SASL, unite all GSS-API etc. under an abstraction!
293 Maybe even drop direct GSS-API and support only through SASL.
294 That is, we can very well provide our own little SASL-client
295 abstraction with what we have already by simply defining some
296 "readline" abstraction plus struct ccred for use by the
297 authentication layer: the protocols must set it up by passing in
298 a line of authentication mechanisms and a callback mechanism.
299 Possibly the user should be able to permit or forbid automatic
300 selection of GSS-API (to avoid useless round-trips) etc. etc.
301 80. The MIME rewrite: mime_parser <-> mime "DOM" analyzer <->
302 selectively create filter chains per part and do XY.
304 This also affects sending, and it will allow us to dig MIME
305 (multipart) mail for -t/-m _correctly_. Also in sofar as we can
306 hook a content-decoder before diving into the MIME structure, and
307 with a DOM, we can re-encode such things properly as we (re)send
308 such mails. All this is wrong at the time of this writing!
309 We still need to special treat things like, e.g., RFC 2046, 5.2.1.
310 But on top of we-can, as opposed to the opposite.
312 (Brezn Stangl, brezn DOT stangl AT yandex DOT com; Martin T)
313 99. Now i'm dreaming some more: with the new object-based approach
314 multiple mailboxes could be in an open state. And it should be
315 possible to do so for the user (`file' and `folder' are required to
316 quit the current mailbox [first -- this not yet]), which is why we
317 either need new trigger characters or new commands.
318 The absolute sensation would be joinable operations over multiple
319 open mailboxes, e.g., views over multiple such!
320 100. If i say `p 3 2 1' then i mean `3 2 1' not `1 2 3'.
321 200. Split program: when entering interactive mode, the main machine
322 should fork and the UI should run in the forked one, taking the
323 terminal (have done setsid, TIOCSTTY, tcsetpgrp, dance).
324 - Communication via sendmsg()/recvmsg(), it was in BSD as soon as
325 1982 says CSRG (date and time created 82/12/04 16:22:24 by
326 mckusick); ok, a bit different by then, but on 1990-04-04 at
327 latest in todays form (Mike Karels: [.]define cmsghdr structure
328 for ancillary data, with new format; move access rights into
329 ancillary data; add MSG_WAITALL).
330 - Maybe furtherly diversify: network (with loop), main machine
331 (with loop), credential helper, i do not know.
332 Provide security sandboxing if possible, i.e., capsicum,
333 pledge/unveil, prctl/seccomp.
335 - The thread sort doesn't get
344 The current sort fails to recognize that F and the thread starting at
345 B are related, which results in a mess.
346 Tests: 41.bad-thread, 58.bad-thread ..
348 -- Being able to sort the outermost level of threads was a suggestion
349 of Rudolf Sykora, especially being able to sort the outermost level
350 according to the date of the newest message in a thread.
352 - Drop **use-starttls* in favour of something better: support 'auto',
353 'no' and 'yes' and act accordingly. For the former be smart enough on
354 the protocol side. (RFC 3207 describes man-in-the-middle attacks due
355 to 'auto' TLS, so explicit 'yes' should be favoured).
357 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
358 deal with IPv6 addresses (as in '[ADDR]:PORT'). Pimp url_parse().
361 - I had a connection collapse during a POP3 download, and neither was
362 there a chance to get access to the 22 yet downloaded mails (after
363 five minutes of waiting followed by CNTRL-C), nor did the layer
364 recognize this very well (got myriads of `POP3 connection already
365 closed.' messages, btw., the thirty-something messages which were not
366 yet downloaded caused (after CNTRL-C) this: ETC. ETC.
368 - I got an email in base64 that obviously used CRNL line endings, and once
369 i've replied the CR where quoted as *control* characters.
370 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
371 time, due to how we deal with I/O and Send layer etc).
373 - edit.c doesn't do NEED_BODY (but IMAP won't work anyway).
376 .. s-nail </dev/null should work interactively when STDERR_FILENO is
377 a terminal! (Built-in editor; how do editline and readline work?
378 should this be documented? POSIX says for sh(1) (APPLICATION USAGE):
379 'sh 2>FILE' is not interactive, even though it accepts terminal input.)
380 . Just like the RFC 3676 link above, it would be nice if it would be
381 somehow possible to recognize links in a document; i don't know yet
382 how this could be achieved without losing formatting information (i
383 mean, we could enable this and inject terminal colour sequences, but
384 one should be able to say 'follow link x', starting an action
385 handler, and the 'x' must come from somwhere - simply injecting
386 '[NUMBER]' references distorts visual). Anyway, it's just a filter
387 that recognized the usual <SCHEME:/> stuff, and of course we can
388 simply have a buffer which records all such occurrences, so that
389 user can say '? xy NUMBER', but without the context it soon gets
391 . TTY layer: the tc*() family may fail with EINTR, which MUST be
392 handled; setting also generates SIGTTOU when we're not in foreground
393 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
394 resetting terminal attributes!
395 .. TTY "I guess it would be much better to create our own session via
396 setpgid(2) and then tcsetpgrp(3) any processes we run synchronously,
397 and properly deal with SIGTTOU, but it always has been like that and
398 i won't do that before other things have been changed.
399 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
400 global mbstate_t objects until the send / MIME layer rewrite is done and
401 has the carrier. Use flip states and add aux funs with only update the
402 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
404 P.S.: the standards do not allow that well at all.
405 Since we work so much with *ttycharset* we would need
406 a setlocale_from_charset(), but which does not exist (except
407 implicitly for UTF-8 locales). But we need char classification!
408 This task up to S-CText.
409 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
410 this <rude>SHIT</rude> must vanish and be replaced by a URL, and
411 a nice "VFS" mailbox object that carries all necessary state so that
412 one can work with it.
414 If not mentioned somewhere else: struct message should be splitted
415 into a tree of objects, with a base class that has as few fields as
416 possible; the global *message should be a deque, only accessible via
417 iterator; it should store pointers to (the actually used subtype of)
418 message structures instead; i.e., for maildir boxes the path is yet
419 allocated separately, then it could be part of the message object,
421 It should track the number of contained parts, so that the
422 "fits-onto-the-screen" tests are more useful than today.
423 . Given how many temporary files we use, it would make sense to
424 support a reusable single temporary file, as in singletmp_take() and
425 singletmp_release(), where singletmp_release() would close and thus
426 drop the file if it excesses a specific (configurable) size, and the
427 mainloop tick would close it (after X (configurable) unused ticks))
428 otherwise. I guess this would improve performance for searching
431 use GNU tools for extraction etc., and write a simple helper program
432 which converts these files to a serialized hashmap, just like we did
433 for the okeys (and *exactly* so); add a config check whether the ({})
434 extension is supported and finally use that for some ({static char
435 const *tr_res;}) injection optimization, then. (Think SFSYS)
436 . Searching body/text yet includes headers from attachments and
437 attachment data. This is shit. :)
438 . The "nifty" unregister_file()->_compress() mechanism that even
439 shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
440 *records* calls clearerr() on the descriptor before performing it's
441 action anyway. when we really make it even to the I/O rewrite, it
442 should be possible to dis-/allow such -- it doesn't make sense to
443 add something faulty to whatever was not faulty before!
444 . `dp' prints EOF at the end of a thread even if unread messages
446 . `resend' doesn't smime-sign.
447 . RFC 5751 describes a message multipart layout that also includes the
448 headers in the signature; it would be nice (for completeness sake)
449 to be able to support that. Note shutup@ietf.org.
450 . The capability to save a message under the name of a recipient is in
451 the standard etc., but i've never used it.
452 What would be cool, otoh, would be if there would be the possibility
453 to register a regular expression, and if just *any* recipient of
454 a message matches, store the message in the given folder instead.
455 I.e., if i send a message to s-nail-users@ then i most likely want
456 to get a copy to the corresponding box, regardless of whoever the
457 message was sent To: Cc: or Bcc: else..
458 . mutt list handling (`~') is very powerful
459 . We have some use of *at() functions, especially anything which
460 temporarily switches cwd.
461 . *newmail* is terrible. At some later time we need to do somethings
462 with timeouts etc. (for MBOX and Maildir it's not that bad, but for
463 anything over the network, yet the mentioned may come in over NFS).
464 Remove it until we have something better?
465 . The RFC 8098 *disposition-notification-send* mechanism is yet not
466 truly conforming (and works with *from*). Also, this is only the
467 sender side, there should be support for creating the MDN response.
468 (Maybe ternary option: off (default),
469 create-when-unread-flag-goes-away, ditto-but-also-strip-header)
470 .. Also, there is DSN as a SMTP extension, see the RFCs 3461, 346 (as
471 above) and 6522 (Wikipedia).
472 . The var_* series should return "const char*" not "char*".
473 This should already work today because otherwise we would get SEGV
475 .. While here: rename enum okeys to enum internal_variables, and the
476 ok_*() series to iv_(). And see below for env_*() series.
477 . fexpand() the 2nd: it should return structure because we need to
478 check for FEDIT_SYSBOX, which currently only checks whether the first
479 character of a file name is '%', not whether it is '%', '%:FILEPATH'
480 or '%VALIDUSER', because that is impossible to do!
481 . On the long run in-memory password storage should be zeroed after
482 use, possibly even encoded *during* use. After v15.
483 . We need a `spamcheck' command that is like `spamrate' but updates
484 the mail in-place, i.e., with the headers that the spam engine adds.
485 . __narrow_suffix() is wrong (for stateful encodings that we
486 don't support yet) and should inject a reset sequence if it shortens
488 . When a user edits a specific header, it should no longer be
489 modified. (Do not loose knowledge that collect() edited it.)
490 . The new internal ~/$ expansion mechanism should get support
491 for POSIX parameter expansions ${[:]-} and ${[:]+} (and ${[:]?}).
492 There is no real way to get the functionality otherwise...
493 . Make S/MIME an option separate of SSL/TLS, i.e., optional.
494 . With very long input Heirloom mailx(1) / S-nail(1) can produce
495 encoded-words (RFC 2047) with incomplete multibyte sequences (i.e.,
496 non self-contained encoded-words).
497 . Group addresses, especially the undisclosed recipients but also
498 "Bla": addresses; are missing.
499 . Per-folder (S/MIME) en- and decryption key (Tarqi Kazan): if a xy
500 variable is set (that points to a key) add a transparent en- and
501 decryption layer on top of any per-message operation (for boxes for
502 which the variable is set).
503 . For v15.0: remember private thread with Tarqi Kazan (2015-05) and
504 try to improve situation with *record*, so that only messages enter
505 it which have really been sent. If we support postponing and have
506 a multi-process layout and add an intermediate *record-queue* we
507 may be able to improve the situation.
508 . [Dd]ecrypt should transport decryption errors, not silently be like
509 copy and copy undecrypted content, because this is what it's for?
510 ..We need atomic operations with rollback support in order to make
511 this happen, but i think maybe file truncation (decryption always
512 appends?) is enough provided that files are locked?
513 WE NEED ATOMIC OPERATION SUPPORT for quite some operations.
514 Man, are we far from that.
515 . `pipe' is total shit regarding MIME. We need some defined and
516 documented method to configure which parts are displayed and/or how
517 they are visually separated.
518 .. In PARTICULAR we MUST NOT use stdout for log/status in batch mode:
519 ssh X "echo 'move * |cat' | s-nail -#f %" >> download
520 should do the right thing, but can't like that due to unwanted
521 noise in the stdout output! Best would be if it would be
522 possible to explicitly define a file/dev to be used, but falling
523 back to stderr in batch mode otherwise. (think S-Web42)
524 . Exit status handling is sick.
525 . *mime-allow-text-controls* is a no-brainer: instead we should
526 introduce something that allows us to switch and detect UTF-16 once
527 we run into the problematic situation, then start all over in an
528 Unicode mode? I.e.: continue to force the user to set such
529 a switch, but do it in a sensible fashion, because the UTF-16 data
530 stream may nonetheless contain control characters??
533 . smime_verify(): only dump the multipart that is signed into the file for
534 verification purposes. DOCUMENT that only the FIRST such part is verified.
535 Ditto, we don't decrypt but on toplevel. Sic.
537 . convert iconv so that it always "places the reset sequence" i.e.
538 finalizes the string properly. we don't do this at all right now!
540 . -:, *mimetypes-load-control*, ?, should honour the given load order; as
541 appropriate, add a "b" for built-in!
542 It happened to me that i searched for at least 30 minutes for a bug
543 that resulted in text/plain not text/x-diff only to find out that this
544 was because of ArchLinux's /etc/mime.types!
546 . getapproval() should support a TRUM1 return, meaning "cancel",
547 to be understood as appropriate.
549 . `mbox' _can_ be made usable anywhere with yet another PS_MBOX global
550 bypass! ditto touch,save,Save
552 . We should be much smarter regarding when we allow a PAGER
553 etc. to be used, which is supposed to be a possibly useful thing in
554 $ s-nail -Scrt=0 >LOG 2>&1
556 . when doing Lreply we may ask for Reply-To:, but strip out the address
557 actively even if user said yes to the question. That should not
558 happen? It somehow matches the documentation however. unsure.
560 . if -t is used and the file includes Mail-Followup-To:, then we should
561 NOT add to it, OR we need to offer a way to get there!
563 . `mimetype': more type markers: i want to be able to send
564 application/mbox as text if it is 7bit clean; ditto application/x-sh.
565 Ditto xml etc. And: if highbits, try conversion, but fall back to
566 base64 instead of failing to send the message.
567 ?ui=t,wire=7bit,8bit-or-base64