Limits, response codes and headers of the gateway

Technical key figures of the Conbool gateway: port and TLS, maximum message size and recipient count, behaviour on errors, SMTP response codes, loop protection and all headers and host names it sets.

This page collects the technical key figures of the gateway in one place: what is accepted, what is rejected, which answer goes back and which traces Conbool leaves in a message. All values apply to cloud operation. Partner and on-premises installations run with their own configuration and can differ, the authoritative values are held in the respective instance.

Connection, port and TLS

Mail flow runs exclusively over SMTP on port 25, in both directions. Delivery to the relay host of the domain and to a smart host also uses port 25. A different port is not provided for.

There is no SMTP authentication. The gateway does not advertise AUTH and does not serve it. Permission to send follows from the SPF record of the domain, described under SPF and DKIM.

STARTTLS is offered as soon as a certificate is available. Encryption starts at TLS 1.2, the cipher order follows BSI TR-03116-4 and is enforced server side. Connections without TLS are accepted, because an accepting MX must not let mail fail on encryption. For the outbound path a separate strictness applies per target: if the target publishes DANE or MTA-STS, the certificate is verified and, if verification fails, no unencrypted delivery takes place. International addresses are supported through SMTPUTF8.

Limits per message and per connection

Message size: 36,214,400 bytes per message, measured on the transferred size. Since attachments are encoded for transport and grow by about a third in the process, this corresponds to roughly 25 MB of attachments. Larger files belong in SecureFiles.
Recipients per message: 500. Further recipients are rejected individually with 452, the connection stays open and the message goes to the recipients already accepted.
Idle: an inbound connection without data flow ends after 180 seconds.
Patience when delivering: Conbool waits up to 60 seconds for the greeting of a target server and 30 seconds for the connection to be established. A slow target server therefore does not immediately cause a delay.
Rates: connections and messages per sending IP and minute are limited. The limits are far above normal business traffic and in regular operation only affect bulk senders.
Repeated rejection: three rejected delivery attempts from the same address lead to a block for two hours. Well-known large providers are exempt.

What happens on an error

For regular delivery Conbool keeps no queue of its own. If delivery to the next server fails temporarily, the gateway returns a 4xx error to the delivering server. That server retries according to its own rules.

One frequently asked question answers itself from this: the retry rhythm and the queue lifetime are determined by the delivering server, not by Conbool. Exchange Online gives up after about a day, Postfix keeps a message in the queue for five days by default. Only after that does a non-delivery report appear, and it appears there, not at Conbool.

If the error is permanent, the gateway answers with a 5xx code. The non-delivery report to the sender is then also created by the delivering server.

Where several target servers are available, Conbool tries them one after another before a temporary error goes back.

Response codes that come from the gateway

452 4.5.3 The recipient limit per message has been reached.
451 4.7.1 Too many connections or messages from this address in a short time.
550 5.7.1 Access denied from your address The address is blocked after repeated failed attempts.
550 5.7.1 A relay host is required No relay host is stored for the recipient domain. To be added under connecting a domain.
554 5.4.14 The message was routed too many times The message is circling, see loop protection.
451 without further detail after long processing: the content check exceeded its time budget. In enforce mode delivery is then delayed rather than unchecked. The delivering server retries, and as a rule the message goes through on the second attempt.

Response codes from other sources can be recognised by the identifier of the reporting system. A 554 5.4.1 Hop count exceeded with a protection.outlook.com identifier comes from Microsoft, for instance, not from Conbool.

Loop protection in figures

Three limits apply independently of one another.

More than 30 foreign Received lines in the topmost header block lead to rejection with 554 5.4.14. Only the topmost block is counted so that attached reports and forwarded messages do not count towards it.
If the gateway detects the same message re-entering, it counts this in X-Conbool-Relayed. From the fifth pass it rejects.
On pass-through within the same tenant, for instance with out-of-office replies and calendar invitations, the path ends after twelve hops. The circling copy is accepted and discarded so that no flood of non-delivery reports arises.

There is ample distance to normal traffic: legitimate mail typically reaches one to five hops. Anyone investigating a loop finds the most common causes under Exchange connectors.

Headers that Conbool sets

These headers appear in processed messages and can be evaluated in your own rules.

X-Conbool-<domain>: true confirms that the message has already passed the gateway for this domain. Dots in the domain become hyphens, so example.com becomes X-Conbool-example-com. This header carries the loop protection in Exchange.
X-Conbool-Flag: YES marks a message scored as spam. The transport rule in Exchange then sets the spam confidence level.
X-Conbool-Released: yes is carried by a message released from quarantine, complemented by X-Conbool-Released-By and X-Conbool-Released-From.
X-Conbool-Relayed is the counter of the loop protection.
X-Conbool-System: yes marks messages Conbool creates itself, such as quarantine notifications. Your own rules should not process these messages again.
X-Conbool-Trace carries the identifier of the tenant and serves to attribute non-delivery reports.
X-Conbool-Orig-Client-Ip preserves the original address of the delivering system across internal processing steps.

In addition there are the usual records of sender authentication: Authentication-Results with the identifier mail.conbool.com, an ARC seal with d=arc.conbool.com and selector arc1, and the outbound DKIM signature with your own domain. Its selector belongs to the domain and is shown in the setup wizard at the DNS step, commonly conbool1.

Names in the mail flow

mail.conbool.com is the gateway, smart host, identifier in the authentication results and the name in the TLS certificate.
bounces.conbool.com appears as the envelope sender of forwarded messages. This is sender rewriting under SRS and keeps the return path for non-delivery reports working when the path runs through Conbool. A softfail in SPF for this domain on a connection that does not come from Conbool marks exactly this return path and is not a fault of your own configuration.
arc.conbool.com seals inbound messages. Registering it as a trusted sealer is described under Exchange connectors.
journal.conbool.com receives archive copies, see archive setup.

The delivering addresses of a domain are shown in the portal under Settings, Domains in the mail server field. They are kept there and not here because partner and on-premises installations deliver from their own instance.