IP Connections

The IP Connections page (Manage > Connections) is a live monitor of every IP address currently connected to the mail server. Rather than showing individual mailboxes or sessions, it groups activity by IP address, which makes it the fastest place to answer the question "who, or what, is hitting my server right now?" Connections are broken out across nine tabs: All Connections, and then one tab per protocol — Webmail, SMTP, IMAP, POP, XMPP, EAS (Exchange ActiveSync), MAPI & EWS, and WebDAV. From here, a system administrator can blacklist an abusive IP address outright or forcibly drop its current connections without leaving the page.

It's worth emphasizing exactly what the numbers on each tab represent: they are a count of total connections, not a count of unique IP addresses. If the IMAP tab shows "7," that means there are 7 active IMAP connections open right now — which could be 7 different users connecting once each, a single user connected from 7 devices, or anything in between. The grid itself, sorted by IP address, is what tells you how those connections are actually distributed.

Why the Menu Count and the Grid Count Can Differ

System administrators frequently notice that the connection count shown as a badge next to Connections in the left-hand navigation menu doesn't exactly match the count on the All Connections tab once the page is open. This isn't a bug — it's a difference in how each number is refreshed:

• The navigation menu badge is pushed to the browser automatically in the background (via a SignalR connection) on a short, fixed interval measured in just a couple of seconds, for as long as an administrator is logged in. It updates continuously without any action on the administrator's part.
• The grid on the All Connections tab, by contrast, is a snapshot. It's accurate the moment the page loads, but it will not update again on its own — it only refreshes when the administrator clicks the Refresh button, or performs an action (like blacklisting or dropping a connection) that reloads it.

In practice, this means the menu badge is the better real-time indicator of overall load — if it's climbing quickly, that's worth investigating — while the grid is the tool for actually drilling into which IP addresses are responsible. Click Refresh on the grid to bring its count back in line with the menu badge before drawing any conclusions from a discrepancy between the two.

Available Columns

When viewing connections, on any tab, the following columns are available:

• IP Address – The IP address of the remote host connecting to the server.
• Country – The country associated with the IP address, as resolved by SmarterMail's IP geolocation lookup. This is one of the fastest ways to spot suspicious activity: a login attempt from a country where the organization has no staff or customers is worth a second look.
• Port – The port the connection came in on. This will generally stay constant within a given protocol tab (for example, 993 for SSL IMAP), but if a protocol is bound to more than one port – such as both an unencrypted/StartTLS port and a dedicated SSL/TLS port – connections on either port will appear together on that protocol's tab.
• IP Connections – The number of simultaneous connections open from that specific IP address, for the protocol (or protocols, on the All Connections tab) currently being viewed. It's normal for this number to be greater than 1 for a single IP; that's expected when a user is connected to their account from an email client on their desktop, a mobile client on their phone, and a webmail session in a browser simultaneously, all from behind the same router or NAT gateway.
• SSL/TLS – Whether the connection listed is secured with SSL or TLS encryption.

Actions

The following buttons/actions are available regardless of which tab is currently selected:

• Refresh – Reloads the grid with the current, up-to-the-moment list of connections for the selected tab.
• Actions (⋮) – Select one or more rows using their checkboxes (or right-click a single row) to reveal this menu, which contains:
  • Blacklist – Opens a dialog to add the selected IP address (or addresses) to the server's IP blacklist.
  • Drop Connections – Immediately terminates the selected IP address's current connection(s).
  • Copy IP – Copies the IP address of the row that was right-clicked to the clipboard, a convenient shortcut when the address needs to be pasted into a firewall rule, a WHOIS lookup, or a support ticket.

Blacklist

The Blacklist dialog writes directly to the same server-wide IP blacklist documented under Security > Blacklist/Whitelist – there is only one blacklist, regardless of which page an entry was added from. A few details are worth knowing before using it from this page:

