45 Million SMTP Services, 3,932 FortiMail Assets: Separating Protocol Exposure From Product Exposure

A recent measurement round produced a pair of numbers that are easy to combine and wrong to combine: 45,446,771 services matching service="smtp", and 3,932 assets matching app="FortiMail". The gap between them is roughly four orders of magnitude, and understanding why is the difference between a useful exposure report and a misleading one.

The measurements

All queries were run on 20 October 2026 between 22:32 and 22:37 UTC with sub_type="all" and a page size of one record. Totals are matched asset counts, not retrieved records.

Why the protocol count is not a product count

SMTP is a protocol, and the count describes every host that answers an SMTP conversation: relays, mail servers of every generation, appliances, honeypots, and embedded devices that speak SMTP for alerting.

app="FortiMail" describes assets whose fingerprint matches a specific product's signature. The two sets overlap but neither contains the other, and the sizes are not comparable.

Combining them in a report is a category error. So is using the SMTP count as a proxy for "exposed mail infrastructure" — an SMTP service on an appliance that does not accept external mail still counts.

The same logic applies to LDAP at 1,089,053. A host answering LDAP on some port is not necessarily a directory service holding identity data; it might be a device with an embedded directory or a decoy.

Where product-level data actually helps

The interesting comparison in this set is FortiMail against Zimbra and Roundcube.

FortiMail at 3,932 is a small observable population compared to Zimbra at 211,018 or Roundcube at 62,630. Those are different product categories — a mail transfer agent plus security appliance, a groupware platform, and a webmail client — so the numbers reflect adoption patterns rather than relative security.

What they do provide is a sense of scale for prioritization. An organization running FortiMail has a relatively small global peer group and a correspondingly small population that attackers can scan. An organization running Zimbra has a much larger observable peer group, which means automated scanning against that product family is likely to be extensive regardless of any specific CVE.

The geographic split for FortiMail — 328 in the United States out of 3,932 globally, about 8.3% — suggests a deployment base that is not concentrated in a single market. That is a useful input when estimating whether a campaign targeting one region would affect a given estate.

Building a mail-exposure view that holds up

A workable approach uses three layers, each with a different purpose.

Protocol layer. Confirm which of your addresses answer SMTP from the internet, and whether they should. This is a reachability audit, not a vulnerability scan.

Product layer. Use fingerprint queries for the specific mail platforms you operate, to find instances you did not know were internet-facing. The value is inventory reconciliation, not severity assessment.

Configuration layer. Determine which of those hosts accept mail from arbitrary senders, which terminate user sessions, and which hold directory bind credentials. Only internal data answers this, and it is the layer that decides actual risk.

The first two layers are cheap and can be automated. The third requires a person who knows the mail architecture, and it is the only one that distinguishes a benign relay from a system whose compromise would expose credentials.

Reading a small number correctly

A count of 3,932 can look reassuringly small in a report. It should not. Small observable populations still include the systems that matter, and a targeted operation does not select victims by scanning a population uniformly.

The relevant question is never how many assets exist globally. It is whether one of them is yours, whether it is patched, and whether anyone would notice if it stopped behaving normally.

References

• ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
• Fortinet, PSIRT advisory channel.
• CISA, Known Exploited Vulnerabilities Catalog.