SGID and Dovecot LMTP Permissions: Fixing Silent Email Delivery Failures

You've set up Exim and Dovecot on your cPanel server. DKIM, SPF, and DMARC all pass. Mail flows fine for days — then suddenly, certain accounts stop receiving email. No bounce messages, no errors in the sender's mail client. The emails simply vanish.

The Root Cause: SGID Bit Misconfiguration

On shared hosting servers, Dovecot's LMTP (Local Mail Transfer Protocol) process delivers mail into user Maildirs. This requires the LMTP process to write files with the correct group ownership — typically the mailgroup on cPanel servers or the user's primary group on Plesk.

The problem emerges when the SGID (Set Group ID) bit on mail directories gets stripped or misconfigured. This commonly happens during:

• Backup restoration: tar and rsynccommands that don't preserve special permission bits strip SGID from Maildir/ directories
• cPanel account migrations: The /scripts/pkgacct and /scripts/restorepkg pipeline occasionally loses SGID on nested mail directories, especially with custom Maildir structures
• Permission "fix" scripts: Hosting providers often run bulk chmod/chown scripts that normalize permissions but inadvertently clear the SGID bit
• CloudLinux CageFS: When CageFS re-mounts user directories, the SGID bit on /home/user/mail/subdirectories can be lost if the skeleton configuration doesn't account for it

What Happens When SGID Is Missing

Without SGID, Dovecot LMTP creates new mail files with the Dovecot process's group instead of the user's mail group. This triggers a cascade of failures:

• New messages are written with incorrect group ownership (e.g., dovecot:dovecot instead of user:mail)
• The user's mail client (IMAP) can't read the files due to permission denied errors
• Dovecot logs show Permission denied errors in /var/log/maillog, but only for delivery — IMAP auth appears normal
• Exim reports successful handoff to LMTP, so outbound logs show no issues

The Manual Fix

For a single affected account, the fix is straightforward:

But on a server with 500 cPanel accounts, finding which accounts are affected — and continuously monitoring for regressions — requires automation.

How CleanShift Detects Permission Anomalies

CleanShift's server scan includes a permission anomaly detector that checks critical system directories for SGID, SUID, and sticky bit correctness. Specifically for mail:

• Scans all Maildir/ directories under /home/*/mail/ for missing SGID bits
• Verifies group ownership chains match the expected mail delivery user
• Cross-references Dovecot's mail_location config with actual filesystem permissions
• Flags directories where the SGID bit was present in previous scans but is now missing (regression detection)

This means you get alerted about SGID permission drift before your customers notice missing emails — not after a support ticket escalation.

Beyond Mail Permissions

Permission anomaly detection is one facet of CleanShift's broader server hardening approach. Incorrect SUID bits on WordPress upload directories, world-writable wp-config.php files, and overly permissive .htaccess rules are all common attack vectors on shared hosting. CleanShift catches them in a single scan pass.