The Gateway That Outlived Its Interface: Faximum and the Cost of Leaving Fax

Summary

• Faximum controlled the document gateway: queues, conversions, user interfaces, application hooks, email integration, line selection and inbound routing. It did not control modem firmware, carrier numbering, telephone-line quality, SMTP trust or the fax and image standards on either side.
• The Canadian company and its ownership of the Faximum software are well supported by public records. Its current legal status is also clear: Corporations Canada records a 2012 dissolution for non-compliance. A live but dated website and a renewed domain do not prove present commercial support.
• The product’s durability came from its position between systems. Standards such as TIFF-F, MIME and SMTP made documents portable, while local scripts, phone numbers, routing tables, print streams, activation keys and operational habits made the installation difficult to replace.
• A dependent organisation should treat any surviving installation as a continuity and migration case: establish who can lawfully support and activate it, inventory every dependency, test security and interoperability under failure, export operational evidence, and prove a parallel exit before changing the live route.

A document can remain in the queue after its interface has gone out of fashion

Imagine an invoice generated by a line-of-business application. It is not yet a fax. It may begin as printer output, ASCII, PCL, PostScript, PDF or a file attached to an email. Someone or something adds a destination number, a cover sheet, an account code and a delivery priority. A server renders the pages into a fax-compatible image, selects a telephone line, asks a modem to place a call, waits through negotiation and retries, records an outcome, and sends a status message back. On the receiving side, another chain reverses enough of that process to put an image into an inbox or a workflow.

The fashionable interface in Faximum’s early years was an X/Motif client on a Unix workstation. It later became a web form, a Windows print driver and, most consequentially, an email address containing a fax number. The less visible machinery—the queue, converters, routing rules, modem control and receipt handling—was the durable part. Faximum’s own Fax Messaging Server monograph described an outbound message addressed to a fax number and inbound faxes delivered as MIME messages with TIFF-F attachments. The proposition was not to make fax modern in itself. It was to let newer office tools hide the boundary with an older network.

That is why the company is more interesting than a nostalgic catalogue entry. The question is not whether fax is an elegant communications medium. It is whether a gateway can become so embedded in the production of invoices, laboratory reports, legal notices, purchase orders, claims or service forms that the apparent obsolescence of its interface says little about the cost of removing it.

Faximum’s public documentation maps that hidden control surface unusually well. The company offered products ranging from an entry-level single-line Unix package to a multi-line server, a cross-platform client/server system, an email gateway, a low-level developer toolkit and TIFF utilities. Its product overview set historical prices from US$495 for a low-level fax engine or ten-user messaging server to US$1,695 for a one-line client/server licence with two concurrent users. Those numbers are obsolete as quotations, but revealing as architecture: the commercial units were the server, line, user and platform because those were the scarce points at which software met organisational capacity.

Faximum therefore sold coordination, not a codec. It coordinated documents, users, applications, mail servers, operating systems, modems, private branch exchanges and public telephone routes. That coordination can survive for years because each adjacent system sees only a narrow, apparently stable interface. An accounts application still prints. An employee still sends email. A partner still answers a number. A compliance team still sees a transmission record.

The old gateway may sit in the middle without appearing in a modern application inventory until a server fails, a carrier retires a circuit, an auditor asks for patch evidence, or a migration breaks a route that nobody knew was a route.

The company is identifiable; its current legal status is not ambiguous

The identity bridge begins with Canadian public records rather than with the surviving website. A 1991 federal directory of Canadian software developers lists Faximum Software Inc. at 1497 Marine Drive in West Vancouver, names George Pajari as president and Carolanne Reynolds as vice-president of marketing, gives 1990 as the founding year, and describes a Unix fax product supporting scanners, printers, multiple telephone lines, least-cost routing and toll restrictions. The Government of Canada directory is strong contemporary evidence that the named Canadian company was not merely a later web label.

Corporations Canada’s record for Faximum Software Inc. supplies the legal sequence. It records the company under the Canada Business Corporations Act from October 30, 1990. It records a dissolution on November 2, 2005, a revival on September 26, 2008, and another dissolution on August 26, 2012 for non-compliance. It also names George Pajari as a director and shows the last listed annual meeting in 2009. A British Columbia Corporate Registry notice separately shows that the company’s extra-provincial registration in British Columbia was cancelled in 2005. The federal revival explains why a website could later be updated without contradicting the earlier cancellation; the second federal dissolution is the decisive current legal-status fact.

