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.
38 - We need a "void" box that can be jumped to, i.e., a state in which no box
41 -- When a MBOX mailbox is removed while it is opened then changing the
42 folder is not possible. This is an inherent problem of the Berkeley
43 Mail codebase, and we need to have a fully functional intermediate
44 VOID box mechanism plus an object-based mailbox implementation to
47 -- Also, when the folder was modified concurrently we should bail, or,
48 in an interactive session, prompt the user what to do.
50 - IDNA decoding. Needs a complete design change.
54 - mutt(1) quotes all text parts of a message, not only the first one!
55 This should at least be optionally available.
57 - If pipes fail for part viewers then at least the usual PART X.Y should be
58 shown, maybe even including some error message.
59 I had 'set pipe-text/html="lynx -dump -force_html /dev/stdin"' but NetBSD
60 does not have lynx(1), and i thought i've found a S-nail(1) bug.
62 -- Also, when we run a pipe handler asynchronously there should possible
63 written something like [pipe-handler xy started] or something
65 - Offer the possibility to work with certificate fingerprints instead of
66 full certificates, in equal spirit to the current maintainers S-Postman
67 and Mercurial. S-nail(1) could simply offer something in equal spirit to
68 the formers --fingerprint, so that no other tool is necessary for
69 certificate management (for at least secure transport).
71 - It would be nice if it would be possible to define a format string for
72 *quote*, like 'set quote="format=some formats"'.
73 In general the current approach is somewhat messy IMO. I.e., it would
74 make more sense to act rather like mutt(1) and as written elsewhere in
75 this document, i.e., have some toggles that act on the display and use it
76 for multiple modes (show/reply/forward etc.)
77 Otherwise introduce commands which include all the headers plus, e.g.,
78 "hreply" or "freply", and then the ditto series, i.e., "hReply" ...
80 -- This would also mean that interactive message editing would work
83 - Command line editing should gain possibility of context sensitive tab
86 - Maybe there should be an additional ZOMBIE directive that is served in
87 equal spirit to DEAD, but that could be a valid MBOX... ?
88 What i want is a *real* resend, best if possible from command line.
89 Meaning, also the possibility to postpone a message. In general.
91 - Having a newsreader would be a really cool thing. (RFC 977 and 2980)
93 - There should be a way to ignore the From_ line, as opposed to the From:
94 line, i.e., distinctively.
96 - There should be a variable that controls wether leading and trailing
97 empty lines of parts and/or messages as such should be printed or not.
99 - printhead()/hprf(): support %n newline format (%t tab?).
100 Make it possible to use the *datefield* algorithm for plain From_ derived
101 dates (needs a From_ parser, i.e., strptime()-alike).
102 Once we have that, rename *datefield-markout-older* to
103 *date-markout-older* ??
104 Note that NetBSD's mail(1) has some other nice things.
105 Note also that our code is quite unflexible.
107 -- NetBSD's mail(1) has nice *indentprefix* and *indentpostscript*
108 variables (though prefix and appendix or prefix and suffix, but..).
109 Note that our code is quite unflexible.
111 - The "top" command should honour ignoretab, or there should be a very
112 special "top" ignoretab. It simply doesn't make sense to "top" 5 lines
113 when all that you get are Received: lines...
115 - In the very end it is not that hard to add (optional) MTA
116 functionality at a most simple level.
117 Use sqlite for aliases (and possibly cache), then.
119 - We should support IMAP compression over the wire.
124 - Improve name extraction rules. And field parsing. There
125 are structured and unstructured fields. There are quoted pairs and
126 comments etc. Rewrite the entire parsing mechanism to comply to RFC
127 5322, and try to merge all those many subparsers around in the codebase,
128 and accordingly. So much duplicated work ...
129 Name parsing has been improved a bit for v13, but it's still broken.
130 yankword(), *extract(), etc.: RFC 5322 says that comments in address
131 fields SHOULD NOT be used (mutt(1) maps them to full name-addr forms if
132 approbiate, even if that actually changes content!!?), and that full
133 name-addr SHOULD be used. Our functions are yet quite silly (i.e.,
134 leading comments remain, as in "(bier2) <a2@b2.de>", unless the address
135 doesn't come in angle brackets, trailing go away, as in "<a6@b6.de>
136 (bier6)", that becomes "<a6@b6.de>").
138 (co$mm1) abc@däf.de (cö,mm,2) ('c'o"m"m.3)
139 Should eventually become
140 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@xn--df-via.de>
141 on the display, or, with IDNA decoding (and thus rather unlikely)
142 co$mm1 cö,mm,2 'c'o"m"m.3 <abc@däf.de>
143 It should NOT become this mutt(1)ism:
144 "co$mm1 cö,mm,2 'c'omm.3" <abc@däf.de>
147 -- Think about a name bypass hashmap cache, and whenever we have to skin or
148 nalloc() or whatever, look in there. Maybe even an additional link for
149 non GFULL(/GSKIN) and fully skinned struct name objects.
150 The amount of duplicated work in this codebase is frustrating, but the
151 real healing would make necessary a complete rewrite of the name handling!
152 Such a cache would work without touching the current code flow ... or
153 allow a smooth transition to a new one anyway.
155 ++ NOTE: 'alternates' tracking happens BEFORE we enter composing, this
156 means that an account switch during message composing will NOT cause
157 reevaluation of all that very very clumy
158 elide/delete_alternates/gexpand/is_myname etc. handling.
160 - The char classification stuff can be improved; currently each character
161 has exactly one classification bit set, even if multiple would apply
162 (e.g., HT=\t == CNTRL|SPACE|ASCII|BLANK). This would allow better
163 testing using our own classification functions in quite some places.
165 - The quoted-printable Content-Transfer-Encoding: supports soft linebreaks;
166 it happens that a lot of mailers (Apple Mail?, Microsoft Word, Yahoo!
167 Webmail) create HTML parts which solely consist of a single line,
168 created via soft linebreaks.
169 To handle such mess we need to be able to break out of the input-line ==
170 output line relationship that is still fixated in the codebase.
171 I.e., it is not even sufficient to convert "rest" into an array, but best
172 would be if we would be able to sequentially work what we have, and
173 detect when it is safe to "dump that out".
174 This MUST be part of the send/mime layer rewrite in 15.0.
176 -- In v15.0, when we can address attachments of a message individually,
177 it would be nice to provide even more access, just like nmh(1) does
178 (Johan Commelin: Are s-nail and mh related?).
180 - I never used anything but the *datefield* option, and it would really be
181 nice if the date strings would be parsed off into some 16 byte or what
182 storage when about to producing the summary, so that it would be directly
183 available and there would be no need to reread the mail. Moreover, or
184 even more than that - the m_date field exists and should possibly simply
185 be init, at least in these cases. (P.S.: this doesn't contradict the
186 statement somewhere else in this file that the structure should be
187 slacked; simply use multiple thereof or so)
189 - All error messages should not go to stderr but instead we should add our
190 own n_warn() family and use that. In the background we should have
191 a ring of error messages (oldest fall off), and a command that is capable
192 to display the ring. The command loop should recognize whenever an error
193 happened during the last command, and print something like "XY errors
194 occurred", followed by a (truncated as necessary) error report.
195 It simply doesn't make any sense to print errors on stderr if normal
196 output goes to stdout and scrolls it off the screen.
197 Note that yet some errors messages still go to stdout.
199 - It would be very nice if it would be possible to have
200 account-specific macros that will be lost when a user switches off
203 -- It would also be very nice if we could define macros while defining
204 account, i.e., recursive definition of macros...
206 - At some later time extend the logic behind -# -- it should not have
207 a current folder, but start in VOID mode (...), and unless one is
208 explicitly chosen.. We need a reliable batch mode.
210 - (Support for mailcap files? As of RFC 1524? Unlikely. Though the
211 % expansions would be very helpful, especially once we can address
212 individuals parts as of v15.0!)
214 - After I/O layer rework we should optionally be able to read RSS
215 (Atom?) feeds -- Expat should be available almost everywhere and
216 should be able to parse that?
217 Atom is harder because it may support html+.
218 I mean, yeah, it's stupid, but we could fill in header fields with
219 dummies and still use S-nail to look into the separated feeds as if
220 they were mail messages; anyway i would like to save me from using too
221 many tools -- three seems reasonable.
223 - Add TODO notes for those RFCs:
224 RFC 5322 - The basic format of email messages.
225 MIME (Multimeda) email extensions
226 RFC 2405 - The format of MIME message bodies.
227 RFC 2406 - Common multimedia types.
228 RFC 2017 - URL External-Body Access-Type
229 RFC 3676 - Updates to the text/plain MIME type and extensions for flowed
230 text (format=flowed). (Martin Neitzel)
231 RFC 2407 - Encoding of non-ASCII text in message headers.
232 RFC 2183 - The Content-Disposition Header
233 RFC 2231 - Encoding of character set and language information in MIME
235 REALLY! We currently use RFC 2047 encoded words to encode
236 filename="" stuff which is plain wrong.
237 also we don't decode this at all!
238 SMTP (Simple Mail Transfer Protocol)
239 RFC 5321 - Simple Mail Transfer Protocol.
240 RFC 6409 - Message Submission for Mail
241 RFC 4954 - SMTP Authentication
242 RFC 3207 - SMTP over TLS
243 RFC 6152 - SMTP Service Extension for 8-bit MIME Transport
244 Post Office Protocol (POP)
245 RFC 1939 - Post Office Protocol v3
246 RFC 2449 - POP3 Extensions (including SASL)
247 RFC 2595 - TLS for POP3 (among others)
249 RFC 4422, 4505 - Simple Authentication and Security layer (SASL)
251 RFC 5246 - Transport Layer Security (TLS)
252 RFC 977 -> 3977 - Network News Transfer Protocol
253 RFC 1036 - Standard for USENET Messages
254 RFC 2980 - Common NNTP Extensions
255 RFC 2387 - multipart/related
256 RFC 2384,1738 - I.e., Much better URL support
257 RFC 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME)
258 RFC 6125 - Representation and Verification of Domain-Based Application
259 Service Identity within Internet Public Key Infrastructure Using
260 X.509 (PKIX) Certificates in the Context of Transport Layer Security
263 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery
264 Status Notifications (DSNs),
265 An Extensible Message Format for Delivery Status Notifications
267 - This is how the codebase has to be reworked in respect to signals and
270 1. We introduce some environment/carrier structs: struct eval_ctx,
271 struct cmd_ctx, (struct send_ctx). All of these form lists.
272 eval_ctx gets a new instance every time evaluate() is entered; for
273 the interactive mode, commands() instantiates an outermost eval_ctx
274 that "cannot be left".
275 cmd_ctx knows about the eval_ctx in which it is was created; it is
276 created for each command that has an entry in cmd_tab and is passed
277 as the new argument of these kind of functions.
278 (send_ctx is the carrier for the MIME and send layer rewrite.)
279 2. We'll get a signal manager. This is a global layer which is the
280 sole object-in-charge for signals. We'll install a complete set of
281 handlers once -- those will only set has-occurred bits.
282 All interested parties have to peek at the signal manager when they
283 are in the position to deal with signals, via a series of
284 "ha(s|ve)_occurred", "needs_action", "would_raise" or whatever, as
286 3. We need a sort of non-local return, everything else would require
287 a totally different way of programming. Also, non-local returns
288 are not *that* bad, generally speaking. We'll be easy and add the
289 possibility to define a jump target location in eval_ctx and
290 cmd_ctx, by peeking at the signal manager (for object design
291 reasons, though done by a macro, say), just like saying "i need to
292 have the chance to perform some actions shall a jump be necessary".
293 4. So, somewhere deep down the still recursive codebase, shall the
294 necessity to honour a jump request occur, we peek the signal
295 manager to "unroll" the current cmd_ctx/eval_ctx chain(s), which
296 will result in none-to-multiple jumps to locations which require
297 cleanup actions, ultimately ending in the non-leavable commands()
298 eval_ctx or whatever.
299 6. Hot: we save us from thousands of syscalls, and get rid of the
300 fucking sig* shit. It rhymes, it rhymes :)
301 Should we even be able to go the non-blocking select(2) way in the
302 end -- that would be fantastic!
303 10. The line buffer used in evaluate() that is passed through to
304 commands (thus: in cmd_ctx, then) needs to become `const'.
305 (I tried to do so in the past, but some commands write into it,
306 thus i stopped and iirc even added some changes on my own which
307 take favour of reusing that buffer.)
308 + Macro execution then no longer needs to clone the macro content
309 lines before executing then.
310 11. Macro execution is potentially recursive. Meaning that
311 `undefine', etc. can occur while macros are executing.
312 The simplemost approach would be to have some recursion counter for
313 each macro and a delete_later flag that gets honoured when the
314 recursion counter gets zero. It would be already possible to
315 immediately remove the macro from the hashtable, so that deeper
316 levels wouldn't find it anymore. To avoid leaks (which *are*) we
317 need to have a jump location for our upcoming signal handler
318 anyway. (Also to get rid of the temporary_localopts_free() hack.
319 + The same is true for `account's. Here things are complicated by
320 the global `account_name', i.e., the account could be the current
322 12. It is annoying that you cannot `source' your MAILRC multiple times.
323 Defining a macro/account/xy should overwrite the current thing,
324 just as it does anyway for normal variables!
325 This is no different than 11. plus additional re-addition.
326 (Same exception: what if the currently active account is
327 overwritten? Same answer, plus a message "new settings take effect
328 when account is switched to the next time".)
329 20. The attachment charset selection loop can then be rewritten to
330 check wether an ^C occurred and treat that as end-of-loop
331 condition. In v14.6.3 this was introduced, but it should act
332 differently depending on wether the interrupt occurred during
333 character set selection or attachment filename input.
334 Also in respect wether the interrupt is "propagated" or not.
335 It's ugly, and documented accordingly.
336 30. Mail protocols and mail messages are accessed through a "VFS".
337 URL should then support file:// and maildir:// etc. Update manual!
338 31. Flag updates of individual messages must find their way through to
340 32. Use deque (on partial views).
341 33. It must be possible to open individual boxes read-only, new command
342 `cfile' (and `cfolder') as a last resort.
343 34. We need a new abstraction: `vie[ws]'. I.e, viewset, viewclear,
344 view(show|look)? We will have (possibly readonly) boxes, a summary
345 cache file, which is created when a mailbox is read in, and all
346 that crap that we currently have (setptr(), setmsize(), etc.!) must
347 vanish. Instead there is another, in-memory abstraction, the view.
348 Some views are builtin and are somehow selectable (the "all" view,
349 for example, and the "new" view).
350 It is possible to make a view persistent by giving it a name, e.g.,
351 'viewset NAME MSG-SPEC' -- 'viewset allnew :n' (and 'viewset XY `'
352 or something must be capable to tag the last a.k.a current).
353 Switching to a named view would thus look over the entire current
354 view (!) for all messages that comply to the message-spec of the
355 view, then create a sorted/threaded display of that subset and
356 create a new anonymous "result" view. It must be possible to
357 specify that a view is to be applied to the entire mailbox instead
358 of the current view, via a simple easy understandable syntax.
359 50. Support SASL, unite all GSS-API etc. under an abstraction!
360 Maybe even drop direct GSS-API and support only through SASL.
361 That is, we can very well provide our own little SASL-client
362 abstraction with what we have already by simply defining some
363 "readline" abstraction plus struct ccred for use by the
364 authentication layer: the protocols must set it up by passing in
365 a line of authentication mechanisms and a callback mechanism.
366 Possibly the user should be able to permit or forbid automatic
367 selection of GSS-API (to avoid useless round-trips) etc. etc.
368 99. Now i'm dreaming some more: with the new object-based approach
369 multiple mailboxes could be in an open state. And it should be
370 possible to do so for the user (`file' and `folder' are required to
371 quit the current mailbox [first -- this not yet]), which is why we
372 either need new trigger characters or new commands (then also in
373 a readonly version, again, it gets lengthy).
374 The absolute sensation would be joinable operations over multiple
375 open mailboxes, e.g., views over multiple such!
376 100. If i say `p 3 2 1' then i mean `3 2 1' not `1 2 3'.
381 - Deal with faulty message selection that may occur when selecting threads
382 via & (when at least mixed with other selectors).
384 -- Also (?same problem?) the thread sort doesn't get
393 The current sort fails to recognize that F and the thread starting at
394 B are related, which results in a mess.
396 - Drop **use-starttls* in favour of something better: support 'auto',
397 'no' and 'yes' and act accordingly. For the former be smart enough on
398 the protocol side. (RFC 3207 describes man-in-the-middle attacks due
399 to 'auto' TLS, so explicit 'yes' should be favoured).
401 - NOTE: we do not really support IPv6 sofar in that we are not prepared to
402 deal with IPv6 addresses (as in '[ADDR]:PORT'). Pimp url_parse().
405 - mutt(1) dotlock ..., "mbox" command doesn'T work?
407 - ARGH! Should `folders' auto-login if *folder* is an IMAP account that is
408 not active? Why does _expand() use *mailname* to expand `@', not
409 getfold() (care: res may point into cbuf, savestr() or so!).
410 Why does demail() etc. treat *mailname* as a file (more or less), why do
411 we need *mailname* at all; we should have Folder objects, multiple of
412 which concurrently, one the active; a Folder may not become *folder*
413 unless it has write (store) capabilities). Maybe then `mbox' works fine
414 if connected to a POP3 server with a *MBOX* on an IMAP account that yet
415 never was connected and needs to read a password on the terminal before
416 the login works ... note the latter situation yet kills us since i think
417 INT is blocked during all that ;-((
419 - I had a connection collapse during a POP3 download, and neither was
420 there a chance to get access to the 22 yet downloaded mails (after
421 five minutes of waiting followed by CNTRL-C), nor did the layer
422 recognize this very well (got myriads of `POP3 connection already
423 closed.' messages, btw., the thirty-something messages which were not
424 yet downloaded caused (after CNTRL-C) this: ETC. ETC.
426 - Add a value-duplication command, i.e.,
433 - Add a boolify() function, so that things like `localopts' and yorn()
434 may be less strict on user input
436 - Ensure that `.' and EOF on a line works with all TTY modes (*ignoreeof*
437 relationship, too)! EOF conditions in general!
439 -- NCL / current expand-on-tab: fexpand() should take additional size_t* to
440 store the number of the results OR should "return char** array", so that
441 individual results can be addressed.
442 Then we could simply print "\nALL-RESULTS\n" and NOT expand the current
443 line if the result is ambiguous, i.e., we have more than one possible
445 However, we would then need something to print the results page-wise,
446 in case we have so many of them that they don't fit on the screen.
449 - I got an email in base64 that obviously used CRNL line endings, and once
450 i've replied the CR where quoted as *control* characters.
451 Get rid of those (kwcrtest.mbox; may be hard to do everywhere for some
452 time, due to how we deal with I/O and Send layer etc).
454 - edit.c doesn't do NEED_BODY (but IMAP won't work anyway).
457 .. s-nail </dev/null should work interactively when STDERR_FILENO is
458 a terminal! (Builtin editor; how do editline and readline work?
459 should this be documented? What does NetBSD Mail do? Should we NOT
460 be interactive?? POSIX says for sh(1) (APPLICATION USAGE): 'sh
461 2>FILE' is not interactive, even though it accepts terminal input.)
462 . Automatically track message attachments when switching off the
464 NOTE: 'alternates' tracking happens BEFORE we enter composing, this
465 means that an account switch during message composing will NOT cause
466 reevaluation of all that very very clumy
467 elide/delete_alternates/gexpand/is_myname etc. handling.
468 We REALLY need an object based rework of all that.
469 . It would be cool if ghosts, shortcuts, alternates could
470 (optionally?) be tracked via localopts.
471 (Additional entry on xy-local xy somewhere above)
472 And / or local to a macro/account if defined in one.
473 . The spam* series (spam.c:_spam_action()) should abort if the command
474 execution failed, instead of iterating the entire list. Look into
476 . DESTDIR= should not be taken into account when deciding wether
477 a rebuild is necessary (not wrong to give that to Gaetan Bisson).
478 . Just like the RFC 3676 link above, it would be nice if it would be
479 somehow possible to recognize links in a document; i don't know yet
480 how this could be achieved without loosing formatting information (i
481 mean, we could enable this and inject terminal colour sequences, but
482 one should be able to say 'follow link x', starting an action
483 handler, and the 'x' must come from somwhere - simply injecting
484 '[NUMBER]' references distorts visual). Anyway, it's just a filter
485 that recognized the usual <SCHEME:/> stuff, and of course we can
486 simply have a buffer which records all such occurrences, so that
487 user can say '? xy NUMBER', but without the context it soon gets
489 . TTY layer: the tc*() family may fail with EINTR, which MUST be
490 handled; setting also generates SIGTTOU when we're not in foreground
491 pgrp, so we better deal with all that and ENSURE WE GET THROUGH when
492 resetting terminal attributes!
493 . Remove all occurrences of mbtowc() with mbrtowc(); temporarily add (some)
494 global mbstate_t objects until the send / MIME layer rewrite is done and
495 has the carrier. Use flip states and add aux funs with only update the
496 state+toggle on success -- CURRENTLY MBTOWC FAILURES ARE PRACTICALLY NOT
498 . Ypnose (linuxien AT legtux DOT org) pointed out that for the IMAP
499 cache we have some kind of UID validity check -- couldn't that be
500 used to perform some kind of automatic reconnection when we get that
501 much-too-frequent connection breaks in IMAP mode??
502 Also, and also for POP3, don't let the ALARM based (ugh! I'm
503 starting to dream wet from select(2), almost truly) timer blindly
504 tick, but restart it with a full interval when we did regular
505 conversation with a server. Don't forget the SSL timeouts (300
506 seconds) and their interaction with normal (user) keepalives.
507 Add a global *keepalive*, add *keepalive-USER@HOST*. (Add and use
508 a generic, single function to get the value for either protocol.)
509 . HAVE_HISTORY plus: for WANT_EDITLINE and WANT_READLINE the
510 mk-conf.sh yet always tests anything, i.e., we could fail due to
511 history related stuff even though the user doesn't WANT_HISTORY.
512 .. We should in fact convert our NCL history to a shared history
513 implementation, and only hook editline(3) and readline(3) so that
514 ^R and Cursor-(Up|Down) work as expected everywhere.
515 Like that we would have duplicate elimination for readline(3), too.
516 .. tty_addhist() should take a struct str. Anyway, evaluate() should
517 enter a history entry if the caller allows so, and it should trim
518 also trailing whitespace; also, the expanded command should be
519 stored, not the abbreviation, so that 'sst' and 'sstats' will no
520 longer produce two separate entries.
521 ... Because of laststring() and because the evaluate()d line buffer is
522 not constant history entries sometimes do not 100% reflect what
523 was actually present on the command line, but i refrained from
524 hacking a solution since that buffer must end up as a constant
525 (TODOs or so in the source).
526 . getprompt() could reserve for each dynamic entry at least one
527 visible offset, so that at least a `?' could be written if the room
528 is otherwise insufficient; in addition, if there were 3 such
529 dynamics, but all in all two visible offsets would be left, a single
530 entry with as much `?' as possible c/should be written, so as to
531 indicate the user anything visually.
532 . Make S/MIME an option separate of SSL/TLS
533 . pop3,mime_cte +++: \r,\n -> \015,\012, to avoid ANY problems..
534 . which_protocol(), *newmail* mechanism, displayname, mailname: all of
535 this <rude>SHIT</rude> must be rewritten completely and can be
536 overcome by an object-based mailbox implementation that carries all
537 the necessary state (user given path, expanded realpath(3),
538 abbreviated display path, box-protocol, etc.). Once we have this,
539 we may as well also re-introduce automatic detection of compressed
540 file-based folders based upon .gz/.bz2/.xz extension.
542 If not mentioned somehwere else: struct message should be splitted
543 into a tree of objects, with a base class that has as few fields as
544 possible; the global *message should be a deque, only accessible via
545 iterator; it should store pointers to (the actually used subtype of)
546 message structures instead; i.e., for maildir boxes the path is yet
547 allocated separately, then it could be part of the message object,
549 It should contain a ui8_t that tracks the number of contained parts,
550 so that the "fits-onto-the-screen" tests are more useful than today;
551 i think 8-bit is sufficient, with 0xFF meaning more-than-fits-here.
552 . Given how many temporary files we use, it would make sense to
553 support a reusable single temporary file, as in singletmp_take() and
554 singletmp_release(), where singletmp_release() would close and thus
555 drop the file if it excesses a specific (configurable) size, and the
556 mainloop tick would close it (after X (configurable) ticks))
557 otherwise. I guess this would improve performance for searching
559 . Searching code *could* perform a prepass, joining stuff together,
560 dropping useless cases etc.
561 But anyway: if there are multiple search expressions, it shouldn't
562 be an error if at least one of them matches at least one message.
563 . catset(3) is plain shit, and ever was. Remove IDs from all tr()s,
564 use GNU tools for extraction etc., and write a simple helper program
565 which converts these files to a serialized hashmap, just like we did
566 for the okeys (and *exactly* so); add a config check wether the ({})
567 extension is supported and finally use that for some ({static char
568 const *tr_res;}) injection optimization, then. (Think SFSYS)
569 . Searching body/text yet includes headers from attachments and
570 attachment data. This is shit. :)
571 . Btw.: (with IMAP) when opening a folder the hook gets executed after
572 the flags but before the headers are loaded, but for `newmail' it is
573 *after* the headers have been loaded.
574 . /* TODO *batch-exit-on-error*: sourcing and loading MUST BE FLAGS!
575 * TODO the current behaviour is suboptimal AT BEST! */
576 . There MUST be a way to specify that a single SPECIFIC box has to be
577 opened readonly. only the global -R flag is NOT ENOUGH!
578 . The "nifty" unregister_file()->_compress() mechanism that even
579 shovels '-Sfolder=imaps://user1@localhost -Srecord="+Sent Items"'
580 *records* calls clearerr() on the descriptor before performing it's
581 action anyway. when we really make it even to the I/O rewrite, it
582 should be possible to dis-/allow such -- it doesn't make sense to
583 add something faulty to whatever was not faulty before!
584 . The message from Andy Switala on nail-devel made me think about some
585 mechanism that invokes a macro after a message has been sent.
586 Unless macros can have args (or do we introduce $*/$@/$1..).
587 Even if the codebase will at some future time be stable and really
588 reliable, sending a message via multiple channels will never be
589 atomic, so that it would make sense for a user to be able to restore
590 *the complete message* in a save place if any of the sends failed,
591 but to remove it from our temporary place otherwise. A simple
592 version of this would be a matter of five minutes, but since
593 mightrecord() may internally (via _compress()) instantiate
594 a complete IMAP session and try to send incomplete data etc.,
595 and all that may jump, i refrained from doing so.
596 .. Note that mutt also has send-hooks with special triggers etc.,
597 which even allows setting some options which affect the mail to be
598 sent, like choosing a signing certificate dependend on the value in
601 1. init send carrier enough for allowing
603 3. fully initialize send carrier according to what is "final"
604 4. run trigger macros WHICH MAY MODIFY THE MESSAGE AGAIN, so
605 5. fully reinitialize the send carrier
606 6. pass the final message down the send/mime chain
607 . SMTPS never became a standard and :465 was already reassigned
608 (thanks, carriers), but if a user says SMTPS and doesn't specify
609 a port also then we could simply assume :465 because except NetBSD
610 noone has SMTPS in their /etc/services?
611 Or at least automatically restart a failed getaddrinfo() in the
612 SMPTS case (if EAI_SERVICE)?
613 (Ooops - i think this should go to Gianluca Ramunno!)
614 . `dp' prints EOF at the end of a thread even if unread messages
616 . [-- #2 : 41/2761, text/plain, 0001-Israel-DST-transitio --]
617 If not fit, it should do `...'
618 . When doing `~w FILE' and FILE cannot be written to (was a directory)
619 then the composed mail is lost completely, it seems we jump to the
621 . `resend' doesn't smime-sign.
622 . Really do extend the test already today; test S/MIME
623 signing/encryption/decryption with two pairs of identities, instead
625 . RFC 5751 describes a message multipart layout that also includes the
626 headers in the signature; it would be nice (for completeness sake)
627 to be able to support that.
628 . The capability to save a message under the name of a recipient is in
629 the standard etc., but i've never used it.
630 What would be cool, otoh, would be if there would be the possibility
631 to register a regular expression, and if just *any* recipient of
632 a message matches, store the message in the given folder instead.
633 I.e., if i send a message to s-nail-users@ then i most likely want
634 to get a copy to the corresponding box, regardless of whoever the
635 message was sent To: Cc: or Bcc: else..
636 . In my ~xother with *nohold* if at the begin i have many large
637 messages i ended up with a truncated *mbox*? what was that?
638 . Things like colalign(), makeprint(), colour*, as well as
639 possibly even cmd1.c:(__hprf|putindent)(), etc. belong into a cui.c,
640 display.c or the like, but not into auxlily.c etc. for sure.
641 Also writing a range of headers should be done through an
642 iterator-thing with setup/finalize init/destroy life cycle, which
643 would encapsulate the entire cmd1.c:_print_head() in the single
644 iterator setup function!
646 defined HAVE_SETLOCALE && defined HAVE_C90AMEND1 && defined HAVE_WCWIDTH
647 into HAVE_NATCH_CHAR, solely keep that
648 . Using -t should still optionally offer an option to enter editing.
649 Also we should support command line arguments on top.
650 Add a -T flag for that. Drop -q, let -T mean the same if no header
651 fields are given (i.e., header fields are not mandatory as with -t).
652 ANYWAY: -t and -q are mutual, enforce that (yet done?)
653 While there, it should be possible to send non text/plain for
654 -q/-t, i.e., perform MIME classification; v15.0 and not only this,
655 why not simply sucking in complete MIME messages via -t?
656 (Brezn Stangl, brezn DOT stangl AT yandex DOT com)
657 . mutt list handling (`~') is very powerful
658 . Check what happens if an account switch or a network connection is
659 done while we are loading the resource files...
660 . We have some use of *at() functions, especially anything which
661 temporarily switches cwd.
662 . *newmail* is terrible. At some later time we need to do somethings
663 with timeouts etc. (for MBOX and Maildir it's not that bad, but for
664 anything over the network, yet the mentioned may come in over NFS).
665 Remove it until we have something better?
666 . The :d modifier is extremely useless even though POSIX compliant (No
667 deleted message or deleted message header shall be displayed by any
668 mailx command other than undelete.)
669 If i say p:d or f:d it should work.
670 . The RFC 3798 *disposition-notification-send* mechanism is yet not
671 truly conforming (and works with *from*). Also, this is only the
672 sender side, there should be support for creating the MDN response.
673 (Maybe ternary option: off (default),
674 create-when-unread-flag-goes-away, ditto-but-also-strip-header)
675 .. Also, there is DSN as a SMTP extension, see the RFCs 3461, 346 (as
676 above) and 6522 (Wikipedia).
677 . Add a env_blook()/env_vlook() series like that: add a FROM-ENV bit
678 to variables; use the normal var lookup, but even if found, when
679 FROM-ENV not set, use getenv(3); question yet open is wether that
680 value should then override what we have; in fact i think we should
681 possibly during loading phase act like this automatically for *all*
682 variable settings, i.e., settings from the environment MUST override
683 settings from ressource files UNLESS command line arguments
684 explicitly override anything else. That is pretty shitty, which
685 makes me think that we should possibly iterate over environ(3) and
686 explicitly overtake all values therein, or at least those which have
687 a meaning for S-nail; this needn't be as expensive as it sounds.
688 . The *sendmail** variables should have been replaced by *mta** in
690 . We should support more named colours, enabled via a, e.g.,
691 *colour-plus*, but provide downgrade colours for given colour names
692 if that isn't set. (Gavin Troy)
693 . I want *pipemac* (or *pipe-hookXY*). This requires v15.0
694 infrastructure (pseudo: evaluate() returns enum eval_retval{OK=0,
695 ERR=1, ISMAC=0x80, MACOK=ISMAC|OK, MACERR=ISMAC|ERR}; new `return'
696 command which only works in an executing macro (care: recursion);
697 macro arguments in pseudo variables $1...$x (works?); `return' can
698 "return" a list (simply keep argument list around); macro execution
699 can then simply check the return value to decide what to do (no
700 jumping); btw.: where is our `clone' command which clones WHATEVER?):
702 clone name=$1 base=$2 ext=$3 ACTION=$4([SEND_]MBOX|DISPLAY|etc)
703 if $name =~ 'README|INSTALL|TODO|COPYING|*.(txt|rc|cfg|conf)$'
706 return 'application/gzip'
707 elif $ext =~ '*.\.nim$'
708 return 'text/x-nimrod'
710 varshell i /usr/bin/file --preserve-date $name
714 Also interesting would be the possibility to let a macro BE the
715 (forked+exec, I/O redirected) external handler, "returning the
717 Inspired by Gavin Troy and Bob Tennent.
718 . Check cmd_tab.h <-> POSIX:
719 The following commands shall be invalid in the start-up file: !,
720 edit, hold, mail, preserve, reply, Reply, shell, visual, Copy,
721 followup, and Followup.
722 Add setenv, unsetenv etc. But that shouldn't be covered by the
723 ARG_I bit, but we need another one; setenv and unsetenv currently
724 explicitly test for the "starting" variable. (That+ should be
725 a bit(s) anyway, see elsewhere in this file.)
726 .. NOTE: POSIX also has a clear idea on what variable comes in from
727 the environment and which not. This was actually adjusted
728 accordingly in the manual after v14.7.1, but we don't really honour
729 it; since our -S mechanism now works correctly it is possibly
730 a good idea to again make a *true and real difference* in between
731 external variables that will be overtaken from the environment and
732 internal variables, which *may not* come in from the environment.
733 They may however override values which (are allowed to) come in
734 from the environment -- that is, for those we should force
735 overriding via setenv even upon startup! (Add a FROMENV flag for
736 enum okeys, and handle it somehow like special!)
737 ... While here: variables with a defined fallback value (like LISTER
738 <- XLISTER, SHELL <- XSHELL etc.) should RETURN the fallback
739 value, i.e., the following should NOT be necessary:
740 if ((sh = ok_vlook(SHELL)) == NULL)
742 but be done automatically -- why not have yet another enum okeys
743 flag that names a preprocessor macro, as in fallback=NAME?
744 ... fexpand() the 2nd: it should return structure because we need to
745 check for FEDIT_SYSBOX, which currently only checks wether the first
746 character of a file name is '%', not wether it is '%', '%:FILEPATH'
747 or '%VALIDUSER', because that is impossible to do!
748 . On the long run in-memory password storage should be zeroed after
749 use, possibly even encoded *during* use. After v15.
750 . Add direct support of gpg-agent(1) and add *agent-lookup* (requires
751 libassuan, but is so much more performant than *agent-shell-lookup*).
752 . Try to deal with invalid MBOXes: if a final MIME boundary is seen,
753 don't require the separating newline before the from (when reading
755 . My signal handling is pretty messy, too. E.g., for the new spam
756 handling we even reset TTIN etc. etc., whereas for
757 *agent-shell-lookup* we don't do just about anything. Even though
758 it work (due to stacking of handlers all over the place etc.), but
759 we need to have a clean design at some later time.
760 . With very long input Heirloom mailx(1) / S-nail(1) can produce
761 encoded-words (RFC 2047) with incomplete multibyte sequences (i.e.,
762 non self-contained encoded-words).
763 . How hard would it be adding support for mixmaster?
764 . We need to ensure that pipe hooks can access $TMPDIR in their
765 environment and that $TMPDIR is a valid accessible directory.
766 While here we could also create a temporary name that doesn't exist
767 in $TMPDIR at the time we test and pass that to pipe handlers, too.