What is “mail in a closed network” and how does it differ from regular mail?

A closed network is an isolated environment without direct Internet access; external exchange goes through controlled points (for example, a gateway), and updates and checks follow internal procedures. The key difference is that you must choose the platform based on how it will be operated and secured under constraints, not only by its interface features.

Where should I start when choosing a platform for a closed network?

Start by describing the isolation model: is there a DMZ, how is external mail accepted and sent, and how are updates brought in and approved. Then document 10–15 mandatory requirements for security, operations, migration and retention, and compare solutions using the same checklist.

Do I need a separate gateway and DMZ, or can I use a single mail server?

In most cases you need a perimeter mail gateway that handles controlled inbound/outbound traffic, primary filtering and breaks direct connections between the internet and internal servers. This reduces risk and simplifies routing rules for branches and during outages.

How do you organize platform updates without internet access?

Plan the process as for an "offline" organization: a separate test environment, compatibility checks with OS/virtualization, a clear rollback plan and integrity checks for packages (hashes/signatures) per your procedures. Predictability and manageability of updates matter more than release frequency in a closed network.

How many users are enough for a pilot and who should be included?

A pilot is best run with 50–100 users or at least with the “complex” roles that stress mail differently: secretaries, managers, lawyers, IT. The pilot’s goal is to verify real operations in your isolation: delivery, search, delegation, mobile access, anti-spam and recovery scenarios.

What usually breaks during mail migration in a closed network?

Plan to move not only messages but also calendars, contacts, shared mailbox permissions, delegation, rules and auto-replies. A practical approach is parallel delivery to old and new systems during transition and a pre-agreed rollback scenario so the business doesn’t lose hours or days if something fails.

How to evaluate anti-spam and anti-virus when you can’t rely on external services?

Rely on checks that work locally: rules, signatures, attachment policies, quarantine and managed exceptions. In a pilot measure not only “how much was caught” but the cost of errors: false positives, delivery delays and how clear the block reasons are for admins.

What should I look for in mobile clients for a closed network?

First define which devices you actually support (corporate, BYOD, tablets) and which policies are mandatory: PIN, auto-lock, remote wipe, restrictions on attachments and copy/paste. Then test offline mode, search, handling of large attachments and correct calendar/invitation behavior under poor connectivity.

How does archiving differ from backup and which is more important?

Backups are for restoring service after a failure; an archive is for keeping correspondence per rules and quickly finding and exporting it for audits and investigations. For evidentiary use you need immutability, separate access roles and a full audit trail of search and export actions.

How to plan recovery after failures and requirements for hardware?

Start by defining RPO (how much data may be lost) and RTO (how quickly mail must be restored), then design architecture and procedures to meet those figures. Run regular test restores, consider the storage subsystem—I/O is often the bottleneck for indexes, journals and databases—and keep copies in a different room or rack.

Mail platforms for closed networks: how to choose

Where to start when choosing mail for a closed network

A closed network means mail in an isolated environment: no direct Internet access, limited exchange channels and strict security rules. Here, not only features matter but also how the platform behaves under constraints: how you install updates, how you accept external mail, how you handle outages and how you demonstrate compliance.

The first questions usually aren’t about Zimbra, HCL Domino, or CommuniGate Pro. They’re about the framework: is there a DMZ gateway, is external exchange required (and through what), what are the logging and retention requirements, who approves updates. If patches may be applied only after internal testing, then release schedules, OS and virtualization compatibility, and rollback capabilities become more important than a list of “nice” options.

Four risk areas commonly surface: delivery and routing, protection from spam and malicious attachments, mobile access, and recovery plus long-term retention.

The platform choice affects support and costs for years. In a closed network “cost” is not just licenses but daily operations: how easy it is to find and train admins, how fast patches are applied, whether there are practical migration and backup tools, and whether mail can be scaled reliably across branches.

A practical start is to briefly describe the isolation model (perimeter, gateways, update rules), then gather 10–15 mandatory requirements and only then compare solutions using the same scheme. That makes the choice based on real operations, not demos and promises.

Zimbra, HCL Domino, CommuniGate Pro: what you actually buy

When choosing a platform for an isolated network it helps to remove marketing and break the offering into clear parts: what the platform itself provides and what typically gets deployed alongside it.

Zimbra is often chosen as a "classic" corporate mail with a strong web client and a straightforward admin interface. It fits well when common scenarios are needed: mail, calendar, contacts, delegation and shared mailboxes.