The product bridge is similarly direct. Faximum’s 2002 software licence defines the server and client components, states that Faximum Software Inc. retained title to the software, and makes use dependent on an activation key issued by the company. That is not proof that every bundled component was written by Faximum—its stack used external mail software, image tools, operating systems and modem firmware—but it is clear evidence that the company claimed and licensed the named Faximum product family.

Independent evidence connects the same company to the same technology. Telebit’s contemporary modem manual instructs Unix and Xenix owners to use “Faximum by Faximum Software Inc.” with the T3000 and WorldBlazer family; it does not present Faximum as Telebit software. A 1993 report preserved by the Computer History Museum describes Faximum contributing its server technology to a joint Unix fax project with Hewlett-Packard. Linux Journal and LWN’s report of FMS 2 identify the West Vancouver company, its email-to-fax workflow, its Linux server and its historical price. These sources join the legal company, its principals, its address and its products without requiring an inference from a similar brand name.

The relationships with larger vendors need careful boundaries. Faximum’s own partner page describes a technology exchange with Hewlett-Packard and says Sun Microsystems licensed a Faximum-derived product for the Sun Voyager. The underlying HP collaboration is independently reflected in the period press. Those were development, cross-licensing and original-equipment-manufacturer relationships, not evidence that HP or Sun acquired Faximum Software Inc., assumed all customer obligations, or became a general successor for every Faximum licence.

The same restraint applies today. Faximum.com still responds, and its domain registration was updated in 2025. The home page identifies Faximum Software Inc. and was marked “last updated” in 2010. Other key pages are older: the company history and much of the product catalogue say 2003; the support policy says 2005; the contact page says 2006; and the product-status table describes a 2001 snapshot. The site responded over plain HTTP when checked for this article, while an HTTPS connection was unavailable. Its server disclosed an Apache 2.2.22 banner. A banner can be inaccurate and a distributor can backport patches, so it is a warning to investigate, not a remote vulnerability finding. Apache itself says the 2.2 branch has been end-of-life since 2017.

These traces prove continuing custody of a domain and a body of documentation. They do not establish that the dissolved corporation is selling licences, answering support calls, issuing replacement activation keys or shipping security fixes in 2026. No public acquisition, assignment of the full product line, or authorised successor-maintenance statement appears in the evidence. A reseller may know the software; an OEM may hold rights to a particular derivative; a former engineer may understand the code.

None of those facts, alone, proves authority to issue keys, modify the licensed binaries, distribute a patched build or bind the original company.

For a dependent organisation, that distinction is operational. “The website is up” is not a support contract. “The software still runs” is not a security lifecycle. “A consultant can log in” is not proof that the consultant has source rights or can restore a machine-bound licence after a disaster. Faximum is historically well proven and presently dissolved; any claim of current continuity must be demonstrated transaction by transaction.

What Faximum actually controlled

Faximum’s strongest claim was the software layer above the fax modem and below the employee or business application. In the full server products, that layer accepted work, rendered it, scheduled it, assigned a route, submitted it to a device, interpreted status and stored operational records. This is a wider surface than “fax driver,” but a narrower one than an end-to-end communications network.

At the user edge, Faximum controlled several submission paths. Its Unix client/server product exposed an X/Motif graphical client, a command-line interface and a line-printer intercept. The intercept mattered because an existing application did not need a new fax integration: it could print a stream that Faximum separated into documents and destinations. Mail-merge output could become a broadcast. Form overlays could add letterhead, invoices or purchase-order layouts. On Windows, the product offered client support and later an FMS print driver.

The driver rendered what an application could print, collected recipient details and handed an attachment to the user’s email client. Windows was therefore an edge in many deployments, not necessarily the operating system hosting the fax engine.

At the application edge, Faximum offered two different levels of control. The higher-level products owned queueing, delayed transmission, retries, line balancing and notification. The MFax toolkit deliberately did less: its specification says the developer was responsible for scheduling requests and handling retries while the utility attempted the call and returned a result. That distinction is essential when excavating an old installation. A process called “Faximum” may contain critical business logic written by the customer or an integrator, not by Faximum. Replacing the executable without finding that orchestration can remove the very behaviour the organisation believes it is buying.

