Batch sending of emails

It seems, there is only one last reason to stay with Thunderbird and not switch to Cypht completely. Namely the lack of support (e.g. through a module) for batch sending of emails. Let me describe how I envisage the batch sending capability in Cypht (higher priority items first; only the first 2 items are necessary).

The "Compose" page should read CSV data (or a similar easy-to-manually-create and easy-to-parse format supporting tables) in UTF-8 (!) from an input field or a file. The CSV is a list of To: fields (and possibly other related data like specific greeting for the particular email address - useful for inflecting last names in languages which require that - and many do; see column labels below) to which the email should be sent.

For each To: field is the email processed separately and processed emails are then sent one-by-one in a serial manner with a defined minimum and maximum time interval between two consecutive transmissions. The exact time between transmissions should be randomly chosen (uniform distribution) from the user-set interval (if the start and end number is the same, the interval is fixed).
Define and implement support for a minimal set of case-sensitive strings representing CSV column labels for email standard fields (at least To Bcc Cc Reply-To), common convenient adjustments (PRE-Subject-text/plain POST-Subject-text/plain PRE-Body-text/plain POST-Body-text/plain PRE-Body-text/html POST-Body-text/html representing text which should be put to the front/back of the email title/body having the corresponding MIME type and MIME subtype (not MIME parameters as described in RFC2045)), and a CSV column label syntax for advanced manipulation based on programmatical generation as described below (e.g. EXE-INIT-application/x-jimf-tcljs or EXE-INIT-application/x-marcbelmont-lisp).

Column labels not matching these syntactic rules will be reported to the user as a non-recoverable mistake with suggestions (guesses) how to correct them.
Provide preview of the email before starting the batch processing (use first item from the CSV as input data).
If the minimum and maximum interval is 0, send messages in parallel to speed up processing.
It might be convenient to somehow "unify" address book functionality, LDAP support and these CSV tables. But so far I would not do that and leave it rather completely separate. Basically it makes sense to only propagate small amount of information like email, last name, and inflections for greetings. The propagation is anyway only one-way - from the address book or LDAP to this module - so the benefits are quite low.
With regards to repeatable batch sending, there is sometimes the need to do a little bit more complicated stuff (e.g. randomly choose some string from a supplied list or do some simple computations based on date, number of recipients etc.).

For these purposes, a support for pure client-side generation of emails from a non-JS language (e.g. Tcl in JS or 4-15 KByte Tcls in JavaScript or even Lisp having 6KB or other "Lisps") source code is undoubtly the solution. Usually this is solved using macros (see e.g. https://addons.mozilla.org/cs/thunderbird/addon/mail-merge/ ), but they are by definition very constrained, unnecessarily extend syntax, push users to learn specific syntax (non-transferable knowledge), require well-coded parser with huge comprehensive suite of tests, need to support nested macros, etc. and in the end the result is far away from a minimal/sane full-featured well-known programming language like Tcl (note, it must not be Javascript as it would pose a huge security risk).

This would mean, that the user will write the email body in the programming language, will choose from a list of MIME types of supported programming languages (in addition to the currently supported text/plain and text/html) for the email body content, will check a check box "execute the body code", will provide some initialization code (e.g. variable assignments) in corresponding CSV columns as described above (i.e. the content of EXE-INIT-application/x-jimf-tcljs will be executed before the email body code), and finally will write some code to the email body.

To enable that, a tiny programming interface must be provided for each supported language. Probably a simple object/structure representing the whole email (including headers) for reading and writing using methods/functions. I would discourage something like CGI and rather provide fool-proof methods/functions having only 1 or 2 string arguments (the strings which should be present in the email bit by bit without even applying any encodigs etc. - all this stuff will be responsibility of the user) for changing and adding any email headers and body content.

Example content of the CSV column EXE-INIT-application/x-jimf-tcljs:
```
set emailbody [localTo7bit "precise time of assembling email body content: [dateToLocaleString [datenow]]"]
```
(note, it's better to convert it to 7bit, because it might stay like that in the email)

Example email body content:
```
if {[emailheader "To"] == {<email0@a.bc>, <email1@x.yz>}} {
 set emailbody "[localTo7bit {Hello email0 and email1,

do you know Cypht rocks? If not, take a look at https://cypht.org .

Yours sincerely,
Cypht Lover}][7bitToLocal emailbody]"
```
(emailbody variable is provided as the interface as well as the commands localTo7bit and 7bitToLocal; note also, that the EXE-INIT-application/x-jimf-tcljs column content is just concatenated with the email body and first then the result is executed)

I think all this "email content programming" could be a fully separate "programming" module independent from the batch sending module described above. Or maybe not?

Keep in mind, this is just a draft which already got several revisions.

cypht-org / cypht

Batch sending of emails #115