Security is of prime concern for Merce Broadside installations, for various reasons. Corrupted or malware-infected emails can seriously damage the reputation of the transmitting organisation and trigger blocking actions at recipient mail servers. Intruders can attempt to connect to and corrupt the Merce Broadside installation itself.
Hardened platform. Merce Broadside is built on the Linux OS kernel and layered components, all of which are suitably hardened for high security. All configurations of all software components are audited to close known vulnerabilities, and access mechanisms into the underlying server are configured for tight security. This is necessary for any mission-critical system continuously connected to the Internet.
Archived configuration history. All changes to the system configuration, access rights, etc., are archived, and before-images are retained in the database, to allow complete change audit. These records are stored in the database and are updated through the administration console. Whenever any record needs to be updated, a copy of the old record is inserted into an archive table. These archive records are purged periodically by a background process. Thus, a forensic audit will always be able to tell which user changed the configuration of a specific parameter, and when.
Source control for message origination. Messages submitted to Merce Broadside for onward transmission are only accepted if their originating IP address and sender email address match pre-defined ACL entries. These ACL entries can be edited by authorised users. Each bulk mail and mailing list application can have a set of sender addresses and a set of source IP addresses defined against it. Only email messages originating from these sources will be accepted by the dispatcher of Merce Broadside. This prevents an infected PC from sending out malware-loaded messages accidentally through the Merce Broadside system, or any other possible misuse with malicious intent.
Account and password hygiene policies. Merce Broadside supports enforcement of policies for account expiry, temporary accounts and forced password change. This permits the enforcement of some basic levels of account management hygiene. Merce Broadside user management is implemented on the Merce user management foundation, which allows the system to set the number of old passwords which cannot be repeated when a user changes his password. For instance if this is set to 5, then a user cannot re-use one of his last five passwords when changing his password.
SSL v3 Digital Client ID support. Users can be forced to connect to Merce Broadside's administration console only after strict two-way authentication using Digital Client IDs, sharply enhancing the authentication security. This is implemented and supported by the Web server which serves as the front-end for the Broadside administration console. Digital Client IDs require cryptographic keys to be generated and installed on the browsers of all users, and supercedes the simple username-password based authentication which is prone to password sharing, password theft, etc. Any communication using SSL v3 is also encrypted using 128-bit SSL encryption, preventing snooping of text on the wire.
L1 and L2 access privilege separation. In Merce Broadside, L1 users do not automatically and implicitly get access to L2 privileges, thus supporting clear separation of roles. This allows the L1 users to be given system management rights, but they can be denied any visibility into, or edit rights for the application definitions being operated within Merce Broadside. The L1 user can grant himself L2 privileges, but this granting action will then be archived in the historical records for post facto forensic analysis. In addition, not all L1 users can grant themselves any additional rights --- a right-granting privilege is required for this. This allows for high security and clean separation of roles.
Mailing list hold-and-check. Messages meant for broadcast to a mailing list are always put in a message repository for review and manual re-transmission, eliminating the danger of accidental broadcast of incorrect content. This becomes very necessary because of the danger of a miscreant sending out a potentially damaging email message to millions of users through a mailing list, under the full protection and performance assurance of Merce Broadside. To prevent such misuse, all messages submitted for outward transmission are queued and made available for manual verification. A human operator must manually release the message for outward transmission before it can be sent out.
Virus filters for outgoing email. All outgoing emails are scanned for viruses to ensure that no malware-infected email reaches the Internet. This is essential protection for any high-performance mail transmission system like Merce Broadside, because transmission of infected messages can damage the reputation of the Broadside installation's IP addresses and prevent effective legitimate use for a long time thereafter. Recipient servers will black-list the IP addresses and activate blocks for all mails emanating from the Merce Broadside system, if it is used to transmit infected messages even once.
Policy controls on mail content and size. Merce Broadside supports the enforcement of allowing only a permitted list of MIME types for outgoing mail attachments, and imposes size limits. This is a defensive measure to prevent inappropriate messages being sent out accidentally or deliberately through a Merce Broadside system. Most Merce Broadside installations only require to send out a small list of MIME types in their attachments, e.g. PDF files and spreadsheets. Thus, pre-defining this white-list allows the Merce Broadside system to block messages which do not fit the policies. The same benefits accrue from the size limit policy.
Message archiving. All outgoing messages and incoming bounces can optionally be archived for complete post facto audit. This feature is very effective during testing phases and when sending out highly critical emails to small sets of users. The archiving mechanism works for both outgoing messages and bounces which return to the Merce Broadside system. The administrator can choose whether the entire messages will be archived or just the headers, and the retention duration of such archived data.
Message bounce tracking. Each outgoing message from the Merce Broadside system is given a unique address where bounces may return, and the event of a bounce is tracked and logged. This allows Merce Broadside to report exactly which of the millions of outgoing messages have failed to reach their recipients, and in many cases, why. Other incoming messages, e.g. incoming requests into auto-responders, are handled separately from bounces.
