High-Availability Outbound Email: Postfix smtp_fallback_relay with HAProxy SMTP Balancing

For organizations operating mail infrastructure in restrictive networks or corporate subnets with unreliable direct port 25 connectivity, combining HAProxy as an SMTP proxy relay with Postfix's smtp_fallback_relay directive guarantees reliable email delivery without dropped messages.

Flow: Primary MTA → Direct MX Delivery Failure → smtp_fallback_relay → HAProxy Relay VPS → Destination MX

1. HAProxy TCP Relay Configuration (haproxy.cfg)

listen smtp-relay
    bind *:2525
    mode tcp
    option tcplog
    timeout connect 5s
    timeout client 1m
    timeout server 1m
    server mta-out 10.0.0.1:25 check

2. Postfix Fallback Configuration (/etc/postfix/main.cf)

Instruct Postfix to attempt direct MX delivery first, but automatically route through the HAProxy relay if destination mail servers are unreachable:

# Automatic fallback routing to HAProxy relay on port 2525
smtp_fallback_relay = [relay.example.com]:2525

[Solved] Fixing Broken DomainKeys and DKIM Signatures Sent via PHP mail()

When sending emails through PHP's native mail() function on a server configured with SPF, DomainKeys, and DKIM (such as Plesk), desktop mail clients (Outlook, Thunderbird) may sign outbound emails correctly, but emails dispatched from web scripts fail DKIM verification with invalid domain signatures.

The Trap: Setting a raw From: string inside $additional_headers causes the sendmail wrapper to misidentify the originating signing domain d=$DOMAIN.

The Problematic Call

// This breaks DKIM signatures by overriding the sender envelope incorrectly:
mail($to, $subject, $message, "From: Name <user@domain.com>");

The Solution

Explicitly pass the envelope sender using the -f flag in the 5th parameter ($additional_parameters):

// Correct invocation with verified envelope sender:
mail($to, $subject, $message, "", "-f user@domain.com");

Verification Tip: Send a test email to check-auth@verifier.port25.com. The automated robot will reply within seconds with a detailed SPF, DKIM, DomainKeys, and SpamAssassin diagnostic report.

[Solved] Postfix SASL Authentication Failure: realm changed: authentication aborted in Plesk

When enabling STARTTLS on a Plesk server running Postfix, mail clients like Mozilla Thunderbird may connect normally, while Microsoft Outlook clients repeatedly fail with authentication popups and the following mail log errors:

Environment: Plesk • Postfix with STARTTLS • Cyrus SASL Authentication

postfix/smtpd[1929]: warning: SASL authentication failure: realm changed: authentication aborted
postfix/smtpd[1929]: warning: SASL DIGEST-MD5 authentication failed: authentication failure

Root Cause & Solution

Outlook struggles with DIGEST-MD5 SASL negotiation over TLS on certain Cyrus SASL configurations. Restricting the SASL mechanism list to CRAM-MD5, PLAIN, and LOGIN resolves the negotiation conflict:

1. Edit /usr/lib64/sasl2/smtpd.conf and update mech_list:

   mech_list: CRAM-MD5 PLAIN LOGIN

2. Edit /etc/postfix/main.cf and confirm security options:

   smtpd_sasl_security_options = noanonymous

3. Restart services:

   service postfix restart
   service saslauthd restart

How to Disable 'Sort by Subject' in Roundcube Webmail

In Roundcube Webmail, accidentally clicking on the Subject column header triggers an expensive mailbox-wide sort operation. On large mail folders with thousands of messages, sorting by subject can freeze the UI and create heavy server load. Here is how to disable sorting on the Subject column while keeping date and status sorting intact.

File: program/steps/mail/func.inc • Target: Subject header click handler

Step-by-Step Fix

1. Open program/steps/mail/func.inc in your text editor.
2. Search for ./#sort (typically around line 440–445).
3. Locate the onclick attribute generation:

   'onclick' => 'return ' . JS_OBJECT_NAME . ".command('sort','" . $col . "',this)"

4. Replace it with a no-op handler for the subject column (or globally):

   'onclick' => 'return true'

Save the file. Clicking the Subject column header will no longer initiate slow sorting queries.

How to Log PHP mail() Sender Scripts and Headers to Detect Outgoing Spam

When a web server hosting multiple PHP applications or CMS sites is compromised by spammers, identifying the exact malicious PHP script sending unauthorized emails can be notoriously difficult. In PHP 5.3 and newer, built-in configuration directives allow you to track the exact script filename and originating source of every outgoing message.

Key Directives: mail.log for auditing script paths • mail.add_x_header for tracking script UID in email headers.

1. Enable mail.log

Open your server's php.ini (or pool configuration in PHP-FPM) and configure a dedicated mail log:

; Log all mail() function invocations, including script path and line number
mail.log = /var/log/php_mail.log

Ensure the web server user (e.g. apache or www-data) has write permissions to the destination file:

