Sprache wechseln auf deutsch
Znuny Professional Services

The ((OTRS)) Community Edition Fork with long-term Support (LTS)

When Mail Intake Breaks, CLI Saves the Day

Recovering from Procmail misconfigurations and spool file buildup is simple with Znuny and formail.

In a perfect world, incoming emails flow seamlessly into your Znuny ticketing system and are processed without delay. But in reality, even a small misconfiguration — especially when direct delivery is done via procmail — can quietly derail your mail intake.

Instead of creating tickets, Znuny’s expected mail accumulates messages in the local spool file (e.g., /var/spool/mail/znuny). No alerts. No tickets. Just a growing backlog of unprocessed mail.

🔍 Root Causes for: Misconfigured Procmail

Your local MTA utilizes procmail, in most setups, to pipe incoming mail directly to Znuny's CLI processor:

:0
| /opt/znuny/bin/znuny.Console.pl Maint::PostMaster::Read

If this command fails - due to incorrect paths, permissions, or missing binaries - you won't necessarily see the errors directly, but you'll feel the effects. The default .procmail rc will log the errors, and then it simply drops the mail into the spool file. 

MONTHFOLDER=`date +%Y-%m`
YEARFOLDER=`date +%Y`
LOGFILE=$SYS_HOME/var/log/procmail-$MONTHFOLDER.log
VERBOSE=on
COMSAT=no

Common misconfigurations include:

  • Incorrect Znuny binary path
  • Missing execute permissions for the Znuny user
  • Syntax errors in .procmailrc
  • Znuny CLI disabled or broken
  • Mail transfer agent (MTA) delivering to the wrong mailbox
  • Not stopping your MTA during an upadte.

❕This silent fallback behavior is convenient for delivery continuity, and aids you in your recovery.

🛠️ The Fix: formail + Znuny CLI

Once you’ve identified the spool file buildup, you can recover cleanly using formail, a classic tool for splitting mbox-style files into individual messages.

Here’s the full recovery workflow:

mv /var/spool/mail/znuny /var/spool/mail/znuny.orig
formail -s /opt/znuny/bin/znuny.Console.pl Maint::PostMaster::Read < /var/spool/mail/znuny.orig
rm /var/spool/mail/znuny.orig

What this does:

  • Moves the original spool file to avoid race conditions
  • Splits it into individual messages using formail -s
  • Pipes each message to Znuny’s PostMaster processor
  • Cleans up after successful injection

This method ensures every mail is reprocessed through Znuny’s filters, queues, and ACLs—just as if it had arrived live.

🧪 Bonus: Testing Filters in Dev Systems

This same technique is perfect for testing routing logic in non-production environments. You can inject sample mails - optionally downloaded from the productive system - to test custom headers, simulate edge cases, and validate queue assignments - all without touching production.

For example:

  • Test postmaster filters behavior based on sender or subject
  • Validate queue routing for specific keywords in generic agents.
  • Debug follow-up filters
  • Reproduce incidents for training or documentation

It’s a CLI-first workflow that’s reproducible, auditable, and safe.

✅ Key Takeaways

  • Always validate your .procmailrc and Znuny CLI paths
  • Monitor spool file size and mail delivery logs
  • Use formail for clean recovery and testing
  • Automate spool cleanup in your incident response playbook

Znuny’s flexibility shines when paired with robust CLI tools and a clear understanding of your mail intake flow. Whether you're recovering from a misfire or proactively testing filters, this method keeps your ticketing system reliable and transparent.

previous post