Size limits and bounces in MailGuard

Two settings that rarely come up in daily use and are the first questions when something goes wrong: how large a message may be, and what happens to delivery status notifications a mailbox never expected.

Per-tenant message size limit

The limit lives in the policy under General → Maximum message size. It applies to the complete message including all attachments and their encoding, not to the size of the attachments on disk. A 20 MB file becomes roughly 27 MB in transport because of base64 encoding.

The limit only works downwards. No policy can exceed the instance limit; that one is the ceiling for every tenant and sits at about 34 MB. Anyone who needs more sends the file through SecureFiles instead of as an attachment.

If the sending side announces the size during the dialogue, which is the normal case, the message is rejected with 552 immediately, before a single byte of content is transferred. That helps the sender: the notice saying the message was too large is then written by their own server, in wording they understand. If the sending side announces nothing, or announces a wrong size, the check after the transfer applies. The outcome is the same; only the path there costs more.

A disabled policy checks nothing. Only the instance limit remains.

Attachment limit

The policy carries a separate limit per attachment. Both work together: a message with five attachments, each below the attachment limit, can still exceed the message limit.

Virus scanning has its own ceiling. An attachment too large to be scanned is not delivered unscanned. The message is deferred with 451 and the delivery attempt repeats. There is no path anywhere that delivers unscanned mail.

Bounces and backscatter

A delivery status notification is a message without a sender. That is exactly what makes it abusable: sending spam with one of your mailbox addresses as the sender to thousands of invented recipients makes thousands of destination servers send a report to that mailbox. Every report carries the spam as an attachment. This is called backscatter.

MailGuard checks every incoming report against its own message tracing and against the tenant's domains:

• Verified. The message the report refers to has a row in message tracing. We delivered it ourselves, so the report belongs to it.
• Misdirected. The report refers to a message from a foreign domain. There is no path on which such a report could legitimately reach you. It is not delivered and appears in message tracing as a discarded bounce.
• Unverified. Everything else. The report does not name the original message, or it names one from one of your domains for which we have no row, for instance because it was not sent through MailGuard. These reports are delivered and carry the header X-Conbool-Bounce-Check with the result, so a mailbox rule can sort them.

Only the unambiguous case is discarded. That is deliberate: a discarded genuine bounce means a sender never learns that their message did not arrive, and that is the more expensive mistake.

Mail that goes through sender address rewriting additionally carries a signature in the address itself. Those reports can be attributed beyond forgery, independently of the three cases above.