HCL Domino is often selected for more than just mail. For many it’s an ecosystem where mail is part of internal apps and processes. If you already have Domino legacy or plans for forms and databases, the platform’s value increases significantly.

CommuniGate Pro is usually seen as a “mail server plus communications” solution that emphasizes flexibility, routing rules and support for multiple protocols. It’s often chosen when nonstandard domain schemes, complex delivery policies and integrations are important.

Out of the box you typically get a server component, web interface, synchronization (at least calendars and contacts), admin tools, and roles and permissions. But real projects almost always need an edge gateway, antivirus scanning, backups, monitoring and archiving (if correspondence must be kept for years).

To read vendor claims correctly, check the things that will hurt every day: how shared mailboxes and delegation work in the interface, how easily policies are set (passwords, MFA, quotas), what happens when a node fails and how long recovery takes, how mobile devices connect in your model (with or without MDM), and what logs and reports are actually available for incident investigations.

A good validation format is a pilot with 50–100 users doing typical tasks. It quickly reveals the difference between “we can do it in theory” and what reliably works in isolation and under your rules.

Architecture and security: what matters in isolation

In a closed network the main question is how mail will operate without constant access to external services: updates, cloud reputation checks and third-party directories. Architectural mistakes are hard to fix later without downtime.

Start with protocols and compatibility. If some users need Outlook, mobile sync and calendars, clarify in advance what will work over IMAP/SMTP, where ActiveSync is required, and which features (tasks, shared calendars, delegation) are truly supported without workarounds.

Accounts deserve special attention. Closed networks usually already have AD/LDAP, groups and password policies. Mail must fit your domain structure, support MFA if required, and provide clear admin roles and separation of duties.

Map mail flows ahead of time. There will almost always be internal exchange and controlled entry/exit points via a gateway, relays and a DMZ (if present). For branches decide in advance where the central node will be, what happens if links break, and how to handle messages that must not be lost.

Before the pilot lock down basic security requirements: TLS across all segments and acceptable ciphers, work with an internal CA (issuing and rotating certs, lifetimes, key rotation), audit and logs (who logged in, what changed, who delegated access, what was deleted), log export to SIEM and retention periods, backups of configs and key data so recovery is predictable.

A simple example: in a multi-city organization, separate branch and central security admin roles. Local tasks are solved quickly while central security keeps control and investigations.

Migration without downtime: plan and control points

Mail migration in a closed network usually fails on data transfer and careful cutover, not on platform install. Common sources are Microsoft Exchange, IMAP servers, local PST files, and standalone archives accumulated by accounting or security. The sooner you consolidate these sources, the fewer surprises at the end.

Don’t migrate only messages. Calendars, contacts, distribution lists, shared mailbox permissions, delegation and rules are critical. If these are lost, the project will be considered a failure even if messages are intact.

Before the pilot collect baseline numbers: count of mailboxes and total volume, average and max mailbox size, share of large attachments and messages over the last 1–3 years, peak loads (mornings, reporting days, mass mailings), and retention and legal-archive requirements.

Run pilots with real users, not just "test" accounts. Choose 20–50 people from different roles: secretaries (calendar-heavy), lawyers (search and attachments), IT (rights and shared mailboxes), and managers (mobile access). Agree on success criteria and rollback steps in advance.

Keep pilot criteria simple: data present (mail, calendar, contacts), search performs within acceptable time, mobile mail connects using the guide, shared mailbox rights match the source, and support resolves typical requests within agreed times.

Do the cutover in a short window but prepare it in advance: parallel delivery to old and new systems, forwarding, correct TTLs for DNS records, and brief user instructions. In branch networks it’s often easier to convert the head office first, then roll out waves to branches, checking control points after each wave.

Anti-spam and antivirus: how to judge filtering quality

For a closed network anti-spam and antivirus are part of mail resilience, not a checkbox. A filtering error either lets phishing through or blocks an important document. Judge by results, not promises.

Decide where filtering happens. In practice multi-layered filtering is common: at the perimeter (gateway), on the server (platform policies and checks) and partly on the client (labels, warnings, manual spam reporting). The stricter the isolation, the more crucial it is that key checks run locally and don’t rely on external reputation services.

Quality is best tested in a short pilot on your real mail (or an anonymized sample). Look not only at detection rates but at error cost: false positives, missed spam, delivery impact, clarity of block reasons, and ease of creating exceptions (per department or recipient).