At the document edge, the suite converted text, printer languages and images into fax-ready pages. Product specifications name ASCII, ISO-8859-1 text, PCL, PostScript, TIFF-F and, in some configurations, PDF or HTML conversion using external tools. The company’s TIFF-F utilities could concatenate and split multipage files, inspect tags, change compression, crop regions, display images and render fax images for PCL or PostScript printers. This was valuable plumbing: a standards-based file might move between systems, but the installed scripts, fonts, form overlays and conversion options determined what the recipient actually saw.

At the email edge, FMS could be installed as a delivery agent on the same host as sendmail, Postfix or qmail; on a separate local server receiving messages from the organisation’s main mail system; or behind a remote provider using a dedicated fax domain and ETRN queue triggering. Faximum’s email compatibility guide explicitly separates those three arrangements. The company controlled the fax delivery agent and its address conventions. It did not control Microsoft Exchange, Netscape Messaging Server, the customer’s DNS, an internet service provider’s queue, or the basic trust properties of SMTP.

At the telephone edge, Faximum controlled commands to supported Class 2 or Class 2.0 modems and boards, plus higher-level policies such as which line to use. PLUS and Client/Server specifications describe delayed sending based on priority and telephone rates, automatic load balancing, restrictions on long-distance or priority calls, PBX account digits, least-cost selection among trunks, and the ability to reserve lines for incoming traffic. For inbound delivery, it could use a sending machine’s identifier, a direct-inward-dialling extension or an ISDN called-number indication to choose a user.

It could also invoke a local shell program when a fax arrived, turning the gateway into an automation trigger.

At the administrative edge, FMS exposed a web interface to manage users, routing and queues. The full server products maintained accounting records by user and project account and sent transmission-status notifications. That is useful evidence for operations and chargeback. It should not be inflated into a modern compliance claim: the public material does not establish immutable logging, cryptographic integrity, retention controls, central security-event export, individual administrator attribution or a complete chain of custody. Those capabilities must be tested in the installed release.

What Faximum did not control is just as important. It did not define Group 3 fax negotiation, own TIFF-FX, make SMTP inherently authentic, assign telephone numbers, guarantee a carrier path, write every attachment converter, or fix a modem manufacturer’s firmware. It could engineer around those systems and test combinations, but the final result was a chain of separately controlled components. That is why an installation can fail even when the Faximum process itself has not changed.

The narrow waist was an image file and a queue

The architectural insight behind FMS was to use existing messaging infrastructure as the user interface while preserving fax at the external edge. An outbound email supplied the sender, destination and attachments. The gateway rendered pages and queued a telephone call. An inbound call became a TIFF attachment in a MIME message. Users could file, forward and view the result with existing tools.

The image format reduced one kind of lock-in. RFC 3949 defines TIFF-FX profiles for fax, including black-and-white and colour representations aligned with ITU recommendations. Faximum’s common TIFF-F use meant a customer was not necessarily trapped in an unreadable proprietary image container. A properly exported, validated TIFF collection can be opened, converted and migrated by other software.

But a portable page is not a portable workflow. The page does not contain the complete retry history, who approved the destination, why a route was chosen, which phone number received the call, whether an application associated the transmission with an invoice, how a DID range mapped to inboxes, or whether the sender received and acted on a failure notification. A migration that preserves TIFF files but loses these associations preserves documents while destroying operational meaning.

The same is true of email. RFC 5321 specifies SMTP’s store-and-forward delivery model and is candid that SMTP transport does not by itself authenticate the author or provide message integrity. RFC 1985 defines ETRN so a transiently connected site can ask a server to start processing a queue. Faximum used those open mechanisms to fit varied mail topologies, including small organisations without a permanently exposed local mail server. Openness improved interoperability, but it inherited the security and configuration responsibilities of the mail system.

Faximum was close enough to the standards conversation to leave another independent trace. RFC 2542, which set terminology and goals for internet fax, acknowledges George Pajari among contributors. IANA’s service registry still lists “faximum” on TCP and UDP port 7437 with Pajari as the contact. Neither entry proves current product support, but both reinforce the historical bridge between the company’s engineering work and its documented protocol surface.

