Knowledge base

spool-delete-corrupted

Global

Whether to delete corrupted files found in the spool
in the configuration this is a linespool-delete-corrupted falseinside the block Global
What to do with a message that can no longer be read

The default is false. The line decides the fate of spool files in which the engine found encoding errors — the manual names data corruption on disk as the cause.

With the default such files are ignored and stay in place. With true they are deleted.

This is not about messages that could not be delivered: those live by their own order of retries and bounces. It is about files the engine cannot read — they cannot be delivered under any conditions.

The main trap is that the default accumulates traces of a fault. A file left in place does not interfere with work, but it does not disappear either: it lies in the spool directory until someone removes it by hand. On an unattended node such files accumulate, and they are usually discovered while investigating something completely different — when files in the directory are counted and do not match the number of messages in the queue.

The second half matters more: the very appearance of such files is a signal. Encoding errors mean data corruption on disk, and deleting the file treats the consequence. The cause — the disk, the file system, memory — has to be looked into separately.

What the Hub does. It does not write it — the vendor false stays, that is, corrupted files remain in the directory.

We have nothing to notice them with: the Hub does not keep separate track of the spool and does not show the number of files in the directory. With file holder deletion enabled, the number of files in the spool is comparable to the number of messages in the queue — a mismatch would be the sign.

Recommended values

What to set. A choice between traces and cleanup:

Value When
false (default) there is supervision, and you want to keep a corrupted file for investigation
true the node runs unattended: the file cannot be read anyway, and there is no point accumulating it

The second does not cancel investigation: deletion should go together with knowing about the fact — from the log, not from the directory contents.

The false default, the cause of corruption (data corruption on disk) and the behavior with the line off come from the manual, § 3.3.1.6. The breakdown of cases is ours.
Example configuration
# an unattended node: the file cannot be read anyway
spool-delete-corrupted true
Deletion treats the consequence. The very appearance of such files means data corruption on disk, and the cause has to be looked into separately.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Enabling deletion and considering the matter closed

our experience

What it costsDeletion removes the file but not the cause. Data corruption on disk continues, and subsequent messages get corrupted the same way — only now silently.
How to spot itLog entries about corrupted files keep repeating.
How to do it rightLook at the disk and file system; keep deletion as cleanup, not as treatment.

Confusing a corrupted file with an undelivered message

§ 3.3.1.6

What it costsUndelivered messages live by their own order of retries and bounces, and this line does not concern them. The expectation that it will clean out a stuck queue does not come true.
How to spot itThe line is on, the queue does not shrink.
How to do it rightClean the queue with the delete command with an explicit selection, and leave this line for its own task.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
spool-delete-corrupted <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.6
Applying
reload, no restart needed
Queue
also affects what is already in the queue
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the configuration file and applies to the whole node: there is one rule for all spool directories, and it cannot be set separately for one location.
How to check on the node
The line is visible in the configuration, the traces — in the log and in the directory:
grep -n 'spool-delete-corrupted' /etc/pmta/config
grep -i 'corrupt' /var/log/pmta/pmta.log | tail -10
Log entries mean data corruption has already happened. That is a reason to look at the disk and file system, not just to configure deletion.
In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Untangle a stuck queue