Greylisting, SPF/DKIM/DMARC matter, but they must be adapted to your isolation. If mail leaves through a limited set of gateways, SPF and DKIM should be configured for those sources and DMARC used as an authentication policy. Test forwarding and mass mailings carefully—authentication often breaks there.

Agree in advance on attachment policy: what is blocked, what goes to quarantine, who receives notifications and who can release items. Useful tests: office files with macros, passworded archives, executables, and double-extension files.

Don’t forget internal spam: in large organizations it looks like company-wide mailings, system notifications and accidental “reply-all”. It’s good to have limits, moderation for large mailings and clear rules for service accounts.

Mobile clients and user convenience

Initial architecture consultation

We'll discuss your isolation model, DMZ and security requirements before choosing a platform.

Request consultation

In a closed network mail often becomes a single pane for tasks: messages, meetings and approvals. Mobile convenience matters as much as server-side capabilities.

Decide which devices you will actually support. In some organizations all devices are corporate, in others BYOD is allowed, and some use tablets in the field or classrooms. That affects whether strict control via MDM is required and how rigid policies must be.

Native clients are usually more convenient: notifications, better offline behavior, and faster attachment opening. Web clients are easier to maintain: update the server and the interface is uniform for everyone. A common approach is hybrid: web for occasional users and native clients for heavy users.

Test behavior under poor connectivity: basements, factory floors, and between branches. You need stable offline mode, fast search, proper handling of large attachments and a reliable outgoing queue.

Phone security: more than just a device PIN

Minimal centrally enforceable policies to enable: PIN or passcode with auto-lock, encryption (if supported), blocking copy to personal apps (for BYOD), remote wipe of corporate mail on loss, and restrictions on attachments and file types.

Calendar and meetings: a small thing that can break processes

If you have many meetings, test invites and free/busy: creation, acceptance, rescheduling, recurring events, time zones and room resources. A common scenario: a branch employee accepts an invite on the phone while traveling and changes must immediately appear to the secretary and colleagues in the closed network.

A good test before selection: give 10 users different roles (manager, secretary, field worker) and have them live on the mobile client for a week. This quickly shows where support demand will be highest and what training users need at launch.

Archiving, retention and recovery

In a closed network an archive is not for convenience but for evidence. It becomes mandatory when retention rules, audits, investigations, litigation and auditor requests apply. You need not just a copy but the ability to prove messages were not altered.

A practical approach is to make the archive a separate environment with clear roles. Regular mail admins shouldn’t be able to “clean up” history. A good archive supports immutability (WORM-like behavior), separate access rights and detailed logging: who searched, what they opened and what was exported.

Search and exports often decide the outcome of an incident. Imagine a leak complaint: security needs to quickly find related messages, export a thread, and show the action log. Verify how reports are generated and whether exports can be restricted to authorized staff.

Backup and archive are not the same. Backup restores service after a failure; archive stores correspondence per rules and provides searchable access.

Before choosing check: retention periods and deletion policies (including legal hold), role separation (admin, compliance, security), audit trails and search/export reports, export formats acceptable to legal/auditors, and support for immutable storage.

Define recovery targets numerically. Set RPO and RTO, then implement at minimum: regular test restores (not just “backup completed”), copies stored offsite or in a different rack, separate copies of keys and configs, and partial recovery scenarios (one mailbox, one server).

Operations and support: day-to-day reality

Mail pilot in a closed network

We will help organize a pilot and success criteria with real users and scenarios.

Schedule a pilot

After launch most time goes to small daily tasks: updates, delivery monitoring, disk space, certificates and user requests. Evaluate the platform by how easy it is to operate in isolation.

Updates must be predictable. You need a clear release schedule, a test environment and a simple rollback plan. In a closed network plan how packages and signatures are transferred and who verifies integrity (hashes, signatures, install logs).

Monitoring should catch problems before users complain. Minimum daily checks: mail queues and growing delays, disk usage and growth rates, TLS certificate expiry, authentication errors and spike in blocks, AV/anti-spam health (database updates, false positive rates).

Choose redundancy based on real risks. A small organization may manage with one server plus backups. Branch networks usually need geographic separation or clustering so a failure doesn’t halt operations.

Prepare an "admin folder" to avoid chaos. It should include update and test procedures, backup and restore schemes, a list of common incidents and escalation paths, an access matrix and privilege registry, and maintenance windows and contacts for users.

Common mistakes in selection and deployment

A frequent mistake is choosing mail by a features table and deploying it like a simple server. For a closed network this often leads to downtime, user complaints and emergency hardware purchases.