The gateway’s narrow waist was therefore not a single protocol. It was a combination of a queued job, a rendered page, an address or number, and a result. That abstraction let Unix, Linux, Windows, Mac, mail and telephone systems participate without sharing an application. It also let local dependencies accumulate behind each apparently standard interface.

Fax persists because the counterparty sets the last mile

An organisation can replace its own desktop client and still be unable to replace the exchange. The receiving party may accept a fax number because it is printed on forms, embedded in referral procedures, monitored by a staffed queue, recognised by a regulator, or available to a small office that has no shared portal. The sender may have a modern application, but the last mile remains a telephone-addressed document.

This is especially visible in regulated workflows. The US Department of Health and Human Services says the HIPAA Privacy Rule permits providers to send treatment information by fax, provided they use reasonable safeguards; its examples include verifying a number and securing the receiving machine. That HHS guidance does not certify fax as secure or make a specific product compliant. It explains why the channel can remain administratively valid even when better structured exchange exists.

Canadian privacy guidance makes the other half of the case. The Office of the Privacy Commissioner of Canada says organisations sending personal information by fax should confirm both the destination and that only the intended client’s information is delivered. Its safeguards bulletin draws on repeated misdirected-fax cases. In 2023, Ontario’s privacy commissioner called misdirected faxes the leading cause of unauthorised disclosure of personal health information in the province and urged healthcare providers to reduce or eliminate the channel where possible. The point is not that fax is uniquely lawful or uniquely reckless. It is that institutions still use it, and its most damaging failures often occur at the human-number boundary rather than in the compression algorithm.

Even the Canadian Intellectual Property Office illustrates the contradiction. Its current correspondence procedures accept certain black-and-white and colour facsimile filings, specify receiving numbers and treat a transmission report as acknowledgement. The same page warns that confidentiality cannot be guaranteed, discourages computer fax interfaces and internet fax services because of reception issues, and refuses some evidence by fax because of quality, incompleteness and volume. Fax survives not because its weaknesses are unknown, but because a bounded, documented pathway still serves particular interactions.

This is where Faximum’s email gateway could be both helpful and dangerous. It removed paper from the sender’s office, centralised numbers, could restrict costly routes, delivered inbound images to named inboxes and generated status messages. Those controls can reduce people hovering around a shared machine. Yet email delivery also expands the number of systems that copy the document: mail queues, inboxes, backups, mobile clients and archives. A gateway may improve physical confidentiality while creating an electronic retention and access problem.

The correct assessment follows the data through both sides rather than awarding a blanket security label to “fax” or “email.”

The operational persistence is similarly concrete. A pharmacy, clinic, broker, repair network or small supplier may have a number that thousands of counterparties already know. Replacing it requires number porting or forwarding, directory changes, counterparty testing, staff training and a fallback for senders that never read the notice. An outbound application may generate a fixed PCL form that has been accepted for years. Replacing the gateway can subtly change fonts, page breaks, barcodes, signatures or cover sheets even if every call connects. Those are workflow failures, not telecommunications failures.

The modem negotiated the call; Faximum orchestrated around it

Group 3 fax is a conversation. The endpoints identify capabilities, choose speed and resolution, train the channel, transmit pages, acknowledge results and fall back when conditions require it. ITU-T T.30 remains the in-force recommendation for procedures over the general switched telephone network. Faximum’s software could request and react to a session, but a Class 2 or 2.0 modem’s firmware handled much of the low-level negotiation.

Faximum said this directly on its supported-modem page. It warned that firmware defects could create incompatibilities with particular fax machines, that manufacturers sometimes changed chipsets or firmware without changing a model number, and that Class 2 and Class 2.0 were different and incompatible command sets. It recommended particular Multi-Tech devices and listed other brands as operational or mixed. The initial Telebit source is useful precisely because it preserves the division: Telebit supplied a modem with fax capability; the user still needed application software, for which the manual named Faximum on Unix and Xenix.

