Documentation

Without this line the send-first spool is inactive: mails are not intercepted or queued. The backend module and the console commands still exist, but they have nothing to process unless something else wrote to the table.

Any other schema update works too—the Install Tool's "Analyze Database Structure", or database:updateschema if you use helhum/typo3-console.

Re-run this after upgrading whenever ext_tables.sql gains columns, for example redirected_to for Send to address traceability.

Use the TYPO3 Scheduler task "Execute console commands" or a system cron. Without flush, failed mails stay queued forever.

1. Spool active—transport_spool_type set to SendFirstSpool
2. Schema present—table tx_mailqueue_message exists
3. mailqueue:flush runs every minute (Scheduler or cron)
4. mailqueue:cleanup runs daily
5. alertWebhookUrl points at an HTTPS endpoint. Ops email alone is not enough: when the queue is red, SMTP is usually broken too, so the alarm mail may never leave the box. See Webhook Alerting
6. On staging and test, use forceHold and set queuedRetentionDays. Under force hold every mail stays queued forever; without a retention—or a periodic mailqueue:purge—the table and the payload directory grow without bound
7. var/mailqueue/ is readable by the flush user and survives deploys—see below

Attachment payloads are written there by the web-server user during a request and read by the—often different—CLI or cron user that flushes the queue. Two things follow:

Permissions. The extension applies your instance's fileCreateMask, folderCreateMask, and createGroup to the directory and its files, so a standard multi-user setup works out of the box. If you tighten those, keep the flush user able to read them, for example through a shared createGroup.

Deployment. Make var/mailqueue/ a shared or linked directory in your deployment, the way you already treat var/log, so payloads of mails queued before a release survive the deploy.

A payload that cannot be read is not treated as failed. The entry stays queued with a clear error message and is retried once the cause is fixed, and the attempt counter is left untouched because no delivery was tried.

This takes the exact same path as any application mail, including the spool:

Note what --attachment does and does not prove. The payload only goes to var/mailqueue/ when the delivery fails, or when archive mode is on. On a healthy SMTP server both runs simply send, and neither touches the directory.

To actually verify the file-backed path—the part where permission and deployment problems show up—point the instance at an unreachable SMTP server, run the --attachment command, and check that a file appears in var/mailqueue/ and that the entry flushes once SMTP is back.