Mail trace

Follow from the admin console whom a message reached inside this Zimbra installation and whether its recipients passed it on. The search is read-only: messages are never opened, and read flags and folders do not change.

Global administrator or authorized delegated administratorAdmin console › Tools and Migration › Mail Trace

Before you rely on the results in a legal process, verify them with a sample case in your own environment.

The module answers two questions:

• "Whom did this user send what to?" Spam or abuse investigation. Lists the sender's submissions and recipients from the MTA logs.
• "Who received this message, and did they forward it?" Legal process. Finds the root message and follows the attachment or reply chain step by step through the recipients' mailboxes.

Screen

In the left tree click Tools and Migration › Mail Trace (1). The Jobs list (2) is on the left, the new trace form on the right. The form has two tabs (3): Log trace and Content trace.

Mail Trace: job list and trace form

	Log trace	Content trace
Source	MTA logs (/var/log/zimbra.log*)	Mailbox contents + MTA envelope
Speed	Seconds	Minutes, depending on the number of accounts
Touches mailboxes	No	Reads, never changes
Subject / attachment data	No	Yes
Limit	Log retention on the MTA	Messages still on the server

Log trace

Lists every submission of the sender in the given range, one row per Postfix Queue ID.

1. On the Log trace tab fill in Sender and From (required). If Until is empty the search runs up to now. Date format YYYY-MM-DD or YYYY-MM-DD HH:MM (server local time); a date-only end includes that whole day.
2. Click Start trace. The job appears in the list and is selected.
3. Each row is one submission: Submit time, Queue ID (1), Recipients and MTA. Click the recipient count to expand the recipients (2). Recipients are the union of the envelope RCPT and delivered addresses (deduplicated).

Log trace result: Queue ID rows, one expanded

A partial badge means the first queue record of the submission (before the content filter) lies outside the scanned log; recipients from that record may be missing.

Content trace

Finds the root message and follows later submissions carrying the same content through the recipients' mailboxes, step by step.

1. Open the Content trace tab (1).
2. Enter the root criteria. Sender and From (2) are enough to start in most cases. At least one is required: sender, Subject, Attachment name (3), Attachment size (min - max, KB or MB) or Body text.
3. If the sender is unknown, type the accounts to search in Seed accounts, one per line (at most 1000), or tick Search all accounts. Searching all accounts takes very long on large installations.
4. Maximum steps (4, 1-50; default 10) limits how many rounds the spread is followed.
5. Click Start trace (5).

Content trace form: sender and attachment name filled in

How matching works

• Root (step 0): the message matching the criteria, sent by the sender (or the seed accounts). The SHA-256 digests of its attachments, its Message-ID and subject become the "fingerprint".
• Step n → n+1: in every local account that received the message at step n, messages sent after it arrived are searched. A match is one of:
  • Attachment hash: an attachment has the same SHA-256 digest as a root attachment. Caught even when the attachment was renamed.
  • Message-ID chain: the References / In-Reply-To headers lead back to the root Message-ID (a reply, or a forward without the attachment).
• Low confidence: if the attachment was edited (the digest changes) but its name or size is similar, the row is listed as Low confidence (name / size / name+size) with its recipients in Next recipients, but it is not followed. Size-only similarities are folded into a separate group. This keeps unrelated attachments out of the report; if needed, start a new trace with those recipients.
• Criteria: if the root has no attachment, the spread is searched with root criteria such as subject and body text and the match type is Criteria. This is looser; review the results by hand.
• Distribution lists and aliases are expanded to real accounts. A visited account is never searched twice.

Bcc and automatic forwarding

Bcc recipients exist in the sent copy only when the message was sent from the web client. Therefore every submission found is completed with the recipients in the MTA envelope (Message-ID ↔ Queue ID mapping). Rows verified from the envelope show a ✓ in the Envelope column; in the example the recipient richard.roe was Bcc and was found only through the envelope.