That division determines today’s tests. A spare modem with the same badge is not necessarily an equivalent spare. Its ROM revision, chipset, USB or serial bridge, flow control, adaptive-answer behaviour and response to marginal lines can differ. A virtual machine may preserve the Unix executable but remove access to the multi-port serial card. A modern PBX may present an analogue adapter whose packetised path changes timing. A carrier may convert an apparently analogue access line to IP in its network. The server can remain byte-for-byte unchanged while the end-to-end fax success rate deteriorates.

ITU-T T.38 addresses real-time Group 3 fax where part of the path is an IP network. It is not simply “fax over any voice codec.” Gateways must preserve the fax protocol’s timing and indicators across a network with different delay and loss characteristics. Faximum’s historical material concentrated on physical modems, analogue or ISDN interfaces and branch routing; its FMS monograph claimed T.37 internet-fax compliance for store-and-forward messaging, which is a different architecture from T.38 real-time relay. A buyer must not assume T.38 support from the presence of email, TCP/IP or the phrase “internet fax.”

Inbound routing adds another dependency. Faximum could map a DID extension or ISDN called-number indication to a user, but the carrier and PBX had to deliver that signal correctly. It could use a calling fax machine’s identifier, but that identifier was supplied by the remote endpoint and could be absent, generic or misleading. Manual web routing showed the first page to an authorised operator, but then privacy depended on the operator, the access controls and the correctness of the directory.

Every routing method has a different failure mode, and a migration must reproduce the intended policy rather than merely deliver all incoming images somewhere.

Least-cost routing also belongs to its era but has a modern analogue. Faximum could choose WATS, tie, foreign-exchange or other trunks, insert account digits and move an urgent job when a preferred route was busy. Cheap long-distance rates have weakened that particular value proposition. The enduring function is policy-based route selection: choose a carrier, branch gateway, local number, priority or fallback based on cost, success probability and urgency. A replacement that offers lower nominal per-page pricing but no equivalent routing, observability or failure recovery may increase the operational cost of undelivered documents.

The security boundary was always larger than the fax line

Faximum’s 2003 Linux FMS README is unusually frank about its main mail-gateway risk. It says FMS performed only a rudimentary sender check using the email From header, acknowledges that the header can be forged, and tells administrators to prevent unauthorised external messages from reaching the internal FMS server. This aligns with SMTP’s own security limitations. It also means the historical product’s safe operation depended on network and mail-server enforcement outside Faximum.

The same FMS README instructs an installer to connect to a web administration service over HTTP on port 7437 and, during initial setup, to log in as admin with any password. Read in its 2003 context, that may have been a bootstrap procedure intended for a protected local network. Read as a 2026 control, it demands proof: when does strong authentication become mandatory, are credentials protected in transit and at rest, can the setup state reappear after a restore, and can the interface be bound to a management network rather than exposed?

The attachment path broadens the attack surface again. The gateway accepts untrusted inbound page data and outbound files from users or applications. It parses TIFF structures, invokes converters, handles fonts, builds cover sheets and may call external components such as Ghostscript for PostScript or PDF. Standards compliance does not make a parser memory-safe, and a clean result on ordinary office documents does not show how the stack behaves with malformed tags, extreme dimensions, decompression expansion, deeply nested input, a huge recipient list or a disk-filling queue.

The installed versions and privileges of every converter matter as much as the Faximum binary.

There is no basis here for claiming a disclosed Faximum breach or a particular unpatched flaw in an installed copy. The absence of a public vulnerability entry would not prove safety, especially for a small proprietary product from an era before systematic software-bill-of-materials publication and coordinated disclosure became procurement expectations. The appropriate conclusion is an evidence gap: obtain the exact binaries, hashes, build and patch history; identify libraries and helper programs; scan them; and test the deployed controls without assuming that the old public version number describes the live system.

Platform age makes that gap material. The public FMS documentation names Red Hat 7, 8 and 9, Caldera OpenLinux, SCO Linux, UnitedLinux, AIX 5 and Windows 95 through XP clients. Microsoft records that Windows XP support ended in 2014, and IBM records that standard support for AIX 5.3 ended in 2012. A customer may have ported, isolated or replaced components; the website does not show a supported modern matrix. Canada’s Cyber Centre advises replacing unsupported components and documenting the justification and approval when a critical business capability makes immediate replacement impossible. Its unsupported-systems guidance is a better policy baseline than “it has worked for years.”

