3 Release S-nail v20 on 2018-03-25, the 40th anniversary of Mail.
4 With a clean, conforming and efficient codebase, then.
6 - Recipients specified on the command line should be added to those
7 specified in the message when the -t option is set.
9 - At least optionally disallow silent discarding of invalid addresses,
10 i.e., cause sending to be aborted if not all recipient addresses pass the
13 - Ditto if a resource file can't be found that has been explicitly set via
14 environment variables there should be some feedback.
16 - I.e., it is fine to be silent unless an error occurs, but then please
17 report errors and offer (in interactive mode) the possibility to act at
18 a glance. (See error ring topic around here.)
20 - POSIX says that, when written to DEAD: "If the file exists, the message
21 shall be written to replace the contents of the file". This is mentioned
22 for ASYNCHRONOUS EVENTS, but it's the only description of what should be
23 done in which way to DEAD. savedeadletter() yet appends. See ZOMBIE ,)
25 - It irritates me that a message with 5 visible lines but 115 header lines
26 goes through the pager, even if i have *crt=*.
28 - We should possibly get away of using command line utilities for
29 compression. (At least optionally?) Instead we should link against
30 zlib(3), bz2lib(3) and lzma(3), if found. Or we may use dlopen(3)
31 instead, if found, to avoid linking (though those libraries don't need
32 much linker work unless actually used afaik, 'should look in detail).
33 We should also drop lzw.c, it is used for the IMAP cache.
35 - We should maybe turn -~ into the meaning "force interactive".
36 We should extend cc-test.sh, then, to test some interactive things.
37 E.g., via (tcl(1) or, better.., perl(1) (CPAN)) expect.
39 - We need a "void" box that can be jumped to, i.e., a state in which no box
42 -- When a MBOX mailbox is removed while it is opened then changing the
43 folder is not possible. This is an inherent problem of the Berkeley
44 Mail codebase, and we need to have a fully functional intermediate
45 VOID box mechanism plus an object-based mailbox implementation to
48 -- Also, when the folder was modified concurrently we should bail, or,
49 in an interactive session, prompt the user what to do.
51 - IDNA decoding. Needs a complete design change.
52 (Unless wants to brute force decode anything before display, of course.)
54 - If pipes fail for part viewers then at least the usual PART X.Y should be
55 shown, maybe even including some error message.
56 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
57 does not have lynx(1), and i thought i've found a S-nail(1) bug.
59 -- Also, when we run a pipe handler asynchronously there should possible
60 written something like [pipe-handler xy started] or something
62 - Offer the possibility to work with certificate fingerprints instead of
63 full certificates, in equal spirit to the current maintainers S-Postman
64 and Mercurial. S-nail(1) could simply offer something in equal spirit to
65 the formers --fingerprint, so that no other tool is necessary for
66 certificate management (for at least secure transport).
68 - It would be nice if it would be possible to define a format string for
69 *quote*, like 'set quote="format=some formats"'.
70 In general the current approach is somewhat messy IMO. I.e., it would
71 make more sense to act rather like mutt(1) and as written elsewhere in
72 this document, i.e., have some toggles that act on the display and use it
73 for multiple modes (show/reply/forward etc.)
74 Otherwise introduce commands which include all the headers plus, e.g.,
75 "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
77 -- This would also mean that interactive message editing would work
80 - Command line editing should gain possibility of context sensitive tab
83 - Maybe there should be an additional ZOMBIE directive that is served in
84 equal spirit to DEAD, but that could be a valid MBOX... ?
85 What i want is a *real* resend, best if possible from command line.
86 Meaning, also the possibility to postpone a message. In general.
88 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
90 - There should be a way to ignore the From_ line, as opposed to the From:
91 line, i.e., distinctively.
93 - There should be a variable that controls wether leading and trailing
94 empty lines of parts and/or messages as such should be printed or not.
96 - printhead()/hprf(): support %n newline format (%t tab?).
97 Make it possible to use the *datefield* algorithm for plain From_ derived
98 dates (needs a From_ parser, i.e., strptime()-alike).
99 Once we have that, rename *datefield-markout-older* to
100 *date-markout-older* ??
101 Note that NetBSD's mail(1) has some other nice things.
102 Note also that our code is quite unflexible.
104 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
105 variables (though prefix and appendix or prefix and suffix, but..).
106 Note that our code is quite unflexible.
108 - The "top" command should honour ignoretab, or there should be a very
109 special "top" ignoretab. It simply doesn't make sense to "top" 5 lines
110 when all that you get are Received: lines...
112 - In the very end it is not that hard to add (optional) MTA
113 functionality at a most simple level.
114 Use sqlite for aliases (and possibly cache), then.
115 (Though a nice dynamic cpdict should also be sufficient.)
117 - We should support IMAP compression over the wire.
122 - Improve name extraction rules. And field parsing. There
123 are structured and unstructured fields. There are quoted pairs and
124 comments etc. Rewrite the entire parsing mechanism to comply to RFC
125 5322, and try to merge all those many subparsers around in the codebase,
126 and accordingly. So much duplicated work ...
127 Name parsing has been improved a bit for v13, but it's still broken.
128 yankword(), *extract(), etc.: RFC 5322 says that comments in address
129 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
130 approbiate, even if that actually changes content!!?), and that full
131 name-addr SHOULD be used. Our functions are yet quite silly (i.e.,
132 leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
133 doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
134 (bier6)", that becomes "<a6@b6.de>").
136 (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3)
137 Should eventually become
138 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
139 on the display, or, with IDNA decoding (and thus rather unlikely)
140 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
141 It should NOT become this mutt(1)ism:
142 "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
145 -- Think about a name bypass hashmap cache, and whenever we have to skin or
146 nalloc() or whatever, look in there. Maybe even an additional link for
147 non GFULL(/GSKIN) and fully skinned struct name objects.
148 The amount of duplicated work in this codebase is frustrating, but the
149 real healing would make necessary a complete rewrite of the name handling!
150 Such a cache would work without touching the current code flow ... or
151 allow a smooth transition to a new one anyway.
153 ++ NOTE: 'alternates' tracking happens BEFORE we enter composing, this
154 means that an account switch during message composing will NOT cause
155 reevaluation of all that very very clumy
156 elide/delete_alternates/gexpand/is_myname etc. handling.
158 - The char classification stuff can be improved; currently each character
159 has exactly one classification bit set, even if multiple would apply
160 (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK). This would allow better
161 testing using our own classification functions in quite some places.
163 - The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
164 it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
165 Webmail) create HTML parts which solely consist of a single line,
166 created via soft linebreaks.
167 To handle such mess we need to be able to break out of the input-line ==
168 output line relationship that is still fixated in the codebase.
169 I.e., it is not even sufficient to convert "rest" into an array, but best
170 would be if we would be able to sequentially work what we have, and
171 detect when it is safe to "dump that out".
172 This MUST be part of the send/mime layer rewrite in 15.0.
174 -- In v15.0, when we can address attachments of a message individually,
175 it would be nice to provide even more access, just like nmh(1) does
176 (Johan Commelin: Are s-nail and mh related?).
178 - I never used anything but the *datefield* option, and it would really be
179 nice if the date strings would be parsed off into some 16 byte or what
180 storage when about to producing the summary, so that it would be directly
181 available and there would be no need to reread the mail. Moreover, or
182 even more than that - the m_date field exists and should possibly simply
183 be init, at least in these cases. (P.S.: this doesn't contradict the
184 statement somewhere else in this file that the structure should be
185 slacked; simply use multiple thereof or so)
187 - At some later time extend the logic behind -# -- it should not have
188 a current folder, but start in VOID mode (...), and unless one is
189 explicitly chosen.. We need a reliable batch mode.
191 - After I/O layer rework we should optionally be able to read RSS
192 (Atom?) feeds -- Expat should be available almost everywhere and
193 should be able to parse that?
194 Atom is harder because it may support html+.
195 I mean, yeah, it's stupid, but we could fill in header fields with
196 dummies and still use S-nail to look into the separated feeds as if
197 they were mail messages; anyway i would like to save me from using too
198 many tools -- three seems reasonable.
200 -- `sync'hronize commando -- robin@stjerndorff.org (Robin Stjerndorff):
201 Wondering how to update back to my Maildir, moving new read mails
202 in ~/Maildir from new to cur, without exiting the application.
203 Automation available? [And simply re-`[Ff]i' involves a lot of
206 -- Provide sync'ing options -- Jacob Gelbman <gelbman@gmail.com>:
207 If I open two instances of mailx, I then delete a message and then
208 quit in one. Then in the other one I read a message and quit, mailx
209 saves the status of the read message and the fact that a message was
210 deleted, even though it was opened before the other instance deleted
211 it. How is it doing that? [Of course he was using Maildir]
213 - Add TODO notes for those RFCs:
214 RFC 5322 - The basic format of email messages.
215 MIME (Multimeda) email extensions
216 RFC 2405 - The format of MIME message bodies.
217 RFC 2406 - Common multimedia types.
218 RFC 2017 - URL External-Body Access-Type
219 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
220 text (format=flowed). (Martin Neitzel)
221 RFC 2407 - Encoding of non-ASCII text in message headers.
222 RFC 2183 - The Content-Disposition Header
223 RFC 5321 - Simple Mail Transfer Protocol.
224 RFC 6409 - Message Submission for Mail
225 RFC 4954 - SMTP Authentication
226 RFC 3207 - SMTP over TLS
227 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
228 Post Office Protocol (POP)
229 RFC 1939 - Post Office Protocol v3
230 RFC 2449 - POP3 Extensions (including SASL)
231 RFC 2595 - TLS for POP3 (among others)
233 RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
235 RFC 5246 - Transport Layer Security (TLS)
236 RFC 977 -> 3977 - Network News Transfer Protocol
237 RFC 1036 - Standard for USENET Messages
238 RFC 2980 - Common NNTP Extensions
239 RFC 2387 - multipart/related -- yet handled like /alternative
240 RFC 2384,1738 - I.e., Much better URL support
241 RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
242 RFC 6125 - Representation and Verification of Domain-Based Application
243 Service Identity within Internet Public Key Infrastructure Using
244 X.509 (PKIX) Certificates in the Context of Transport Layer Security
247 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery
248 Status Notifications (DSNs),
249 An Extensible Message Format for Delivery Status Notifications
250 RFC 5598 - Internet Mail Architecture
251 RFC 1524 - True support for mailcap files?
252 draft-ietf-uta-email-tls-certs-01.txt
253 SMTP security via opportunistic DANE TLS draft-ietf-dane-smtp-with-dane-15
254 draft-melnikov-smime-header-signing
255 Considerations for protecting Email header with S/MIME
257 - This is how the codebase has to be reworked in respect to signals and
260 1. We introduce some environment/carrier structs: struct eval_ctx,
261 struct cmd_ctx, (struct send_ctx). All of these form lists.
262 eval_ctx gets a new instance every time evaluate() is entered; for
263 the interactive mode, commands() instantiates an outermost eval_ctx
264 that "cannot be left".
265 cmd_ctx knows about the eval_ctx in which it is was created; it is
266 created for each command that has an entry in cmd_tab and is passed
267 as the new argument of these kind of functions.
268 (send_ctx is the carrier for the MIME and send layer rewrite.)
269 2. We'll get a signal manager. This is a global layer which is the
270 sole object-in-charge for signals. We'll install a complete set of
271 handlers once -- those will only set has-occurred bits.
272 All interested parties have to peek at the signal manager when they
273 are in the position to deal with signals, via a series of
274 "ha(s|ve)_occurred", "needs_action", "would_raise" or whatever, as
276 3. We need a sort of non-local return, everything else would require
277 a totally different way of programming. Also, non-local returns
278 are not *that* bad, generally speaking. We'll be easy and add the
279 possibility to define a jump target location in eval_ctx and
280 cmd_ctx, by peeking at the signal manager (for object design
281 reasons, though done by a macro, say), just like saying "i need to
282 have the chance to perform some actions shall a jump be necessary".
283 4. So, somewhere deep down the still recursive codebase, shall the
284 necessity to honour a jump request occur, we peek the signal
285 manager to "unroll" the current cmd_ctx/eval_ctx chain(s), which
286 will result in none-to-multiple jumps to locations which require
287 cleanup actions, ultimately ending in the non-leavable commands()
288 eval_ctx or whatever.
289 6. Hot: we save us from thousands of syscalls, and get rid of the
290 fucking sig* shit. It rhymes, it rhymes :)
291 Should we even be able to go the non-blocking select(2) way in the
292 end -- that would be fantastic!
293 10. 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 temporary hack which duplicates the line buffer in order to
301 place the original content in history can be removed again.
302 11. Macro execution is potentially recursive. Meaning that
303 `undefine', etc. can occur while macros are executing.
304 The simplemost approach would be to have some recursion counter for
305 each macro and a delete_later flag that gets honoured when the
306 recursion counter gets zero. It would be already possible to
307 immediately remove the macro from the hashtable, so that deeper
308 levels wouldn't find it anymore. To avoid leaks (which *are*) we
309 need to have a jump location for our upcoming signal handler
310 anyway. (Also to get rid of the temporary_localopts_free() hack.
311 + The same is true for `account's. Here things are complicated by
312 the global `account_name', i.e., the account could be the current
314 + That also is: redefinition of names that have yet-pending
315 deletion requests are possible.
316 12. It is annoying that you cannot `source' your MAILRC multiple times.
317 Defining a macro/account/xy should overwrite the current thing,
318 just as it does anyway for normal variables!
319 This is no different than 11. plus additional re-addition.
320 (Same exception: what if the currently active account is
321 overwritten? Same answer, plus a message "new settings take effect
322 when account is switched to the next time".)
323 20. The attachment charset selection loop can then be rewritten to
324 check wether an ^C occurred and treat that as end-of-loop
325 condition. In v14.6.3 this was introduced, but it should act
326 differently depending on wether the interrupt occurred during
327 character set selection or attachment filename input.
328 Also in respect wether the interrupt is "propagated" or not.
329 It's ugly, and documented accordingly.
330 30. Mail protocols and mail messages are accessed through a "VFS".
331 URL should then support file:// and maildir:// etc. Update manual!
332 31. Flag updates of individual messages must find their way through to
334 32. Use deque (on partial views).
335 34. We need a new abstraction: `vie[ws]'. I.e, viewset, viewclear,
336 view(show|look)? We will have (possibly readonly) boxes, a summary
337 cache file, which is created when a mailbox is read in, and all
338 that crap that we currently have (setptr(), setmsize(), etc.!) must
339 vanish. Instead there is another, in-memory abstraction, the view.
340 Some views are builtin and are somehow selectable (the "all" view,
341 for example, and the "new" view).
342 It is possible to make a view persistent by giving it a name, e.g.,
343 'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
344 or something must be capable to tag the last a.k.a current).
345 Switching to a named view would thus look over the entire current
346 view (!) for all messages that comply to the message-spec of the
347 view, then create a sorted/threaded display of that subset and
348 create a new anonymous "result" view. It must be possible to
349 specify that a view is to be applied to the entire mailbox instead
350 of the current view, via a simple easy understandable syntax.
351 50. Support SASL, unite all GSS-API etc. under an abstraction!
352 Maybe even drop direct GSS-API and support only through SASL.
353 That is, we can very well provide our own little SASL-client
354 abstraction with what we have already by simply defining some
355 "readline" abstraction plus struct ccred for use by the
356 authentication layer: the protocols must set it up by passing in
357 a line of authentication mechanisms and a callback mechanism.
358 Possibly the user should be able to permit or forbid automatic
359 selection of GSS-API (to avoid useless round-trips) etc. etc.
360 99. Now i'm dreaming some more: with the new object-based approach
361 multiple mailboxes could be in an open state. And it should be
362 possible to do so for the user (`file' and `folder' are required to
363 quit the current mailbox [first -- this not yet]), which is why we
364 either need new trigger characters or new commands.
365 The absolute sensation would be joinable operations over multiple
366 open mailboxes, e.g., views over multiple such!
367 100. If i say `p 3 2 1' then i mean `3 2 1' not `1 2 3'.
369 - Deal with faulty message selection that may occur when selecting threads
370 via & (when at least mixed with other selectors).
372 -- Also (?same problem?) the thread sort doesn't get
381 The current sort fails to recognize that F and the thread starting at
382 B are related, which results in a mess.
384 - Drop **use-starttls* in favour of something better: support 'auto',
385 'no' and 'yes' and act accordingly. For the former be smart enough on
386 the protocol side. (RFC 3207 describes man-in-the-middle attacks due
387 to 'auto' TLS, so explicit 'yes' should be favoured).
389 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
390 deal with IPv6 addresses (as in '[ADDR]:PORT'). Pimp url_parse().
393 - mutt(1) dotlock ..., "mbox" command doesn'T work?
395 - ARGH! Should `folders' auto-login if *folder* is an IMAP account that is
396 not active? Why does _expand() use *mailname* to expand `@', not
397 getfold() (care: res may point into cbuf, savestr() or so!).
398 Why does demail() etc. treat *mailname* as a file (more or less), why do
399 we need *mailname* at all; we should have Folder objects, multiple of
400 which concurrently, one the active; a Folder may not become *folder*
401 unless it has write (store) capabilities). Maybe then `mbox' works fine
402 if connected to a POP3 server with a *MBOX* on an IMAP account that yet
403 never was connected and needs to read a password on the terminal before
404 the login works ... note the latter situation yet kills us since i think
405 INT is blocked during all that ;-((
407 - I had a connection collapse during a POP3 download, and neither was
408 there a chance to get access to the 22 yet downloaded mails (after
409 five minutes of waiting followed by CNTRL-C), nor did the layer
410 recognize this very well (got myriads of `POP3 connection already
411 closed.' messages, btw., the thirty-something messages which were not
412 yet downloaded caused (after CNTRL-C) this: ETC. ETC.
414 - Add a value-duplication command, i.e.,
421 - Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
422 relationship, too)! EOF conditions in general!
424 -- NCL / current expand-on-tab: fexpand() should take additional size_t* to
425 store the number of the results OR should "return char** array", so that
426 individual results can be addressed.
427 Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
428 line if the result is ambiguous, i.e., we have more than one possible
430 However, we would then need something to print the results page-wise,
431 in case we have so many of them that they don't fit on the screen.
434 - I got an email in base64 that obviously used CRNL line endings, and once
435 i've replied the CR where quoted as *control* characters.
436 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
437 time, due to how we deal with I/O and Send layer etc).
439 - edit.c doesn't do NEED_BODY (but IMAP won't work anyway).
442 .. s-nail </dev/null should work interactively when STDERR_FILENO is
443 a terminal! (Builtin editor; how do editline and readline work?
444 should this be documented? What does NetBSD Mail do? Should we NOT
445 be interactive?? POSIX says for sh(1) (APPLICATION USAGE): 'sh
446 2>FILE' is not interactive, even though it accepts terminal input.)
447 . Automatically track message attachments when switching off the
449 NOTE: 'alternates' tracking happens BEFORE we enter composing, this
450 means that an account switch during message composing will NOT cause
451 reevaluation of all that very very clumy
452 elide/delete_alternates/gexpand/is_myname etc. handling.
453 We REALLY need an object based rework of all that.
454 . It would be cool if ghosts, shortcuts, alternates could
455 (optionally?) be tracked via localopts. And macros. And inner macros.
456 (Additional entry on xy-local xy somewhere above)
457 And / or local to a macro/account if defined in one.
458 . DESTDIR= should not be taken into account when deciding wether
459 a rebuild is necessary (not wrong to give that to Gaetan Bisson).
460 . Just like the RFC 3676 link above, it would be nice if it would be
461 somehow possible to recognize links in a document; i don't know yet
462 how this could be achieved without loosing formatting information (i
463 mean, we could enable this and inject terminal colour sequences, but
464 one should be able to say 'follow link x', starting an action
465 handler, and the 'x' must come from somwhere - simply injecting
466 '[NUMBER]' references distorts visual). Anyway, it's just a filter
467 that recognized the usual <SCHEME:/> stuff, and of course we can
468 simply have a buffer which records all such occurrences, so that
469 user can say '? xy NUMBER', but without the context it soon gets
471 . TTY layer: the tc*() family may fail with EINTR, which MUST be
472 handled; setting also generates SIGTTOU when we're not in foreground
473 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
474 resetting terminal attributes!
475 .. "I guess it would be much better to create our own session via
476 setpgid(2) and then tcsetpgrp(3) any processes we run synchronously,
477 and properly deal with SIGTTOU, but it always has been like that and
478 i won't do that before other things have been changed.
479 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
480 global mbstate_t objects until the send / MIME layer rewrite is done and
481 has the carrier. Use flip states and add aux funs with only update the
482 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
484 . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
485 cache we have some kind of UID validity check -- couldn't that be
486 used to perform some kind of automatic reconnection when we get that
487 much-too-frequent connection breaks in IMAP mode??
488 Also, and also for POP3, don't let the ALARM based (ugh! I'm
489 starting to dream wet from select(2), almost truly) timer blindly
490 tick, but restart it with a full interval when we did regular
491 conversation with a server. Don't forget the SSL timeouts (300
492 seconds) and their interaction with normal (user) keepalives.
493 Add a global *keepalive*, add *keepalive-USER@HOST*. (Add and use
494 a generic, single function to get the value for either protocol.)
495 . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
496 mk-conf.sh yet always tests anything, i.e., we could fail due to
497 history related stuff even though the user doesn't WANT_HISTORY.
498 .. We should in fact convert our NCL history to a shared history
499 implementation, and only hook editline(3) and readline(3) so that
500 ^R and Cursor-(Up|Down) work as expected everywhere.
501 Like that we would have duplicate elimination for readline(3), too.
502 .. tty_addhist() should take a struct str. Anyway, evaluate() should
503 enter a history entry if the caller allows so, and it should trim
504 also trailing whitespace; also, the expanded command should be
505 stored, not the abbreviation, so that 'sst' and 'sstats' will no
506 longer produce two separate entries.
507 ... Because of laststring() and because the evaluate()d line buffer is
508 not constant history entries sometimes do not 100% reflect what
509 was actually present on the command line, but i refrained from
510 hacking a solution since that buffer must end up as a constant
511 (TODOs or so in the source).
512 P.S.: i have hacked that in in [f1ded4c] (as a temporary user
513 goodie because of inconvenience for v14.7.6).
514 . getprompt() could reserve for each dynamic entry at least one
515 visible offset, so that at least a `?' could be written if the room
516 is otherwise insufficient; in addition, if there were 3 such
517 dynamics, but all in all two visible offsets would be left, a single
518 entry with as much `?' as possible c/should be written, so as to
519 indicate the user anything visually.
520 . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
521 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
522 this <rude>SHIT</rude> must vanish and be replaced by a URL, and
523 a nice "VFS" mailbox object that carries all necessary state so that
524 one can work with it.
526 If not mentioned somewhere else: struct message should be splitted
527 into a tree of objects, with a base class that has as few fields as
528 possible; the global *message should be a deque, only accessible via
529 iterator; it should store pointers to (the actually used subtype of)
530 message structures instead; i.e., for maildir boxes the path is yet
531 allocated separately, then it could be part of the message object,
533 It should contain a ui8_t that tracks the number of contained parts,
534 so that the "fits-onto-the-screen" tests are more useful than today;
535 i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
536 . Given how many temporary files we use, it would make sense to
537 support a reusable single temporary file, as in singletmp_take() and
538 singletmp_release(), where singletmp_release() would close and thus
539 drop the file if it excesses a specific (configurable) size, and the
540 mainloop tick would close it (after X (configurable) unused ticks))
541 otherwise. I guess this would improve performance for searching
543 . Searching code *could* perform a prepass, joining stuff together,
544 dropping useless cases etc.
545 But anyway: if there are multiple search expressions, it shouldn't
546 be an error if at least one of them matches at least one message.
548 use GNU tools for extraction etc., and write a simple helper program
549 which converts these files to a serialized hashmap, just like we did
550 for the okeys (and *exactly* so); add a config check wether the ({})
551 extension is supported and finally use that for some ({static char
552 const *tr_res;}) injection optimization, then. (Think SFSYS)
553 . Searching body/text yet includes headers from attachments and
554 attachment data. This is shit. :)
555 . Btw.: (with IMAP) when opening a folder the hook gets executed after
556 the flags but before the headers are loaded, but for `newmail' it is
557 *after* the headers have been loaded.
558 . /* TODO *batch-exit-on-error*: sourcing and loading MUST BE FLAGS!
559 * TODO the current behaviour is suboptimal AT BEST! */
560 . The "nifty" unregister_file()->_compress() mechanism that even
561 shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
562 *records* calls clearerr() on the descriptor before performing it's
563 action anyway. when we really make it even to the I/O rewrite, it
564 should be possible to dis-/allow such -- it doesn't make sense to
565 add something faulty to whatever was not faulty before!
566 . The message from Andy Switala on nail-devel made me think about some
567 mechanism that invokes a macro after a message has been sent.
568 Unless macros can have args (or do we introduce $*/$@/$1..).
569 Even if the codebase will at some future time be stable and really
570 reliable, sending a message via multiple channels will never be
571 atomic, so that it would make sense for a user to be able to restore
572 *the complete message* in a save place if any of the sends failed,
573 but to remove it from our temporary place otherwise. A simple
574 version of this would be a matter of five minutes, but since
575 mightrecord() may internally (via _compress()) instantiate
576 a complete IMAP session and try to send incomplete data etc.,
577 and all that may jump, i refrained from doing so.
578 .. Note that mutt also has send-hooks with special triggers etc.,
579 which even allows setting some options which affect the mail to be
580 sent, like choosing a signing certificate dependend on the value in
583 1. init send carrier enough for allowing
585 3. fully initialize send carrier according to what is "final"
586 4. run trigger macros WHICH MAY MODIFY THE MESSAGE AGAIN, so
587 5. fully reinitialize the send carrier (as necessary)
588 6. pass the _final_ message down the send/mime chain
589 . SMTPS never became a standard and :465 was already reassigned
590 (thanks, carriers), but if a user says SMTPS and doesn't specify
591 a port also then we could simply assume :465 because except NetBSD
592 noone has SMTPS in their /etc/services?
593 Or at least automatically restart a failed getaddrinfo() in the
594 SMPTS case (if EAI_SERVICE)?
595 (Ooops - i think this should go to Gianluca Ramunno!)
596 . `dp' prints EOF at the end of a thread even if unread messages
598 . When doing `~w FILE' and FILE cannot be written to (was a directory)
599 then the composed mail is lost completely, it seems we jump to the
601 . `resend' doesn't smime-sign.
602 . Really do extend the test already today; test S/MIME
603 signing/encryption/decryption with two pairs of identities, instead
605 . RFC 5751 describes a message multipart layout that also includes the
606 headers in the signature; it would be nice (for completeness sake)
607 to be able to support that.
608 . The capability to save a message under the name of a recipient is in
609 the standard etc., but i've never used it.
610 What would be cool, otoh, would be if there would be the possibility
611 to register a regular expression, and if just *any* recipient of
612 a message matches, store the message in the given folder instead.
613 I.e., if i send a message to s-nail-users@ then i most likely want
614 to get a copy to the corresponding box, regardless of whoever the
615 message was sent To: Cc: or Bcc: else..
616 . Things like colalign(), makeprint(), colour*, as well as
617 possibly even cmd1.c:(__hprf|putindent)(), etc. belong into a cui.c,
618 display.c or the like, but not into auxlily.c etc. for sure.
619 Also writing a range of headers should be done through an
620 iterator-thing with setup/finalize init/destroy life cycle, which
621 would encapsulate the entire cmd1.c:_print_head() in the single
622 iterator setup function!
624 defined HAVE_SETLOCALE && defined HAVE_C90AMEND1 && defined HAVE_WCWIDTH
625 into HAVE_NATCH_CHAR, solely keep that. But improve the name
626 . Using -t should still optionally offer an option to enter editing.
627 Also we should support command line arguments on top.
628 Add a -T flag for that. Drop -q, let -T mean the same if no header
629 fields are given (i.e., header fields are not mandatory as with -t).
630 ANYWAY: -t and -q are mutual, enforce that (yet done?)
631 While there, it should be possible to send non text/plain for
632 -q/-t, i.e., perform MIME classification; v15.0 and not only this,
633 why not simply sucking in complete MIME messages via -t?
634 (Brezn Stangl, brezn DOT stangl AT yandex DOT com)
635 . mutt list handling (`~') is very powerful
636 . Check what happens if an account switch or a network connection is
637 done while we are loading the resource files...
638 . We have some use of *at() functions, especially anything which
639 temporarily switches cwd.
640 . *newmail* is terrible. At some later time we need to do somethings
641 with timeouts etc. (for MBOX and Maildir it's not that bad, but for
642 anything over the network, yet the mentioned may come in over NFS).
643 Remove it until we have something better?
644 . The :d modifier is extremely useless even though POSIX compliant (No
645 deleted message or deleted message header shall be displayed by any
646 mailx command other than undelete.)
647 If i explicitly say p:d or f:d or c:d it should work.
648 . The RFC 3798 *disposition-notification-send* mechanism is yet not
649 truly conforming (and works with *from*). Also, this is only the
650 sender side, there should be support for creating the MDN response.
651 (Maybe ternary option: off (default),
652 create-when-unread-flag-goes-away, ditto-but-also-strip-header)
653 .. Also, there is DSN as a SMTP extension, see the RFCs 3461, 346 (as
654 above) and 6522 (Wikipedia).
655 . Add a env_blook()/env_vlook() series like that: add a FROM-ENV bit
656 to variables; use the normal var lookup, but even if found, when
657 FROM-ENV not set, use getenv(3); question yet open is wether that
658 value should then override what we have; in fact i think we should
659 possibly during loading phase act like this automatically for *all*
660 variable settings, i.e., settings from the environment MUST override
661 settings from ressource files UNLESS command line arguments
662 explicitly override anything else. That is pretty shitty, which
663 makes me think that we should possibly iterate over environ(3) and
664 explicitly overtake all values therein, or at least those which have
665 a meaning for S-nail; this needn't be as expensive as it sounds.
666 .. Some things need to be tracked, e.g. HOME (homedir), TMPDIR
667 (tempdir) or must not be settable (USER). We should be able to
668 do so (currently "USER" etc. are "assembled") and error out as
669 necessary (currently "setenv USER=goof" just works!)
670 .. More on variables below!
671 . We should support more named colours, enabled via a, e.g.,
672 *colour-plus*, but provide downgrade colours for given colour names
673 if that isn't set. (Gavin Troy)
674 . I want *pipemac* (or *pipe-hookXY*). This requires v15.0
675 infrastructure (pseudo: evaluate() returns enum eval_retval{OK=0,
676 ERR=1, ISMAC=0x80, MACOK=ISMAC|OK, MACERR=ISMAC|ERR}; new `return'
677 command which only works in an executing macro (care: recursion);
678 macro arguments in pseudo variables $1...$x (works?); `return' can
679 "return" a list (simply keep argument list around); macro execution
680 can then simply check the return value to decide what to do (no
681 jumping); btw.: where is our `clone' command which clones WHATEVER?):
683 clone name=$1 base=$2 ext=$3 ACTION=$4([SEND_]MBOX|DISPLAY|etc)
684 if $name =~ 'README|INSTALL|TODO|COPYING|*.(txt|rc|cfg|conf)$'
687 return 'application/gzip'
688 elif $ext =~ '*.\.nim$'
689 return 'text/x-nimrod'
691 varshell i /usr/bin/file --preserve-date $name
695 Also interesting would be the possibility to let a macro BE the
696 (forked+exec, I/O redirected) external handler, "returning the
698 Inspired by Gavin Troy and Bob Tennent.
699 . Check cmd_tab.h <-> POSIX:
700 The following commands shall be invalid in the start-up file: !,
701 edit, hold, mail, preserve, reply, Reply, shell, visual, Copy,
702 followup, and Followup.
703 Add setenv, unsetenv etc. But that shouldn't be covered by the
704 ARG_I bit, but we need another one; setenv and unsetenv currently
705 explicitly test for the "starting" variable. (That+ should be
706 a bit(s) anyway, see elsewhere in this file.)
707 .. NOTE: POSIX also has a clear idea on what variable comes in from
708 the environment and which not. This was actually adjusted
709 accordingly in the manual after v14.7.1, but we don't really honour
710 it; since our -S mechanism now works correctly it is possibly
711 a good idea to again make a *true and real difference* in between
712 external variables that will be overtaken from the environment and
713 internal variables, which *may not* come in from the environment.
714 They may however override values which (are allowed to) come in
715 from the environment -- that is, for those we should force
716 overriding via setenv even upon startup! (Add a FROMENV flag for
717 enum okeys, and handle it somehow like special!)
718 ... While here: variables with a defined fallback value (like LISTER
719 <- XLISTER, SHELL <- XSHELL etc.) should RETURN the fallback
720 value, i.e., the following should NOT be necessary:
721 if ((sh = ok_vlook(SHELL)) == NULL)
723 but be done automatically -- why not have yet another enum okeys
724 flag that names a preprocessor macro, as in fallback=NAME?
725 ... More on variables above!
726 ... fexpand() the 2nd: it should return structure because we need to
727 check for FEDIT_SYSBOX, which currently only checks wether the first
728 character of a file name is '%', not wether it is '%', '%:FILEPATH'
729 or '%VALIDUSER', because that is impossible to do!
730 ... ALL OF THAT: another fexpand() thing below!!
731 . On the long run in-memory password storage should be zeroed after
732 use, possibly even encoded *during* use. After v15.
733 . Add direct support of gpg-agent(1) and add *agent-lookup* (requires
734 libassuan, but is so much more performant than *agent-shell-lookup*).
735 Then again, how about either adding a special config variable or
736 interpreting the very first character of *agent-shell-lookup*
737 specially in order to support caching of looked up passwords?
738 Let it be a number in seconds as necessary?
739 . Try to deal with invalid MBOXes: if a final MIME boundary is seen,
740 don't require the separating newline before the from (when reading
742 . We need a `spamcheck' command that is like `spamrate' but updates
743 the mail in-place, i.e., with the headers that the spam engine adds.
744 . My signal handling is pretty messy, too. E.g., for the new spam
745 handling we even reset TTIN etc. etc., whereas for
746 *agent-shell-lookup* we don't do just about anything. Even though
747 it work (due to stacking of handlers all over the place etc.), but
748 we need to have a clean design at some later time.
749 . How hard would it be adding support for mixmaster?
750 . lex.c:__narrow_suffix() is wrong (for stateful encodings that we
751 don't support yet) and should inject a reset sequence if it shortens
753 .. Ditto field_put_bidi_clip() and possibly more.
754 .. THAT IS TO SAY: the entire codebase doesn't really support stateful
755 encodings, including the bidi_ things that i've done (but the NCL
756 does iirc? what is this??). We should have a global string that
757 has the multibyte reset sequence plus length available for easy
759 . Note (for v15.0 most likely): when quoting an original message then
760 if that doesn't end with a newline we should automatically add one.
761 I thought about hacking it in via quoteflt in the meanwhile??
762 .. We want this stuff also for message specification btw., look at
763 NetBSD Mail in particular. (I.e., the parenthesis are yet taken by
764 IMAP searches, but if sole parens are separated by WS, maybe?)
765 . When a user edits a specific header, it should no longer be
766 modified. This unfortunately requires v15.0 infrastructure.
767 . Regular expression list resorting is no good; the user should be
768 able to specify a match order weight, as in:
769 mlist 10 a@b.org 8 c@d.org .*@else@org 0 almost@never.com
770 So: optional digit 0-10, where 0-4 are never relinked and always
771 placed at the tail, 6-10 are never relinked and always placed at
772 head (all in decreasing order, head to tail), and 5 is the implicit
773 value, placed in between and automatically resorted just as is the
774 sole algorithm we currently have.
775 .. And maybe we should have an event mechanism with one-shot etc..
776 Then install a resorter function when we actually have lookups and
777 one-shot sort the entire thing once (when the loop ticks).
778 Instead of busy resorting, that is.
779 . Some pieces of cake (e.g. usermap()) don't perform actions on
780 addresse(e)s if the first character is a backslash. Others do.
781 And do we really support that notion all through the codebase.
782 And, even more: should we support that at all?
783 . The var_* series should return "const char*" not "char*".
784 This should already work today because otherwise we would get SEGV
786 .. Now that we have flags and VIRTUAL variables we can very well
787 extend that and provide an additional set of DEFVAL. On the one
788 hand it doesn't make sense to do all those first-time-inits due
789 comply to POSIX compliance, because many get vanished again when
790 the resource(s) is (are) loaded; many others are never ever needed,
791 but still require dynamic memory. Better to have DEFVAL and
792 a init-on-first-use for those which have this set.
793 .. I think it would really be better if localopts handling is replaced
794 by an "environment" with copy-on-change adjustments via reference
795 counting. (But not before we have a signal manager.)
796 . We need more hooks: on-leave, on-connect.. whatever
797 . callforeachexec MACRO SHELL..STUFF..
798 -> MACRO called with each line read (in $1 ...)
799 . fio.c:_globname() is a security risk, but anyway the current POSIX
800 definition of wordexp(3) is a joke (Rich Felker,
801 gmane.comp.security.oss.general-15785). Beside that.
802 What can be encapsulated in the v15.0 URL object (scheme:// prefix).
803 Otherwise and in addition: change semantics in v15.0, support POSIX:
804 Several unquoted special characters shall be recognized when used
805 as file names, with the following substitutions:
806 % The system mailbox for the invoking user.
807 %user The system mailbox for user.
810 +file The named file in the folder directory. (See the folder variable.)
811 --> Transition to internal mechanism started with topic/fexpand.2.
812 .. The new internal expansion mechanism should possibly get support
813 for POSIX parameter expansions ${[:]-} and ${[:]+} (and ${[:]?}).
814 There is no real way to get the functionality otherwise...
815 . struct ignoretab and handling can be merged with the new generic
816 struct group stuff (with some effort) and localized in nam_a_grp.c,
817 then. Then -- rename that file to grpignnam.c?? :-)
818 . run_command()++: when we change TTY modes then if we "release" the
819 terminal to child processes (note STDERR...) then we should
820 proactively reset before exec and reinstantiate once the child has
821 finished. Maybe the former anyway. I.e.: don't rely on the shell.
822 Also, if our stdin is a pipe we possibly want to adjust that for the
823 child instead of simply leaving the fd alone, which isn't an
824 impossible case as of today.
825 . Make S/MIME an option separate of SSL/TLS, i.e., optional.
826 . Read https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07.
827 Can we implement OCSP (see RFC 6066)????
828 . With very long input Heirloom mailx(1) / S-nail(1) can produce
829 encoded-words (RFC 2047) with incomplete multibyte sequences (i.e.,
830 non self-contained encoded-words).
831 . Group addresses, especially the undisclosed recipients but also
832 "Bla": addresses; are missing.
833 . The interface must be straight. "history clear" -> "unhistory".
834 Ugly but straight. And ditto all the stuff in equal spirit.
835 . ~@: comma-separated list input should be possible even for filenames
836 which include commas, proper quoting provided. Adjust manual
837 . It is terrible that -S sets variables twice, at once and after the
838 resource files have been loaded. Instead we should look for
839 PS_LOADING and simply don't overwrite variables that are yet set; of
840 course this interferes with the plain basic settings which we yet
841 establish for POSIX compliance -- i.e., first we need a compile-time
842 automatism for those, thereafter... Ok we still need a bit to mark
843 them, but isn't it worth the effort.
844 . The Base64 decoder must become a filter with its own buffer, so that
845 we can join splitted sequences etc.; yes, that is invalid, but we
846 should be tolerant (tolerant on input, strict on output - right?).
847 mutt(1), e.g., even tolerates characters that are invalid ($,!,?++)
848 and simply ignores them. This is great on the one and shit on the
849 other hand -- if like that, the error ring should at least mention
850 that the message WAS FAULTY. E.g., mutt(1) ignores long,long
851 sequences of those bytes, which i don't consider a good thing..
852 And then, should we (really, see mime_enc.c) make a difference in
853 B64_T and B64, ... and regarding this??
854 . OPT_INTERACTIVE and ARG_I are two different kinds of
855 "interactivity". The latter should be "non-loading/sourcing".
856 . Cleanup: mime_param.c uses _ALPHA_, urlcrecry.c uses ALPHA_. Unify
857 that across all sources / headers, full recompile test anywhere
859 . Several facilities can use table-based settings: colour-stuff
860 (auxlily.c), ccred_lookup() (maybe including availability error
862 . *smime-sign* (*asksign*) i would like to see in all XOK forms, yet
863 today the credentials are looked up after variable check, in fact
864 even conditionalized on wether signing is desired or not.
865 . Per-folder (S/MIME) en- and decryption key (Tarqi Kazan): if a xy
866 variable is set (that points to a key) add a transparent en- and
867 decryption layer on top of any per-message operation (for boxes for
868 which the variable is set).
869 . For v15.0: remember private thread with Tarqi Kazan (2015-05) and
870 try to improve situation with *record*, so that only messages enter
871 it which have really been sent. If we support postponing and have
872 a multi-process layout and add an intermediate *record-queue* we
873 may be able to improve the situation.
874 . All of OPT_INTERACTIVE, (OPT_SENDMODE,) OPT_UNICODE, OPT_TTYIN,
875 OPT_TTYOUT should not be user_options but instead program_state
880 . We can "steal" features from msmtp(1) that make sense: SOCKS support
881 (primitive) and /etc/aliases ($mta_alias_file). At least postfix(1)
882 supports file and pipe addressees in the latter... It also
883 supports include files via :include:/filename but which i think
884 should be supported in a second step. Ditto caching (timestamp
885 check and a mechanism to support/disable caching.)