For a recipient reached through automatic forwarding of an account (the user's forwarding address zimbraPrefMailForwardingAddress, an administrator-defined zimbraMailForwardingAddress or a Sieve redirect), the From column shows via forwarding of with the account name; in the CSV this is the Yonlendirme ile (kimden) column.

Result: table and tree

Select the job in the list. The top line shows the state, step and number of accounts searched, followed by Notes and the results.

Content trace result: three recipients at step 1, forwarded attachment at step 2

In the example jane.doe sent the presentation to three people (step 1, Attachment hash). john.doe renamed the attachment to rapor_son.pdf and forwarded it to sam.smith; because the content is the same it was found at step 2 (2), again by Attachment hash. Tree (3) shows the spread from whom to whom, Download CSV (4) downloads the report.

Spread tree view

Columns: Step, Account, From, Time, Subject, Attachment (name and size), Match, Next recipients, External recipients (addresses without an account in this installation; listed, not followed) and Envelope. External addresses seen in the envelope but not in the sent copy are added with the label seen here:.

Background jobs

• The job runs on the server in the background; you can close the tab and come back later. The list and the open job refresh every few seconds.
• Progress: step, searched / total accounts and number of matches; for a log trace the MTA being scanned. When progress is unknown it reads "Running, last activity N s ago".
• Partial results are visible and downloadable before the job finishes.
• Cancel job stops the job; what was found so far is kept. Accounts left unsearched are marked Not searched.
• If mailboxd restarts, a running job becomes Interrupted (server restarted); its results stay in the report. Start the job again.
• Jobs and reports are kept on the server under /opt/zimbra/data/profelis-mailtrace/jobs/ for 30 days (retentionDays).

CSV report

The file is prepared for Turkish Excel: UTF-8 (BOM), ; separator. Cells that could be read as a formula get a leading single quote. Column headings are in Turkish.

• Content trace columns: Adim (step); Hesap (account); Kimden (from); Yonlendirme ile (kimden) (via forwarding of); Zaman (time); Konu (subject); Ek (attachment); Ek Boyutu (attachment size); Eslesme (match); Sonraki Alicilar (next recipients); Dis Alicilar (external recipients); Zarf Dogrulandi (envelope verified); Gozlenen Dis Alicilar (observed external recipients); Aranmadi (not searched); Message-ID.
• Log trace columns: Gonderim Zamani (submit time); Queue-ID; Alici Sayisi (recipient count); Alicilar (recipients); MTA; Not (note).
• After the rows come the Notlar (notes), Ozet (summary: job, started by, criteria, total accounts, messages, steps, external recipients) and Aciklama (legend of the match types) blocks.

Notes and SIEM

The part of the query range older than the oldest log record on the MTA cannot be searched locally. The Notes box then gives concrete terms to search for in the information security log system (SIEM, central syslog): the MTA server, date range, postfix/smtpd from=<sender>, known Queue IDs, cleanup message-id=<…> and postfix/(lmtp|smtp) to=. The notes are written in Turkish.

Notes: SIEM search terms for an MTA log gap

If an MTA cannot be reached the job does not stop; a note is added that the MTA was unreachable and its envelope recipients could not be verified. Search that MTA's records in the SIEM.

Access and audit

• Global administrators can always use it. To give a delegated administrator access, a global administrator clicks Authorized admins, types the accounts one per line and clicks OK. Each account in the list must also be a delegated administrator. The right is checked on the server on every call; the authorized admin gets no mailbox rights.
• Authorized admins can search the whole server (no domain limit), but see only their own jobs in the list. A global administrator sees all jobs with their owners.

Authorized admins window

Every action is audited: starting a job (with its criteria), finishing, cancelling, viewing results, downloading the CSV, changing the authorized list, denied access and the cross-server account search. The lines go to the Zimbra audit.log and to /opt/zimbra/data/profelis-mailtrace/audit.jsonl. User audit 1.2.5 shows them on the Admin & sessions tab as readable text (for example "started a mail trace job", shown in Turkish). Plain status queries (job list, progress) are not audited.

Personal data

Trace results contain communication data. Keep the authorized list short and set report retention according to your organisation's data protection policy.

Limits

• Text fields at most 1024 characters, at most 1000 seed accounts, maximum steps 1-50.
• At most 3 active jobs per owner at a time (global administrators included); the server runs at most 2 jobs at once, the others wait as Queued.
• The CSV report is at most 20 MiB; narrow the criteria for larger jobs.
• A sent copy is needed: that a recipient passed the message on is found from that account's sent copy on the server. Submissions from clients that keep Sent items only locally (some Outlook / IMAP / SMTP setups), or whose sent copy was deleted, can be found only through recipient mailboxes and seed accounts. If you suspect forwarding from such an account, give the likely recipients as seed accounts.
• The Zimbra search index stores the attachment name (filename:) in each attachment's own part. When attachment name and body text are given together, the name is also searched as plain text; typing the full attachment name rather than a fragment gives the most reliable result.
• MTA records are limited by log retention; for older ones use the SIEM terms in the Notes.

Installation

Mail Trace has three parts and comes with the installation package: the com_profelis_mailtrace server extension (on every mailbox server, mailboxd is restarted), the admin zimlet of the same name and a read-only log helper on every MTA.

1. On every MTA server, as root:

   ./install-mailtrace-mta.sh
   ./install-mailtrace-mta.sh --verify
   

   The script puts pf-mailtrace-log and pf-mailtrace-ssh under /opt/zimbra/libexec/ and writes /etc/sudoers.d/profelis-mailtrace, which lets the zimbra user run only this helper as root (the log files belong to root). --uninstall removes everything.

2. If the mailbox server is also the MTA, nothing else is needed.

3. If the MTA is a separate server, the mailbox server connects to it with a dedicated ssh key (Zimbra's own key cannot be used for this):

   # on every mailbox server (root): the key is generated and the public key printed
   ./install-mailtrace-mta.sh --gen-key
   # on every MTA server (root): pass the public key line or the .pub file
   ./install-mailtrace-mta.sh --authorize-key '<public key line>'
   ./install-mailtrace-mta.sh --verify
   

   The key is written to /opt/zimbra/.ssh/pf_mailtrace_identity. On the MTA this key can only run the pf-mailtrace-ssh wrapper, which accepts nothing but a log query in the expected form. The command is idempotent; giving the same key again updates the line.

4. Host key checking is chosen with mtaHostKeyMode in /opt/zimbra/data/profelis-mailtrace/config.json: accept-new (default, records the key on first connection) or yes. The older OpenSSH on CentOS / RHEL 7 (before 7.6) does not know accept-new; use yes there and fill the zimbra user's known_hosts beforehand (ssh-keyscan).

Verifying the installation

Start a log trace for a known sender over a short range. If the Notes say that an MTA was unreachable or that the helper failed, check the --verify output on that MTA.

Operating notes

• Memory: the log helper loads the content-filter records of the scanned log files into memory to pair them. Roughly, 100,000 messages a day and 7 days of logs use ~100 MB of RAM and similar /tmp space; large 30-day logs can reach GB level.
• Narrow the range: the helper reads only log files newer than From. For a log trace pick a start as close as needed; for a content trace envelope queries are limited to ±24 hours around the message time.
• Search all accounts searches every mailbox one by one; run it outside working hours.