Privacy controls must cover misdirection as well as intrusion. Use verified destination directories rather than repeated manual keying; require additional confirmation for new or changed sensitive numbers; separate test destinations from production; limit what appears on a cover sheet; restrict who can see an inbound first page; and make misdelivery a reportable incident with containment, notification and recurrence analysis. The Office of the Privacy Commissioner’s CIBC case shows why: similar numbers and weak organisational response allowed personal banking information to be misdirected over years. A gateway can enforce an allowlist and preserve evidence, but only if the organisation configures and monitors it.

Finally, availability is a security property here. A stuck queue can delay treatment instructions, orders, claims or legal notices. Controls should distinguish accepted by the gateway, dialled, connected, page-confirmed, delivered to an inbound mailbox and consumed by the downstream workflow. A successful SMTP submission is not a successful fax; a T.30 confirmation is not proof that the right person read the document; a printed transmission report is not a complete incident record. Monitoring must preserve those state changes without turning uncertain delivery into a false assurance.

Pricing and activation reveal where the lock-in accumulated

Faximum’s historical pricing treated the basic server as affordable and expansion as incremental. The price list put FMS at US$495 for ten users and one line on Linux or SCO, with additional 25-user packs and lines at US$350 each. Client/Server began at US$1,695 for one line and two floating users. Premium annual support was listed at US$600; remote installation at US$200. The FMS appliance for a Windows or Mac network was advertised from US$1,490 including hardware, modem and software.

These are not current offers and should not be used in a budget. They show the old pricing logic. Faximum monetised concurrency and capacity while using the customer’s existing server, mail infrastructure and telephone service. It argued that this was cheaper than per-user hosted fax. For a small organisation, the calculation could work: centralise a few lines, avoid a desktop modem and licence for every person, and use email clients already deployed.

The ownership boundary complicates total cost. FMS was a product, not a managed transmission service. The customer owned and operated the server, but the 2002 licence says the customer did not own the software. The server licence was personal, non-transferable and tied to a machine identified by an activation key. Faximum’s price list charged for transfers between CPUs and said transfers were available only for a current release; older releases had to be upgraded. Evaluation and some pre-payment keys could expire.

That design turns a disaster-recovery exercise into a licensing test. Can an organisation restore the server on replacement hardware or a virtual machine without obtaining a new key? Does the existing permanent key bind to a hostname, hardware identifier, network address or another property? Is a second passive instance permitted? Can the software start if the system clock, interface order or storage geometry changes? The public registration page still renders, but that does not prove that a human or service now issues valid keys. These questions must be answered before the original host fails, not during the outage.

Support was also version-sensitive. Faximum’s historical policy offered annual or per-call assistance, stated that obsolete releases were supported on a best-efforts basis, and warned that fixes could require an upgrade. That is normal commercial behaviour when a vendor is active. Once the recorded corporation is dissolved and no current release or successor is documented, the same terms expose a continuity gap. A consultant may keep an instance running, but maintenance without lawful access to source, build tools, signing or activation authority may be confined to configuration and surrounding infrastructure.

The largest switching costs, however, are usually customer-created. They include print queues named in old applications; mail aliases embedded in address books; scripts that parse status messages; PCL overlays aligned to a recipient’s forms; directory entries and DID maps; line-accounting codes; retention jobs; firewall exceptions; serial-port settings; modem ROMs; staff who manually route ambiguous pages; and counterparties that know only a fax number. None appears in a licence count, yet each can break a replacement.

The competitive test is who assumes continuity risk

Faximum’s architecture still has recognisable alternatives, but they distribute responsibility differently. HylaFAX+ remains an open-source fax management system with source available and a current 7.0.11 release. Source availability can reduce dependence on one legal entity, but it does not provide an automatic support service, security response or tested migration. The customer still owns integration and operations unless it contracts them elsewhere.

Current enterprise products offer on-premises or hybrid server designs, virtualisation, high availability and application connectors. FaxBack, for example, advertises enterprise deployments with multiple ports, high availability, application integration and HTTPS transmission options. OpenText’s fax-security paper describes an audit trail and archive copy as part of a modern RightFax security proposition. These are vendor claims to validate, but they establish the questions a procurement team should now ask of any replacement.

