tq v1.0.0-r0



 PMA  ==>  tq  ==>  msmtp  ==>  mail server  ==>  destination 


What does it do

tq is a mail queueing service. The T stands for timed delivery. In order to delay mail sending until a user defined time, we are going to lie 2 new internal X-header fields into the mail header, so that it

These two configurable X-fields could, but never will leave the house, we rewrite the mail’s header to ensure that before sending.

In order to achieve these goals you must hand over your deferred mail to tmstpq (best done locally), which in turn will check its queued mail periodically (as long as you configure it, see below; it will not send a mail w/out the send command; you shall configure it doing so via a cron service or something similar) and send it when its time has come.

tq was coded as a sendmail replacement in the Swiss Army Knife style, it is wholly self contained and shall provide good output to check its operations and the queue itself.

Check it out by calling it without arguments like so:

Invoke tq from command line
 $#> tq

tq relies on msmtp for (s)smtp communications, this could further require gnutls and/or certificate configuration. Testing out full functionality of msmtp alone beforehand would be a splendid idea. No msmtp, no tq.

Logging to syslog is not implemented, logging is done to a log file, which is rotated solely by yourself. Logging will fall back to /var/log/tq.log and can be overridden in /etc/conf.d/tq.

back to toc

How it works

Have a gander at /etc/conf.d/tq for commented options pertinent to operation of the queue, everything is explained and defaults are given.

To get the two extra fields into that mail header, have a gander at the init-edit script as well, provided in


Do this or something similar with your personal mail client. This way you get the two new X-fields (definable in cfg) into the mail header. These two are crucial, tq will send mails right away (on the next ‘tq send’* command) if it is unable to find these.

Once you have the means to provide these extra two fields for your composed mails, turn to your mail client again, I reckon it has some sendmail compatibility. Enter tq in sendmail’s stead as a means of transportation for outgoing mail. Bring your own msmtp options or use the ones provided below / in the usage text in tq.

back to toc

Privacy / Personal Use

As tq can be used in a server wide installation, observe that with its queue it tries to emulate mailboxen in real life: The lid of the mailbox is open, everybody can drop mail into the queue. But all mails get chowned to root upon admittance. This way the users cannot read each others queued mail, but are still able to send away.

The only way for personal use (this instance of tq is used only by yourself, hence you want unprotected mails in your queue, on queueing attributed to you instead of root) at the moment is to have your mail queue anywhere below /home. But you can patch this out quite simply, this is a bash script after all. ;)

Be advised if you use it on a personal basis, you then are allowed to overrule msmtp’s server wide /etc/msmtprc with (fi) ~/.msmtprc, since msmtp is now called by you, not root.

Also note that it would probably be best if you would rely on your personal rather than root’s crontab for periodic mail sending purposes, if there is any fCron on your machine.

back to toc

What you have to do

Firstly, you have to bring the two extra header fields as defined in /etc/conf.d/tq. Use the means provided in this document or any other means you see fit, but bring these two header fields!

When it comes to submitting new emails into the queue, tq is sendmail-compatible, so as that you have to cat your mails to it line by line. Do something like this:

How to send mail from the command line with tq

[cat mail.txt |] /sbin/tq add -t -i -C /etc/msmtprc [-a ]

After the tq command (here: the ‘add’) tq accepts all of msmtp’s command line switches, a part of which you can see here. Check msmtp’s man page for further ideas what to use.

If unsure how to write /etc/msmtprc, have a look at cui-msmtp package, the internets or msmtp’s man page. Msmtp must be configured to work with your particular smtp server for in order for tq to work, as tq relies solely on it for mail delivery purposes.

You can define a default account (handy for a particular server or type of service) in the config of msmtp, so as to ommit everything after /etc/msmtprc in the incantation above.

You can keep tq’s option doCronTab=false in /etc/conf.d/tq and provide an entry to your own crontab mechanism to then check your queue periodically in order to use msmtp to send you due mails.

Alternatively you can set doCronTab=true in order to let tq do its thing and generate an entry in root’s fCron or the other one, whatchamacallit, cron mechanism by itself. Yes, it can do that.

Keep in mind that you have to send mail from your queue proactively by incantating any of the send commands either yourself or a periodical service, this is no mailserver. Failing that your mails will not leave your queue.

back to toc

What (else) you can do

Have a gander at options/usage by incantating:

Display usage
 $#> tq

You can inspect the queue (less clutter) by incantating:

Inspect the mail queue
 $#> tq list

You can send all queued mails, if they are due / have no special header fields by incantating:

Send all mails from the queue (quietly)

$#> tq sendAll/sendQuiet

You can test a particular queued mail’s dueness by incantating:

Test mail if ready to send

$#> tq test

so this should work, as long as you have 1 mail in your queue:

Test mail 1 if ready to send

$#> tq test 1

You can send mails from the queue individually by incantating:

Send mail

$#> tq send `

so they get sent if their time is due. Overriding the dueness (and thus sending a mail earlier than its due date) is neither possible nor acceptable. Use something else for that.

back to toc

Further ideas

You can still use tq in a mixed environment/group where only some have the ability to delay outgoing mail. tq will send mails without the X-header fields immediately anyway, so the mails without are getting sent on its next call.

Also of interest in this context is tq’s ability to store meta information on a per mail basis, ie multiple msmtp accounts could be in service on the server at once, with any single user being able to service multiple accounts at the same time.

What you configured w/in msmtp is the only limit here.

back to toc