郵件出不去：當 Postfix 比 HR 先知道你要離職

Prologue

Wang had a plan.

His resume went through three drafts. The second was too modest; the third struck the right balance between “experienced” and “not desperate.” His cover letter took longer — he rewrote the opening line four times before settling on something that sounded confident without being smug. He chose 6pm as his window, that quiet stretch after the last stragglers leave and before the cleaning crew arrives. He would send it then. No one would notice. He had thought of everything.

He was completely wrong about all of it.

Act 1: Postfix Was Waiting

That afternoon, HR checked a box in iDempiere. It took four clicks — navigate to the employee record, find the LDAP configuration tab, toggle IsMailMonitor to Y, save. She didn’t dwell on it. There was a stack of onboarding forms waiting. Three systems silently updated: iDempiere wrote to the database, the LDAP sync service pushed the flag to the directory, and Postfix — which had been running quietly on a server in the corner rack — now had new instructions.

Two floors away, Wang was proofreading his cover letter for typos.

Three things happen before Wang even notices the email is gone. First, Postfix queries LDAP in real time — the interception flag lives in the directory, not in a config file, which means it takes effect the moment HR saves the record. No restarts. No waiting. Second, email flagged for HOLD doesn’t bounce and doesn’t deliver; it sits in a queue, suspended, while a review is initiated in the ERP. Third, a FastAPI service bridges the gap between Postfix’s queue and iDempiere’s workflow — it is the piece that turns a mail server action into a business process. Together, the three form a loop Wang had no reason to know existed.

Act 2: The Fate of the First Email

Wang hit send at 6:03pm. His email entered Postfix. Postfix consulted LDAP. LDAP returned: HOLD.

The interception logic lives in three lines of main.cf:

# /etc/postfix/main.cf
smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/recipient_permit.cf,
    check_sender_access ldap:/etc/postfix/ldap-sender.cf,
    permit

Postfix evaluates sender restrictions in order. If the LDAP lookup matches, the sender’s message is held. Three lines. Wang’s email never had a chance.

The LDAP query that does the actual work is in ldap-sender.cf:

server_host = ldap://your-ldap-host
search_base = ou=users,dc=ninniku,dc=tw
query_filter = (&(uid=%s)(IsMailMonitor=Y))
result_attribute = hold

The filter checks two things simultaneously: does this uid exist, and is IsMailMonitor set to Y? If both match, the result attribute hold is returned to Postfix, which interprets that as the HOLD action. The email enters the queue. Wang’s client shows the message as sent — his side of the conversation ended there. The other side hadn’t started yet.

The email entering the HOLD queue wasn’t the end of the story. Something was watching the queue.

FastAPI is the bridge no one talks about. It does three things on a loop:

1. Every few seconds, postqueue -p scans the HOLD queue and collects Queue IDs for intercepted emails — any message suspended and waiting for a decision.
2. For each Queue ID, postcat -q <id> extracts the sender address, subject line, and body text in full.
3. That data is pushed to iDempiere via REST API, creating a review record in the HR_MailIntercept table — sender, subject, content, timestamp, status: Pending.

Wang’s email was now in limbo — like a traveler detained at customs with no good explanation for what’s in the bag.

Act 3: Wang in the ERP

The next morning, HR opened the Mail Intercept window. Three emails, neatly listed. Sender: Wang. Subject: Application – Senior Engineer.

The window offered two paths for each record.

Approve — click Complete. FastAPI receives the callback, runs postsuper -H <queue_id> to release the email from HOLD, and Postfix delivers it normally. The recipient gets the email. The sender never knows there was a delay.

Reject (Void) — click Void. FastAPI receives the callback, runs postsuper -d <queue_id> to permanently delete the message from the queue. The email ceases to exist. The sender’s client still shows it as sent.

HR looked at the email with the subject line Application – Senior Engineer. She clicked Void. Wang never found out what happened to that email.

The glue holding this together is a Java hook in the iDempiere LDAP user model. When HR saves the record — whether it’s a new employee or a flag change on an existing one — the hook fires and pushes the update to LDAP immediately:

// LDAPUser.afterSave snippet
if (success && (newRecord || is_ValueChanged("IsMailMonitor"))) {
    LdapService.syncUserFlags(
        getAD_Client_ID(),
        getLDAPUser(),
        getName(),
        getEMail(),
        "Y".equalsIgnoreCase(get_ValueAsString("IsMailMonitor"))
    );
}

One checkbox. Three systems in sync. HR doesn’t need to know LDAP. The engineer doesn’t need to be on standby.

The Historian’s Note

The historian notes: Wang believed he was invisible. He was not. Postfix had been waiting at the door. LDAP had been watching without blinking. The ERP had been keeping records, patiently. The email never left. The queue holds all; nothing escapes unreviewed.

The full iDempiere HRM plugin (including the mail monitoring module) is open source on GitHub: https://github.com/ray-idempiere/ldap-in-a-box

This feature has been approved by our company’s fictional legal department, the “Probably Fine” division. Consult actual lawyers before deployment.