Mail servers and document collaboration suites are the two categories where the internet-facing surface is the least likely thing to sit behind a CDN. They terminate their own TLS, they own their own hostnames, and they are usually the oldest continuously running service in an organisation.

Counts from 28 October 2026

ZoomEye queries returned the following. Title:"Exchange" 101,582 and app:"Exchange" 8,490. App:"Zimbra" 149. App:"Roundcube" 49. Title:"ONLYOFFICE" 241,809 and app:"Collabora" 15, with title:"Collabora" 2,180.
The mail numbers describe a persistent, self-hosted surface. Exchange title matches exceed application matches by more than an order of magnitude, which is the familiar attribution gap: an Outlook Web App login page identifies the product to a human and not always to a fingerprint engine.

Why this surface stays exposed

Three reasons recur.
Remote access is the product. A mail server that is reachable only from a VPN is a mail server that users complain about. The pressure to publish it is architectural, not careless.
Upgrade cycles are long. Mail and groupware migrations are the projects that get deferred, so a suite installed in one year is often still serving in the fifth.
The perimeter is compound. A single deployment can present webmail, ActiveSync, autodiscover, SMTP submission and an admin console, each with its own path and its own authentication behaviour. Hardening one path does not harden the others.

Where the risk concentrates

For mail, the historically productive attack surfaces are webmail authentication, the autodiscover endpoint, and the administrative interface when it is reachable from the same address space. Each has produced exploited vulnerabilities in recent years, and each is frequently the component that was not in the patch scope.
For document collaboration, the pattern shifts to proxy and connector components. OnlyOffice and Collabora both provide a document server that fetches files from a storage backend; the interesting bugs are usually in that fetch path, for example proxy or URL handling that lets a crafted request reach something it should not.
The 241,809 ONLYOFFICE title matches and the 2,180 Collabora title matches suggest a substantial population of document servers published directly. Whether they sit behind an authenticating proxy is not visible from the count.

Reading the numbers honestly

Title matching is a coarse instrument. A title:"Exchange" match may be a webmail page, a health endpoint, an error page, or a redirect that happens to carry the product name. The counts are useful for sizing and useless for identifying a specific version or patch state.
Application fingerprints are the opposite: precise when they fire, silent when they do not. Where the two disagree by an order of magnitude, the honest statement is a range, and the article should say so.

A short checklist for this surface

Enumerate every hostname that resolves to a mail or document server, not just the primary one. Autodiscover and the document server are routinely forgotten.
Confirm whether the administrative interface is reachable from the internet. If it is, that is the finding.
Track the vendor advisories for the specific edition, and keep the connector and proxy components in the same patch scope as the main application.
Put a reverse proxy with authentication in front of document servers that do not need to be public, and check afterwards that the original port is closed rather than merely unpublished.

References

  • ZoomEye queries collected 28 October 2026: title:"Exchange" 101,582; app:"Exchange" 8,490; app:"Zimbra" 149; app:"Roundcube" 49; title:"ONLYOFFICE" 241,809; app:"Collabora" 15; title:"Collabora" 2,180: https://www.zoomeye.org

  • ZoomEye query syntax reference: https://www.zoomeye.org/doc