• Addresses field – If multiple rows were selected before opening the dialog, all of their IP addresses are pre-filled here as a comma-separated list. This field also accepts an IP range or CIDR-style entry, so a single blacklist entry can cover an entire block rather than one address at a time (for example, to blacklist an entire hosting provider's netblock after repeated abuse from addresses within it).
• Description field – Unlike the equivalent action on the Spool Overview page, which automatically fills in a description noting the entry came from the spool dashboard, the description field here is left blank by default. It's worth taking the extra few seconds to type a meaningful note (e.g., "Repeated failed IMAP logins, 7/15") so that anyone reviewing the Blacklist/Whitelist list later understands why the entry exists.
• Protocol toggles (SMTP, POP, IMAP, XMPP) – This is the detail most likely to trip up an administrator: the dialog only exposes toggles for these four protocols, because they're the ones enforced directly by SmarterMail's own protocol servers. There are no toggles here for Webmail, EAS, MAPI/EWS, or WebDAV, since those run through the web/API layer rather than a dedicated protocol listener. The toggles default differently depending on which tab was active when Blacklist was clicked:
  • From the All Connections, SMTP, POP, or IMAP tabs, the SMTP, POP, and IMAP toggles are pre-checked (XMPP is not).
  • From the XMPP tab, only the XMPP toggle is pre-checked.
  • From the Webmail, EAS, MAPI & EWS, or WebDAV tabs, none of the toggles are pre-checked. At least one must be manually selected before the dialog can be saved.
  In other words, if the abuse being addressed is a flood of brute-force webmail login attempts, blacklisting the IP from the Webmail tab still requires manually enabling SMTP, POP, IMAP, and/or XMPP to actually block anything – the entry alone does not, by itself, block further HTTP-based webmail attempts. Confirm the resulting entry on the Blacklist/Whitelist page afterward if there's any doubt about which protocols it covers.

Drop Connections

Drop Connections is a lighter-weight, non-punitive alternative to blacklisting: it ends the currently open connection(s) from the selected IP address without adding any entry to the blacklist. It's the right tool when a connection simply needs to be reset – for example, a client that's stuck retrying with bad credentials, or a legitimate connection that's hung and holding a license/session slot open – rather than a tool for permanently blocking an address.

What actually happens when Drop Connections is used differs by protocol, since SmarterMail can only forcibly close a connection that involves a persistent, trackable session:

• SMTP, IMAP, and POP – The underlying TCP socket for every session from that IP is closed outright at the server level. This works identically whether the session is in the middle of an active transaction or sitting idle in an IMAP IDLE state waiting for new mail notifications – either way, the socket is torn down immediately.
• XMPP – Active XMPP connections from the IP are likewise closed directly.
• EAS (ActiveSync) – Rather than closing a socket, SmarterMail signals an interrupt to any active ActiveSync "ping" (the long-held HTTP request mobile devices use to wait for new mail) so the device's current wait is broken and it must reconnect.
• MAPI & EWS – Any pending notification subscriptions (the mechanism Outlook uses to be alerted of new items without polling) are cleared for that connection, ending the current wait.
• Webmail and WebDAV – These run over stateless HTTP requests rather than a single long-lived socket, so there typically isn't one persistent connection to "drop" the way there is with SMTP or IMAP. Dropping a webmail or WebDAV connection ends whatever request is in flight at that moment; if the count for that IP doesn't immediately go to zero, give the page a moment and click Refresh, since a new request may already be in progress.

Why Some Counts Fluctuate or Show 0

Two behaviors surprise administrators most often when reviewing this page, and both are expected:

• Connections that appear to last far longer than they should. This is usually a sign of multiple users sharing a single public-facing IP address, not a stuck session. For example, an SMTP connection that stays active for hours is often really several employees behind the same corporate firewall or NAT gateway, each making their own connection, but all appearing to originate from one IP because the firewall masks their individual source addresses. Check the connection count for that IP alongside the Country column before assuming it's a single bad actor.
• MAPI & EWS numbers that fluctuate or sit at 0. Unlike IMAP and EAS, which hold a connection open and wait ("IDLE" for IMAP, a long-poll "ping" for EAS) so new mail can be pushed to the client instantly, MAPI and EWS clients (typically Outlook) generally only open a connection when they're actively syncing or checking for updates. Between those syncs, there may be no connection open at all, so it's completely normal for the MAPI & EWS tab to read 0 most of the time and briefly spike whenever a client checks in.

Related: Server-Wide Connection Limits

This page shows what's connected right now, but it doesn't control how many connections are allowed in total. If connections are being unexpectedly rejected during a legitimate traffic spike, or an administrator wants to cap exposure to a connection-flood attack before it can overwhelm the server, check the per-protocol Max Connections (0 = Unlimited) setting available for SMTP (under Settings > Protocols > SMTP In), and for POP, IMAP, and XMPP (under Settings > Protocols > Other Protocols). These settings cap the total number of simultaneous connections the server will accept for that protocol across all IP addresses combined – they are not a per-IP limit, so they won't stop one address from opening many connections, but they do provide a hard ceiling that protects the server as a whole once combined connection volume from all sources reaches the configured maximum.

Worked Example: Investigating an Abnormally High Count

Suppose the navigation menu badge for Connections jumps from its usual baseline of around 40 up to 300 and stays there. A reasonable investigation using this page looks like:

1. Open IP Connections and click Refresh on the All Connections tab to get a current snapshot, then sort the grid by the IP Connections column (descending) to surface the busiest addresses first.
2. Check the Country column for the top entries. A handful of addresses from an expected country, each with a modest connection count, is far less concerning than a single unfamiliar country suddenly appearing with a very high count.
3. Click through to the individual protocol tabs (SMTP, IMAP, POP, etc.) for that IP to determine which service is being hit. A high SMTP count alongside repeated authentication attempts in the logs suggests a brute-force or spam-relay attempt; a high count that's spread evenly across Webmail, IMAP, and EAS for one address more often points to a single legitimate user behind a NAT gateway with several devices.
4. If it looks like one heavy-but-legitimate user (e.g., a large office behind one public IP), no action may be needed beyond documenting the finding, or perhaps adjusting a Max Connections setting if it's tripping a limit elsewhere.
5. If it looks like a genuine attack or abuse, use Drop Connections first to immediately clear the load, then use Blacklist to prevent the IP (or its netblock, using a range) from reconnecting, making sure to enable the protocol toggle(s) that actually apply and to fill in the Description field for future reference.