Cloud providers move modem, carrier and some availability responsibility out of the customer’s server room. Retarus documents REST job submission, job identifiers, status retrieval, regional high-availability endpoints and IP allowlisting, as well as SMTP and application integration. Its current fax API demonstrates how the interface has moved from email-address conventions and printer drivers toward explicit jobs and machine-readable status. Cloud does not eliminate lock-in: number porting, data location, retention, authentication, outage handling, per-page charges and export rights replace serial cards and activation keys as dependencies.

The correct comparison is therefore not “old fax server versus new fax service.” It is which party will own each failure. An on-premises open-source system gives the customer maximum repair freedom and maximum operational burden. A supported on-premises commercial system may preserve local custody but requires a healthy vendor and entitlement. A cloud service absorbs infrastructure and carrier management but adds contractual, jurisdictional and provider-continuity exposure. A hybrid design can preserve local application interfaces while using a managed telephone edge, at the cost of another boundary to monitor.

Faximum should be tested against those allocation choices, not against a feature checklist frozen in 2003. Its open formats and many interfaces are advantages. Its dissolved corporate status, old public platform matrix, activation model and undocumented present security lifecycle are material disadvantages. A surviving installation may still be the least risky short-term route if it is isolated, understood and paired with a tested replacement. It should not win a new procurement merely because the binary still starts.

A dependent organisation should test the chain, not the demonstration

The first test is authority. Ask any party offering support to identify the contracting legal entity, the scope of its rights, the people available, the response times and the releases it can actually patch. Require evidence of authority to issue or replace activation keys and to distribute modified software. Distinguish an authorised successor from a reseller, an OEM derivative and an independent consultant. If source escrow or a continuity licence exists, exercise it far enough to show that the materials build and that the resulting binary can be lawfully deployed.

The second test is discovery. Record the exact Faximum product, version, release, fix files, binary hashes and activation terms. Inventory the operating system, kernel, C library, mail-transfer agent, web server, converter programs, fonts, printer emulators, scripts, scheduled tasks, user directories, queues, storage paths and backup jobs. Identify serial cards, USB adapters, modem models and ROM revisions, analogue adapters, PBX ports, ISDN or SIP gateways, carrier circuits, inbound numbers and DID ranges. Map TCP port 7437, SMTP routes, DNS records and every firewall rule. Do not infer the production design from the public manual.

The third test is demand. Use at least a representative operating cycle, including seasonal peaks, to measure jobs, pages, recipients, inbound and outbound numbers, document types, retries, busy calls, no answers, transmission duration, failure codes and manual interventions. Find jobs submitted by applications rather than people. A queue with ten visible users may support hundreds of automated destinations. Separate traffic that must remain fax from traffic that can move to a portal, API, secure message or structured exchange.

The fourth test is rendering. Build a golden set of real but appropriately protected documents: single and multipage TIFF-F, text, PCL, PostScript, PDF, forms, barcodes, small fonts, signatures, non-ASCII characters and awkward page sizes. Compare pixel output, page count, orientation, margins and legibility across the current and proposed systems. Fax each result to a range of physical devices and services, then compare the received page rather than the preview. A converter that moves a barcode by two millimetres can fail a downstream workflow despite a successful call.

The fifth test is telephony interoperability. Use controlled endpoints representing old Group 3 machines, modern multifunction devices, another server, a cloud service and paths through analogue, PBX and IP gateways. Exercise busy, no-answer, wrong-number, low-signal and partial-page cases. Verify speed fallback, error-correction behaviour, multi-page confirmation, retries, duplicate prevention and maximum duration. If the future path uses T.38, test it through the actual session border controller and carriers; do not accept a laboratory T.38 label as proof that the production route will preserve timing.

The sixth test is inbound identity and routing. For every number, verify which called-number information arrives and how it maps to a mailbox or application. Test absent, duplicated and malformed identifiers. Confirm what happens when no user matches, an employee leaves, a mailbox is full, email is delayed or the manual router is unavailable. Verify that the operator sees no more content than necessary and that reassignment is logged. Send test traffic after any number port because routing and caller display can change even when the number appears unchanged.