touch /var/log/php_mail.log
chown www-data:www-data /var/log/php_mail.log
chmod 660 /var/log/php_mail.log

2. Enable X-PHP-Originating-Script Header

To embed the sender script path directly into outgoing mail headers, enable mail.add_x_header:

; Adds X-PHP-Originating-Script header containing the UID and filename
mail.add_x_header = On

When an email is sent, the recipient headers will contain:

X-PHP-Originating-Script: 1000:contact_form.php

This allows you to immediately trace spam reports back to the offending script or compromised user account.

How to Run mini_sendmail in a Chrooted PHP-FPM Environment (CentOS & Debian)

Chrooting PHP-FPM worker pools provides robust filesystem isolation on multi-tenant servers. However, standard mail dispatch breaks because PHP's mail() function relies on executing a local sendmail binary (which requires extensive shared libraries and access to /etc). mini_sendmail solves this by providing a lightweight, statically linkable MTA forwarder that relays directly to localhost port 25.

Stack: PHP-FPM Chroot • mini_sendmail • CentOS 6 / Debian 6

1. Preparing the Chroot Filesystem

Inside the jail directory, ensure character devices and DNS resolvers are accessible:

cd /path/to/jail
chmod 0666 dev/{tty,null,zero}
echo "nameserver 8.8.8.8" > etc/resolv.conf

2. Compiling and Patching mini_sendmail

Download and extract the source:

cd /usr/src
wget http://acme.com/software/mini_sendmail/mini_sendmail-1.3.6.tar.gz
tar -zxf mini_sendmail-1.3.6.tar.gz
cd mini_sendmail-1.3.6

When running inside a chroot jail without /etc/passwd, getlogin() fails with can't determine username. Fix this by hardcoding the pool user in mini_sendmail.c around line 148:

// Replace: username = getlogin();
// With your PHP-FPM pool user:
username = "fpm_user";

Compile and install into the jail's usr/sbin/sendmail:

make
cp mini_sendmail /path/to/jail/usr/sbin/sendmail
chmod 755 /path/to/jail/usr/sbin/sendmail
chown fpm_user:fpm_user /path/to/jail/usr/sbin/sendmail

Now PHP scripts running inside the chroot jail can execute mail() and messages are cleanly forwarded to your server's primary MTA.

How to Fix Postfix SASL Authentication Failure and Chroot Errors with saslauthd

When configuring Cyrus SASL (saslauthd) to authenticate SMTP users in Postfix on CentOS / RHEL with Virtualmin, you may encounter persistent user/password authentication failures even when credentials are valid.

Environment: CentOS 6.x / RHEL • Virtualmin • Postfix • Cyrus SASL (saslauthd)

1. Identifying the Symptom: /var/log/maillog

Checking /var/log/maillog often reveals that Postfix cannot communicate with the SASL authentication daemon:

warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory

2. The Chroot Trap and Secondary SMTP Failures

A common workaround suggested in forums is moving or binding the saslauthd socket into the Postfix spool directory (e.g. /var/spool/postfix/var/run/saslauthd). While that may resolve socket visibility, running Postfix processes inside a chroot jail introduces a severe secondary failure: outbound emails will fail to send entirely.

You will see delivery attempts stall in the active queue with errors like:

postfix/qmgr: from=<root@domain.com>, size=421, nrcpt=1 (queue active)
postfix/smtp: fatal: unknown service: smtp/tcp
postfix/qmgr: warning: private/smtp socket: malformed response
postfix/qmgr: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
postfix/master: warning: process /usr/libexec/postfix/smtp pid 29443 exit status 1
postfix/master: warning: /usr/libexec/postfix/smtp: bad command startup -- throttling
postfix/error: to=<user@example.com>, relay=none, delay=1.1, delays=0.1/1/0/0.03, dsn=4.3.0, status=deferred (unknown mail transport error)

Root Cause: When the Postfix smtp client daemon runs chrooted, it cannot access /etc/services to resolve the network port name smtp/tcp, causing the transport to abort and defer all outgoing mail.

3. The Permanent Solution: Disable Chroot for SMTP

To resolve both the SASL socket communication and the transport errors cleanly, configure the Postfix smtp process to run unchrooted.

Step 1: Edit master.cf

Open /etc/postfix/master.cf in your text editor:

nano /etc/postfix/master.cf

Locate the smtp service definition:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      unix  -       -       -       -       -       smtp

The 5th column controls chroot. A hyphen (-) defaults to enabled (yes). Change the 5th column from - (or y) to n:

smtp      unix  -       -       n       -       -       smtp

Step 2: Restart Services

Restart both saslauthd and postfix so the configuration changes take effect:

service saslauthd restart
service postfix restart

4. Verification

Once services are restarted, monitor the mail log while sending a test message or authenticating a mail client:

tail -f /var/log/maillog

SASL authentication will succeed immediately without socket connection errors, and the mail queue will flush smoothly without transport or chroot exceptions.