[GH-ISSUE #115] Batch sending of emails #95

New issue

Closed

opened 2026-02-25 21:34:08 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:34:08 +03:00

Owner

Originally created by @dumblob on GitHub (Sep 13, 2016).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/115

Originally assigned to: @jasonmunro on GitHub.

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.

Originally created by @dumblob on GitHub (Sep 13, 2016). Original GitHub issue: https://github.com/cypht-org/cypht/issues/115 Originally assigned to: @jasonmunro on GitHub. 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). 1. 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). 2. 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](https://tools.ietf.org/html/rfc2045#section-5.1))), 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. 3. Provide **preview of the email** before starting the batch processing (use first item from the CSV as input data). 4. If the minimum and maximum interval is 0, send messages in parallel to speed up processing. 5. 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. 6. 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](https://github.com/jimf/tcl-js ) or [4-15 KByte Tcls in JavaScript](https://wiki.tcl-lang.org/page/Tcl+in+Javascript ) or even [Lisp having 6KB](https://github.com/marcbelmont/javascript-lisp-interpreter/) or other ["Lisps"](http://ceaude.twoticketsplease.de/js-lisps.html)) 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](https://www.tutorialspoint.com/lisp/lisp_structures.htm). 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`: ```tcl 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: ```tcl 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.

kerem

2026-02-25 21:34:08 +03:00

closed this issue
added the
enhancement

new module set

smtp
labels

kerem commented

2026-02-25 21:34:08 +03:00

Author

Owner

@marclaporte commented on GitHub (Oct 29, 2020):

This seems out of scope for Cypht but makes perfect sense for Cypht within other apps like Tiki.

I see 3 modes:
1- manual: Cypht today
2- semi-automatic: Pre-populates a message which user can edit, and send via Cypht
3- fully automatic: sends according to pattern

Data comes from: https://tikitrackers.org/ (import your .csv there)

Wiki pages can be used for templates. Some ideas: https://dev.tiki.org/Mail-Merge

Text can be enhanced by:
https://dev.tiki.org/Natural-Language-Generation

User can adjust content before sending so it's even more personalized and not spammy.

System improves via https://doc.tiki.org/Machine-Learning

Since these mails (manual, semi-automatic and fully automatic) are sent via Cypht, it makes it easier to view all communications in sent box. And replies arrive in inbox as any other mail.

@marclaporte commented on GitHub (Oct 29, 2020): This seems out of scope for Cypht but makes perfect sense for Cypht within other apps like Tiki. I see 3 modes: 1- manual: Cypht today 2- semi-automatic: Pre-populates a message which user can edit, and send via Cypht 3- fully automatic: sends according to pattern Data comes from: https://tikitrackers.org/ (import your .csv there) Wiki pages can be used for templates. Some ideas: https://dev.tiki.org/Mail-Merge Text can be enhanced by: https://dev.tiki.org/Natural-Language-Generation User can adjust content before sending so it's even more personalized and not spammy. System improves via https://doc.tiki.org/Machine-Learning Since these mails (manual, semi-automatic and fully automatic) are sent via Cypht, it makes it easier to view all communications in sent box. And replies arrive in inbox as any other mail.

kerem commented

2026-02-25 21:34:08 +03:00

Author

Owner

@IrAlfred commented on GitHub (Sep 26, 2025):

@marclaporte Given that this seems to be outside Cypht's intended scope, and considering that apps like Tiki are better suited for this functionality, should we close this issue? What are your thoughts?

@IrAlfred commented on GitHub (Sep 26, 2025): @marclaporte Given that this seems to be outside Cypht's intended scope, and considering that apps like Tiki are better suited for this functionality, should we close this issue? What are your thoughts?

kerem commented

2026-02-25 21:34:08 +03:00

Author

Owner

@marclaporte commented on GitHub (Sep 26, 2025):

@dumblob

@IrAlfred Yes, but if someone wants to code it, we are open to contributions.

@marclaporte commented on GitHub (Sep 26, 2025): @dumblob @IrAlfred Yes, but if someone wants to code it, we are open to contributions.