The seventh test is mail security. Attempt an unauthorised external submission in a controlled environment and confirm that the MTA rejects it before FMS. Test forged From headers, relay paths, aliases, distribution lists and a compromised internal account. Require authenticated administration, protected transport, role separation, session expiry and management-network restrictions. Confirm that the bootstrap state cannot be reached after ordinary restart or restore. Inspect both accepted and rejected job logs and export them to monitoring without exposing document content unnecessarily.

The eighth test is hostile and excessive content. In an isolated copy, submit malformed TIFF tags, corrupt multipage files, oversized dimensions, very large attachments, long recipient lists, archive-expanding content and documents that make a converter hang. Confirm resource limits, timeouts, privilege boundaries, quarantine behaviour and queue recovery. This is not a claim that Faximum contains a particular defect; it is a test of an old document-processing boundary whose public security maintenance is unknown.

The ninth test is privacy and auditability. Trace a document from an authenticated origin to the final number and back to its business case. Determine which record proves each state, who can alter it and how long it remains. Test a misdirected number and follow the incident procedure. Verify encryption and access controls for stored TIFF files, mail copies, backups and exports. Reconcile sent jobs with carrier records and downstream acknowledgements. If a regulation requires retention or deletion, show both operations rather than relying on a generic “archive” feature.

The tenth test is recovery. Restore the complete service to clean replacement infrastructure with the production host unavailable. Use documented media, keys, configurations and dependencies—no files copied opportunistically from the running machine. Restore queues without resending completed jobs, reconnect a spare modem or gateway, receive on a test number and send a known document. Time the exercise. A backup is not evidence of continuity until the activation, obsolete packages, device access, mail routes and phone routes all work together.

The final test is exit. Export source documents where available, rendered TIFF files, user and destination directories, DID mappings, routing and restriction rules, form overlays, scripts, account records, queue state and delivery history in documented formats. Port or forward numbers under a reversible plan. Run old and new gateways in parallel with explicitly divided numbers or traffic so that a job cannot be sent twice. Define success by delivery, rendering, routing, status and evidence—not by installation completion.

Exit is a controlled migration, not an uninstall

An organisation should not begin by shutting down Faximum. It should begin by reducing uncertainty. Freeze configuration changes except those needed for safety, copy the authorised installation media and licence records, capture hashes, document the network, and identify owners for every number and application feed. Remove clearly unused routes only after monitoring proves they are unused. Establish a supported destination architecture and a rollback window.

The easiest traffic should leave first: low-volume outbound documents whose counterparties can accept a secure portal or structured message, then fax jobs with simple rendering and well-maintained numbers. Complex application-generated forms, inbound DID routing and regulated records should move after their evidence and exception paths are understood. The goal is not to recreate every historical quirk forever; it is to preserve required outcomes while consciously retiring accidental behaviour.

Number continuity deserves its own plan. Confirm who legally controls each number, whether it can be ported, how long forwarding will remain, what caller or called-number data the new route supplies, and how senders will be notified. Monitor the old route for stragglers. A number printed on a form or stored in a partner’s machine can generate traffic years after an internal directory changes.

Data continuity is broader than page export. Keep a defensible mapping between the old job identifier, business transaction, destination, timestamps, result and migrated document. Preserve only what policy requires, but do not destroy the old evidence before the new system proves completeness. When the parallel period ends, reconcile every open or failed job, revoke credentials, remove mail routes and firewall rules, sanitise storage, release unneeded lines and document the decommissioning decision.

Faximum’s history offers a precise lesson. The company did not own the networks on either side. It owned the translation and orchestration between them, and customers supplied the final layer of scripts, numbers, policies and habit. Open standards made that gateway broadly useful; local integration made it durable. The corporation can be dissolved, the public interfaces can look two decades old, and the business dependency can still be rational until a tested alternative exists.

The correct response is neither complacency nor a ceremonial ban on fax. It is to separate what is verified from what is assumed. Faximum Software Inc. was a real Canadian developer with a well-documented product family and meaningful Unix fax engineering. Its present corporate status is dissolved, its public lifecycle evidence is stale, and its live website does not answer the questions that a current support and security review must answer. Any organisation still relying on the software should preserve service while it proves authority, security, interoperability, recovery and exit. The hard part was never the tone on the line.

It was everything the gateway caused to happen before and after it.