One early error is underestimating storage I/O. Mail databases, search indexes and logs like fast disks. If you count only total volume and ignore IOPS, the system will be slow: searches lag, messages open slowly and backups don’t fit windows.

Another classic mistake is migrating without a pilot and rollback plan. On cutover day you may find some clients won’t connect, several departments lost rules, and executives can’t open old messages. Without a prepared return plan the business loses hours or days.

Third mistake: overly broad admin rights and no audit. In isolation it’s vital to know who created mailboxes, granted access, changed policies and viewed logs. Otherwise incidents turn into “who pressed the button” arguments instead of fact-based investigations.

People are often underestimated. Even the best platform won’t help if users aren’t trained in basic rules and haven’t seen typical phishing examples.

Useful pre-launch mini-check:

verify disk and search load on real mailboxes
run a pilot on one group and document rollback steps
limit admin roles and enable auditing of key actions
separate backup and archival policies
provide short training and a phishing simulation

In branch environments don’t forget to test over slow links. In the pilot specifically run mobile sync, search of old mail and delivery times for large attachments. It’s cheaper than reworking the project after launch.

A short checklist before the final decision

Before comparing licenses and interfaces, document why you need mail in a closed network. The same product may be fine for 300 users in one office and hard to support for 5,000 employees across branches with mobile devices and diverse access rules.

Create a short profile: current mailbox count, expected growth in 2–3 years, critical services (calendar, shared mailboxes, meeting rooms, directory integration, signatures, encryption). Note isolation constraints separately: can updates be applied through a delivery window, and who approves update packages?

Then test the solution in a small pilot on real data. Choose 10–20 “complex” users: many folders, shared calendars, delegation and mobile devices.

Quick checks before selection:

migration: move mail, calendars and permissions without loss and have a clear rollback plan
anti-spam: run your typical mail stream including newsletters, invoices and notifications and assess false positives
mobile access: supported clients, policies (PIN, encryption, copy restrictions), compatibility with your MDM
archive and search: retention periods, access roles, legally valid exports, search speed on large mailboxes
support: who handles incidents, how backups and updates are done, how recovery is tested

If the organization has branches and 24/7 shifts, clear recovery procedures and an on-call support scheme matter more than the richest feature set.

Example scenario: deployment in an organization with branches

GSE servers and workstations

We will pick GSE hardware for mail and related services with appropriate redundancy.

Select servers

Imagine a government agency or regional hospital with 800–1,500 employees and a closed network. There’s a central office and 10–20 branches, some with slow links. Mail is used for requests, notifications and document exchange, so a one-day outage quickly causes a backlog.

Legacy is usually mixed: some users on old mail, departments with dozens of shared mailboxes (for example registratura@, procurement@), many distribution lists and permissions set up over time. Before choosing, document which mailboxes are critical, which integrations rely on SMTP, and who owns each mailing list.

A 4–6 week pilot should mirror reality, not a showroom: 5–10% of users from different roles, migrating several shared mailboxes and 2–3 busiest mailings, anti-spam in operational mode with clear exceptions, archive tests (search, retention, restore), and mobile access per approved policies.

Measure pilot success by facts: no message loss, delivery delays within norms, manageable false positives, archive restores in minutes, and support closes routine requests per the SLA.

Before mass rollout prepare documentation: naming and ownership rules for shared mailboxes, permission matrix, retention and archive policy, mobile access procedure, rollback scenario, and user and admin guides.

Next steps: from comparison to project

Once comparisons are done, turn them into a plan. In an isolated network success depends less on “which platform is best” and more on “how you implement and operate it.”

Consolidate requirements into one document and agree what is critical: mailbox and calendar migration without loss, filtering quality on internal and external flows, mobile convenience, archiving rules, and support response times.

Then move to the project:

describe target architecture: roles (mail, directory, gateways, archive), network zones and how external exchange is handled
assess migration: sources (Exchange, IMAP, PST), order of user moves, and double-delivery during transition
size infrastructure for 3–5 years: CPU, RAM, storage IOPS, growth volume, redundancy and backups, test environments
prepare a pilot on a small group and define pass/fail criteria in advance
build a work schedule with responsibilities: security, network, admins, support and business owners

If you lack in-house experience with isolated networks, consider a systems integrator who can design architecture, select servers and storage, and organize operations. For example, GSE.kz (gse.kz) as a vendor and integrator can cover infrastructure and 24/7 support, which is useful for organizations with branches and shift schedules.