Zimbra Block Attachments

Executable and script attachments are a classic malware vector, so blocking risky file types is a basic mail-server control. To make Zimbra block attachments you have two realistic options: the native zimbraMtaBlockedExtension mechanism, or a component in the mail path that inspects the message body.

The native route is a global extension list that affects the whole message. This page walks through it honestly - including a working .exe setup - covers where the bundled ClamAV scanner fits, and then shows how MSH Zimbra Rules blocks or strips attachments with clear policy rules.

The native way: zimbraMtaBlockedExtension

Zimbra keeps a global list of blocked attachment extensions, enforced by amavisd. Add the usual executable and script extensions with zmprov (as the zimbra user):

zmprov mcf +zimbraMtaBlockedExtension exe \
  +zimbraMtaBlockedExtension bat \
  +zimbraMtaBlockedExtension scr \
  +zimbraMtaBlockedExtension vbs \
  +zimbraMtaBlockedExtension js

You can also decide whether the recipient is told about the blocked message, then restart the MTA stack so amavisd picks up the change:

zmprov mcf zimbraVirusWarnRecipient TRUE
zmmtactl restart
zmamavisdctl restart

This stops the obvious cases, but it has real shortcomings:

• Global only. The extension list applies to the entire system - one policy for every domain, direction, and user.
• Whole-message handling. The message is rejected or quarantined as a whole - you cannot strip the bad file and deliver the rest.
• Filename matching only. It keys off the declared extension, so a renamed .exe slips straight through.
• No size logic. Blocking oversized attachments is a separate mechanism entirely.
• Coarse scope. Applying different policy to inbound vs outbound mail, or per department, is not possible with one global list.

Where the bundled ClamAV fits

Zimbra ships with ClamAV running behind amavisd, and it is fair to ask whether that already covers attachments. It solves an adjacent but different problem.

A virus scanner answers "is this file known malware?" by matching it against a signature database. Attachment policy answers "is this file type allowed here at all?" Those come apart precisely where it matters: a brand-new executable with no signature yet passes ClamAV cleanly, while a type-based rule stops it regardless of whether anyone has seen it before.

You want both - the signature scanning Zimbra already provides to catch known viruses, and an attachment policy as the blunt instrument that does not depend on threat intelligence being up to date.

Policy rules with MSH Zimbra Rules

MSH Zimbra Rules handles attachments with policy rules. You match attachments by name, type, or size, and choose whether to block the message or strip the attachment and deliver the rest - all from a readable rule editor in the web administrator panel.

Three ways to match, so regex stays optional

Attachment name and type conditions each support exact text, wildcards, and regular expressions. Everyday rules need nothing more than a wildcard, and the full regex engine is there when a rule genuinely calls for it - unlike a bare extension list, matching is a choice rather than a single global setting:

• Exact - match one specific filename or MIME type.
• Wildcard - *.exe for executables, text/* for any text format, or *.zip.exe to catch the double-extension trick.
• Regular expression - .*\.(exe|bat|cmd|scr)$ when you want several extensions in a single rule.

Set it up in four steps

1. Install MSH Zimbra Rules on the Zimbra server and connect the milter engine to Zimbra's Postfix with a few zmlocalconfig settings.
2. Create a policy rule with an attachment condition for name, type, or size.
3. Choose the action - block the whole message, or strip just the matching attachment and deliver the rest.
4. Test and enable with the built-in rules tester.

Because rules can be scoped by direction and sender or recipient, you can block dangerous inbound files while applying different limits to outbound mail. Stripping matters more than it sounds: rejecting a message because of one bad file means the sender has to work out what happened and resend, whereas stripping delivers the correspondence and drops only the attachment.

Which approach should you use?

If you only need to reject a handful of executable extensions across the whole system, the native list is enough and costs nothing. Once you need stripping, size limits, per-direction or per-domain policy, or rules that colleagues can read a year from now, a single global extension list stops scaling - not because the mechanism is broken, but because it is the only tool Zimbra gives you for the job.