-
Notifications
You must be signed in to change notification settings - Fork 3
Administrator Interface
The Admin home screen, presented upon login or after clicking the MailCleaner logo in the top-left of the interface, provides an overall summary of system health, statistics and news.
The InfoBox loads a list of messages from the MailCleaner servers with important administrator news and alerts. These often include important changelogs, like the availability new packages (normally installed automatically), suggested settings changes (eg. accommodations for changes made by major mail hosts), or other information.
Presents daily high-level statistics for message traffic.
Presents overall system health, registration status, and user counts.
Status warnings are a summary of the same errors presented in the System Status element at the top-right corner of every page. These are, in turn, a summary of concerning metrics from Monitoring->Status.
This box will only appear if there are active watchdog alerts. There can be a variety of warnings from any node in the cluster, each of which is documented here.
These settings apply only to the machine that you are currently connected to. If you need to change any of these values for a specific cluster node, ensure that your navigate directly to that machine's Admin interface.
This section is the only one that applies to only the one node. All other sections are to be applied to the primary node and will be have those settings duplicated to each other cluster node also. If you apply different settings to a secondary node before adding it to the cluster, only the Base System settings will be preserved after it joins.
In the current MailCleaner release, some configuration is done using a web-based wizard, available on port 4242. This configurator can be disabled via the Network Settings after the initial setup is complete, at which time the Wizard item will no longer appear on this page. When it is there, it is simply a link to port 4242 at the same base URL.
For MailCleaner-Next, all of the configuration from this web-based wizard was instead unified into the commandline installation script to streamline the process.
This page allows for basic configuration of any available non-local network interface. The values from this form are read from and written to /etc/network/interfaces.
- Disabled
Disables the interface at the system level. Connections to it will not be possible via IPv4.
- Manually
Allows for manual configuration of the interface settings below.
- Dynamically through DCHP
Each of the next 4 settings will be configured automatically by the DHCP server for that network.
The IPv4 address for that MailCleaner node.
The network mask to define the scope of network addresses which don't need to transit your gateway to be reached. eg. 255.255.255.0 means that anything which shares the first 3 octets are part of the same local network; anything that does not is outside your local network and will need to route via your Gateway.
The IPv4 address of the Gateway device which provides access to the wider internet, usually your firewall.
Extra IPs that this interface can bind to, one per line. Should typically be left blank.
Enables or disables the Wizard menu item, linking to the Configurator that is used for initial setup.
- Disabled
Disables the interface at the system level. Connections to it will not be possible via IPv6.
- Manually
Allows for manual configuration of the interface settings below.
- Dynamically through DCHP
Each of the next 3 settings will be configured automatically by the DHCP server for that network.
The IPv6 address for that MailCleaner node.
Similar to the Netmask, this is a single decimal number suffix (CIDR notation), which indicates how many of the leading bits are shared within your network. eg. If this is set to 64, it means that the first 64 bits (the first 4 blocks) are shared by your network. Any machine sharing those bits will route internally, and anything that does not will route externally via the Gateway.
The IPv6 address of the Gateway device which provides access to the wider internet, usually your firewall.
Nameserver configuration options. These values, except the HELO option, are written and read directly from /etc/resolv.conf.
This defines the default domain name to search if a DNS query has 0 dots. eg. If there is a query for 'example' and your domain search value is 'domain.com', it will automatically append that domain and search for 'example.domain.com'.
The first nameserver to be queried.
It is recommended that you set this to 127.0.0.1 (localhost). This will cause queries to be sent to the bind service running locally on MailClenaer. bind supports DNS caching, so although it will not know the answer the first time that it is asked, it will cache the result that is discovered downstream and reuse that result for as long as it remains in the cache. This will greatly speed up DNS lookups which can potentially cut down significantly on processing times.
If you already have a caching DNS server within your local network, then it would also be acceptable to use this instead of 127.0.0.1.
The first fallback nameserver in case the primary is unavailable or does cannot find a valid result.
It is highly recommended that you have some form of back-up DNS enabled, since resolving hostnames is critically important for filtering and mail routing. In the event that the primary server is not available or not working as expected, it is good to have at least one back-up which can be expected to be very reliable. This can be your ISP's nameservers or public nameservers such as CloudFlare (1.1.1.1 and 1.0.0.1) or Google (8.8.8.8 and 8.8.4.4).
An additional back-up nameserver in the event that the first two fail.
A value which will be used inside the SMTP transaction in place of that machines actual configured hostname.
This can be useful in the event that you have a cluster with a unique hostname for each node (eg. mx1.domain.com and mx2.domain.com), but then you have traffic load balanced with a single MX record (eg. mx.domain.com). The HELO name should always match the public hostname, otherwise some remote machines will disconnect due to a possible man-in-the-middle attack. In this example, you can configure both nodes to force the HELO name mx.domain.com so that this is shown instead of the real hostname of each.
These settings are used to configure the appropriate timezone for that node.
Narrow the selection of cities down by which continent your machine is located on.
The nearest city which shares your timezone.
System time configuration via NTP or manual configuration.
When enabled, the time of your machine will be automatically synced with the NTP server defined in the next box. The manual settings below are still shown since they allow you to see the values fetched from that server, but if changed they will be overwritten the next time the NTP daemon runs a sync operation.
The Network Time Protocol server which you would like to use to fetch the current date and time. This is a comma-separated list of server hostnames or IPs. Default: 0.debian.pool.ntp.org, 1.debian.pool.ntp.org, 2.debian.pool.ntp.org, 3.debian.pool.ntp.org
If 'Use time server' is disabled, you can manually set the Date for the machine. If it is enabled, this value will be overwritten by the NTP daemon.
If 'Use time server' is disabled, you can manually set the Time for the machine. If it is enabled, these values will be overwritten by the NTP daemon.
These settings provide the option to to proxy any outgoing traffic via HTTP(S) and/or SMTP through a proxying host in the event that your MailCleaner machine does not have a direct path to the internet, or if you would like to obscure the IP of your machine without using NAT.
Defines the server to use to proxy port 80 and port 443 traffic.
Defines the server to use to proxy port 25 traffic.
The unique ID of the appliance within your cluster. It is strongly discouraged to change this ID after the machine has already been in production, since the ID is save along with quarantined items and you will no longer be able to release items stored by that node prior to the ID change.
Links to a request form for a Enterprise Edition Trial if you are not already signed up for Enterprise Edition.
Free trial for MailCleaner options (Enterprise Edition) / Get commercial Add-ons (Community Edition)
Links to the relevant contact form to try one or more of our commercial options.
Form to submit registration details for Enterprise Edition. This form executes /usr/mailcleaner/bin/register_mailcleaner.sh which will use the authentication details to download some features and theming changes immediately, enable premium support SSH keys and
Form to register your machine for Community Edition. This form executes /usr/mailcleaner/bin/register_ce.sh which, once enabled, will allow for downloading of bayes data and uploading of anonymous statistics.
This will unregister from either Enterprise Edition or Community Edition. This form will execute /usr/mailcleaner/bin/unregister_mailcleaner.sh. In either case, it will send a request to the MailCleaner registration servers. For Enterprise Edition it will also remove the premium support SSH keys, revert theming to Community Edition and remove proprietary RBLs and data sources.
Global settings for the installation.
This is the default language for the User Interface prior to selecting a language at login. Note that the Admin interface is only available in English.
Note: MailCleaner accepts community translations via Weblate
This is the domain that will be assumed if a user tries to login without providing a domain. eg. If this is set to 'domain.com' and the user just enters the username 'alice', it will attempt to authenticate as '[email protected]'.
It will also be the domain that is pre-selected if the next setting is enabled.
This option enables a drop-down box of all active domains hosted by the MailCleaner machine. For ease of use, you may wish to enable this for your users. However, you may also wish to disable it if you wish to keep the list of other domains hosted by MailCleaner a secret from other domains' users. Note that MX records are public information, so the domains in this list is not a secret for knowledgeable enough spammers or malicious senders.
This is the email address that will receive administrator alerts (such as watchdog alerts) and also the address that will be included in email headers and other support notices. It should be a valid address which is periodically checked by an administrator.
This will be the sender address which is used by the postmaster (ie. by the Exim daemon and for MailCleaner summary reports and other emails). It should be an email address at a domain hosted by your MailCleaner in order to ensure deliverability, however it can be a 'noreply' address and does not need to be monitored.
This is an address which should receive reports of mail that the users thinks should have been caught as spam, but which were not. Historically, this was used with the Outlook plugin which is now no longer supported.
You can send emails as an attachment spam AT mailcleaner.net. They must contain valid MailCleaner headers, otherwise they will be discarded. These reports may be used to flag IPs or domains to be added to our RBLs, to train the bayesian analysis database, or to go under manual review for new SpamC rules or other changes.
This is an address which should receive reports of mail that was caught as spam but which the users thinks should not have been. In practice, this address is used when the user clicks to 'request filter adjustment' for an item in their quarantine.
You can send emails as an attachment spam AT mailcleaner.net. They must contain valid MailCleaner headers, otherwise they will be discarded. These reports may be used to flag IPs or domains to be added to our RBLs, to train the bayesian analysis database, or to go under manual review for new SpamC rules or other changes. We do not guarantee that any report will result directly in any changes to filtering behaviour.
These contact details are set up when the appliance is initially configured. They are actually not currently used for anything.
The auto-configuration is used to download the settings from our reference implementation which represent the current recommendations for a generic use-case. These settings try to find a balanced strictness level which should be appropriate for most domains and are changed very infrequently.
It applies to most settings in Configuration->SMTP/Anti-Spam/Content protection. It does not apply to list items like Blacklists and Whitelists.
This button will download the recommended settings once and apply them.
This will subscribe your machines to the reference configuration and will periodically download and apply them. Since most settings don't apply until the relevant service restarts, so if you make a change, it will typically get reverted at midnight. If you wish to make changes which persist, you can just download the reference implementation once and not enable this.
If there are important recommended changes in the future, they will generally either be forced by an update (eg. disabling an RBL which is no longer functional), or we will post about it in the InfoBox.
Parameters for the global quarantine settings.
The number of days to keep quarantined spam/newsletter messages. After this expiry time, these messages will get deleted and can no longer be recovered.
The number of days to keep attachments in the Content Quarantine. After this expiry time, these attachments will get deleted and can no longer be recovered.
The time or days at which certain tasks should be run.
The time to run daily tasks. Most significantly, this includes the daily quarantine reports for users. This is also when watchdog alert emails are sent, if there are any.
The day of the week to run weekly tasks. Currently this only applies to quarantine reports for users who are configured to receive them weekly.
The date in the month to run monthly tasks. Currently this only applies to quarantine reports for users who are configured to receive them monthly.
Alternative logging options.
This enables duplication of syslog messages with rsyslog.
This is the destination hostname/IP and port where the rsyslog server is running.
This form is for enabling the backing up of all delivered messages via the email archiving protocol (eg. MailArchiva).
Note that messages are archived as they leave MailCleaner. This means that outbound relayed messages get archived by Exim Stage 1 as the deliver is attempted to the remote recipient. Inbound messages are archived only upon delivery to the destination server by Exim Stage 4. ie. Messages that are quarantined but never released will not be sent to the archiver. This will prevent you from archiving spam, but also means that you could fail to archive false-positives if they are not released.
There is currently no support for archiving the messages internally.
- none
Simply disables the feature
- external
Allows for defining a archiver server with the next field.
This tab provides access to the configuration wizard for domains. Initially, there will be no domains in the search list, until you create one with the 'New domain' form.
Before you do this, you may wish to review the 'Domain default settings'. These are the settings that a newly created domain will be pre-configured with when it is created. They will take a snapshot of those settings and will not be updated when the defaults are updated. Alternatively, when you create a new domain, you can select to have it take it's snapshot from any other already existing domain.
New domains can only be added by the top-level administrators, this is to prevent client administrators in a multi-tenant environment from being able to add a domain which could hijack outgoing email (intentionally, or not) since MailCleaner uses the delivery information for locally configured domains over public MX records.
The following is a description of the available settings within the domain configuration wizard after the domain has been added (as well as the list of domain default settings), as organized by the drop-down menu for that domain.
By default, domains don't have dedicated administrators. This means that the domain can only be administered by the top-level admin account(s). To provide administrative access to a less privileged account, you need to create a new 'manager' or 'hotline' admin in Configuration->Accesses, or assign that domain to an existing account from there. See that section of the wiki for more info.
Similar to the creation of domains, only top-level admins can add aliases for an existing domain. By adding a domain as an alias, it will use identical settings to the domain that you are currently viewing. So, this provides a convenient way to duplicate settings if you have two domains with the exact same set of users and the exact same delivery settings. If there is any difference between the two domains, for example a different destination server, do not treat them as aliases; create a new domain for each (if they share most settings, you can select to 'Use default values from' the first domain that was created for all of the others).
See the Management->Users section for information on User aliases.
This is the email address that will be used as the 'From' for summary reports. These will override the address set in Configuration->General Settings->Defaults unless it is left blank. This allows you to customize the address so that concerns can be addressed to a support address within that domain. This should generally only be set if the domain has it's own administrator(s), or if you give it a unique address for your top-level support staff to be able to triage replies for specific domains.
Similar to the System mail sender address, this overrides the global default value. See the Configuration->General Settings->Defaults section for more.
Similar to the System mail sender address, this overrides the global default value. See the Configuration->General Settings->Defaults section for more.
This is simply a human friendly name for the contact who should be reached if the top-level admins have concerns with the domain. It does not get used for any system emails, but may be used by the top-level admin if they need to send out alerts to all domain owners by dumping the list of names from the database.
This is simply an email address for the contact who should be reached if the top-level admins have concerns with the domain. It does not get used for any system emails, but may be used by the top-level admin if they need to send out alerts to all domain owners by dumping the list of names from the database.
Settings for how non-spam email should be routed after filtering.
This is the list of hostnames or IPs that mail should be sent to after they have been found not to be spam. One or more can be provided and the behavior for multiple is defined below.
This is the port which should be used to attempt delivery for the servers in the previous setting. This should default to 25 and it is unlikely to be anything else unless you happen to use an alternate port to get around port limitations by an ISP or if you have multiple MTAs behind the same IP.
This is the behavior which should be used if there are multiple servers listed in the first box on this page of the wizard. The options are:
- loadbalancing
This will send an approximately equal amount of traffic to each host by randomly selecting one each time.
- failover
This will always attempt to send the message to the servers in order. ie. mail will only be delivered to the second if the first is not available, and to the third if both the first and second are not available, etc.
If this box is selected, hostnames in the first box will be treated as MX records instead of A records. In other words, the Outgoing MTA will do a DNS query for the provided hostname before attempting delivery to find the value of the MX entry and deliver to that destination instead. This is useful if you use a service which regularly changes the hostname of the destination server but keeps the MX hostname static. This is an uncommon configuration.
IMPORTANT: In a typical configuration you DO NOT need to configure users in MailCleaner. This is because MailCleaner is capable of using an external source for verifying that an email address exists (and with LDAP, it can also configure whether the email address is an alias). By configuring a valid verification method at this step, MailCleaner will automatically know when a new address is created or when an old address is deleted and will reject invalid addresses automatically.
For Enterprise Edition users, billing is done on a per-user basis, so it is essential that an accurate list of users is maintained. Without a valid verification method (or locally defined email address list; see Management->Users), all recipient addresses will assumed to be valid. Mail for all addresses will be scanned, quarantined and will only be rejected upon final delivery if your delivery server is configured to do so. Even if those message go on to be rejected by the delivery server, they will be seen as billable users, since they were scanned.
Regardless of whether you are using Enterprise Edition, rejecting invalid addresses will save significantly on system load and will prevent your machine from quarantining mail for (and generating summary email to) addresses that don't exist.
This is the method that should be used for Address Verification. The options are:
- smtp
This option just uses an initial SMTP connection to the delivery server where it is expected that this server will provide a rejection code after the RCPT TO command. Note that some servers, especially Microsoft's Exchange or Office 365 platforms, will not rejected invalid recipients after this command is given. See our Microsoft Exchange or Office 365 wikis for more information.
With this option selected, there will be an additional 'Use alternate server' option. If you define an IP or hostname here, the behavior described above will be the same, but this server will be used instead of the one defined in the Delivery settings.
- ldap
This option will query an LDAP server to check that the recipient exists within the configured domain according to the specified settings. With this connector, addresses that belong to the same user account will automatically associate all addresses to that primary user (as long as "Group user's quarantines" is selected in the Preferences section). This will result in just one quarantine summary email for all of the user's addresses, and will result in just one billable user for Enterprise Edition. The emails will still be delivered to the original recipient address.
With this connector selected, the following additional settings will be available:
LDAP server - The IP or hostname of the LDAP server to be queried. If the server does not use port 363, you must add a suffix with the port number like myserver.com:123. This includes if you want to use the LDAPS port (typically 636), even if the Use SSL option is selected.
Base DN - This is the 'Distinguised Name' for the domain within the LDAP directory. Usually this is something like: DC=MyDomain,DC=COM or DC=MyDomain,DC=local if your domain were mydomain.com, but it can be more complicated.
Bind User - This is the LDAP username that MailCleaner will authenticate with. It needs to be a user that can read that domain's directory, but it does not require write permissions or any other special permissions. It is recommended that you create a dedicated user account so that you can limit the level of access. This username may be required to be prefixed according to the structure of your directory, eg. mydomain\mailcleaner if the username is mailcleaner within the mydomain unit.
Bind password - This is the password for the above bind user. Note that this password is not hashed in the database because it is needed to be in plain-text for Exim to be able to authenticate with it. Any admin with access to this domain in the WebUI or access to the SQL database directly will be able to see it. This is another reason why it is best use a dedicated user account.
Use SSL - This defines whether to attempt to connect via a SSL/TLS encrypted session. If it is disabled, a classic plain-text LDAP connection will be made and the connection will fail if the server requires encryption. If it enabled, an encrypted LDAPS connection will be made and will fail if the server does not support encryption. As mentioned in the LDAP server section above, you must add a port suffix to that field even if you are using the standard LDAPS port (ie. :636). Some servers will just just enable SSL on port 386 instead of using the standard port, so the port number cannot be assumed.
Only addresses in group - This setting will allow you to restrict the lookups to a subset of the Base DN's directory, eg. by OU=SomeGroup. With this, only addresses within that group will be reported as valid.
- local
With this option set, all email addresses must be manually added via Management->Users. You will manually need to keep the addresses in sync with the back-end server by adding or deleting them from MailCleaner any time that they are added or deleted there. This is strongly discouraged.
- none
With this option, no verification will be done. All addresses will be assumed to be valid. All messages will be accepted by the Incoming MTA, the message will be filtered and if the message is not seen as spam then delivery will be attempted. For addresses that do not exist, this means that your MailCleaner will end up generating bounce messages, since it has taken custody of the message and assumes responsibility for informing the recipient. This is opposed to the other methods where the recipient is rejected during the connection from the remote sender, where that machine is responsible for the bounce. Sending bounce messages in response to invalid recipients can result in your MailCleaner machine getting blacklisted due to "Backscatter", so it is strongly recommended that you have some form of recipient verification. Also note that mail quarantined for invalid addresses will result in undeliverable quarantine summaries being queued and extra billable users for Enterprise Edition.
These preferences define the default settings for users of the domain. Most can be overridden by the user in the User Interface or by the admin in Management Users. See the latter section below for more details on how user settings are managed.
This is the default user interface and quarantine summary language for the domain. This does not override the default language of the user interface landing page (as defined in Configuration->General settings->Defaults) since the domain is not known by the time that page is loaded, but it will apply after the user logs in.
Note: MailCleaner accepts community translations via Weblate.
This setting allows for multiple email addresses to be mapped to a single user account. When this is enabled, you can manually map 'Address Groups' via Management->Users', or have them automatically mapped by LDAP by selecting it as the Address Verification method, above. See the Management->Users section below for details on this behavior.
This option allows you to define how often summary reports are sent to users of this domain. The timing of each is indicated by Configuration->General settings->Periodic tasks. Note that if you choose to 'tag' or 'drop' spam messages in the 'Action on spams' section below, these reports will never be sent, so this setting will do nothing.
This option allows you to decide the formatting of the summary emails. Note that you can create a custom set of templates for each type as described in the Templating Guide, and as enabled in the Templates section of the Domains wizard.
- html
This provides an HTML formatted email, including all quarantined emails during the summary period with links to review and release them.
- plain text
This provides all of the same emails and links provide in the html version in a format that is friendlier for mail readers that don't support html. If html support is available, then that version is more condensed and attractive.
- digest
This provides a simple count of the number of items which would have been included in the other two reports and requires the user to log in to the user interface to view and manage them.
This option will override the recipient address for all quarantine summaries. If this is left blank, the original recipient (or the primary mailbox of their address group) will receive the summary report. It is typically only useful to put an address in this field if you want a member of the security team to review all spam messages on user's behalves. If you would like that to be the default behavior, but also want to allow specific users to manage their own summaries, or send a subset of summaries to a different address, you can override this value for each user in the Management->Users section.
- tag
This option will result in all messages flagged as spam having a tag prefixed to the message subject. The tag can be customized, see below. Since no messages will be held in the quarantine, users with this setting enabled will not get a summary report.
This option is useful if your mail server has the ability to create local filtering rules which can detect the tag and place the emails directly into a Junk folder. This way, the user will receive the items in real time and no have to wait for the summary, or to know that they should log in to the user interface to find newly quarantined messages.
Some users may not treat messages in the Junk folder as seriously as messages held in an external quarantine, so there is potentially a little bit more risk with this option as a trade-off for the convenience it provides.
- quarantine
This is the default, and most commonly used option. With this, spam messages are held in MailCleaner's Spam Quarantine. Summary emails listing the trapped messages will be sent according to the 'Summary frequency' above and users can use these emails to be aware of and optionally release false-positives via the user interface or a pop-up window link.
- drop
With this option, messages identified as spam will be discarded. The original sender will not be informed with a bounce message and there will be no option to recover the message.
This is the tag that will be prefixed to the subject of any spam message in 'tag' mode.
Any message which is determined to have dangerous content (according to settings in Configuration->Content protection) will have that dangerous content stripped and placed in the Content Quarantine. This behavior is not configurable, except to restrict which content is seen as dangerous at a global level. When this happens, the remainder of the message will still be delivered, but the attachment will be substituted for a text file which informs the user that they must request administrator assistance to recover the dangerous attachment. When this happens, the subject of the email will be prefixed with the contents of this setting.
Similar to previous and next, however this string is deprecated. It will be removed in later versions.
Similar to previous, this string will be added if one of the configured virus scanners flags an attachment as a virus (vs. the content being flagged for a more general content protection policy).
These settings will allow for users to get authenticated access to the user interface and optionally allow them to relay outgoing messages (as configured in the Outgoing relay section).
Note that if you do not enable an authentication method, users who receive quarantine reports will still be able to access the interface, without authenticating, using a temporary link with a unique session ID at the top of the summary report. These settings will allow the user to log in at any time by navigating to the URL of the master node.
- none
Disables authenticated access.
- imap
Authenticates using the IMAP protocol. With this option enabled, the following settings will be available:
Authentication server - The hostname/IP and optional port suffix used to connect to the IMAP server. Without a port suffix, port 143 is used, regardless of the SSL setting below.
Use SSL - When enabled an encrypted IMAPS connection will be made, otherwise a plain-text IMAP connection is made. If enabled, you may need to add the ':993' suffix or another non-standard port to the previous field since SSL traffic on port 143 is likely to be rejected.
Username modifier - This defines how the input from the username field should be modified before attempting to log in to the IMAP server. This supports: 'only use entered username' which will strip off the domain name, only using it to find these domain settings, then authenticate with just the user portion (eg. '[email protected]' would just authenticate as 'user'). 'add the domain using @ character' which will keep or add the domain name with the '@' symbol when authenticating. 'add the domain using % character' which will add or replace the domain suffix using a '%' in place of the '@'. The proper selection will be determined by how the IMAP server is configured.
Address lookup - This defines how the authenticated username should be mapped to a MailCleaner user account. The first option is typically the only one used in practice.
- pop3
Authenticates using the POP3 protocol. This option uses the exact same settings as IMAP, see above, except that POP3 uses port 110 for plain text and 995 for SSL.
- ldap/Active Directory
Authenticates using the LDAP protocol, including to Active Directory. Note that this does not support Active Directory connections via the API, such as with Azure Active Directory (this feature is on the roadmap but is not supported currently).
This option will query the LDAP server with a defined user to verify that the specified username actually exists, as well as to get information about that users email aliases and proper account mapping. The username and password provided by the user are then tested before allowing the login.
This option requires most of the same settings defined in the Address Verification section, or in the IMAP section above, except:
User attribute - This is the attribute which should be used to search for the content of the username which was submitted. For Active Directory this is usually 'sAMAccountName' and for generic LDAP this is usually 'user'. Whichever directory entry contains this attribute matching the user input will be used to correlate to all 'proxyAddresses' to establish aliases.
This section allows for the overriding of some default preferences defined in Configuration->Anti-spam, as well as to define some more granular filtering behavior for the individual domain.
Enables the antispam filtering for the domain. That is spam quarantining based primarily on the settings in Configuration->Anti-spam.
Enables the dangerous content filtering for the domain. That is, content quarantining based primarily on the settings in Configuration->Content protection.
Enables the temporary rejection of newly seen domain as configured in Configuration->SMTP->Greylisting. More details on greylisting.
Forces strict rejections of messages which claim to be sending from the same domain as the recipient, but which don't pass SPF or DMARC. This will return a rejection at the Incoming MTA rather than directing the message to the spam quarantine to avoid the user being tricked into releasing a message that is likely to be phishing. Be sure that your domain has up-to-date SPF, DKIM and DMARC before enabling this setting.
If your back-end mail server is case-sensitive, you may wish to restrict incoming email to only use lower-case letters. This is a niche setting that is typically no longer relevant for modern MTAs.
This setting will require that all incoming SMTP connections be encrypted using STARTTLS. Be sure that you have properly set up Configuration->SMTP->TLS/SSL before enabling this setting, otherwise all messages will be rejected.
This setting will treat messages that are detected to be a newsletter, but not detect to be spam as non-spam messages, resulting in them being deliver without quarantining or tagging. If this is disabled, newsletters will be quarantined. Individual users can override this preference.
This setting is required to be enabled in order for any whitelist at any level to be enforced for this domain. When enabled, it will open a new section on this page where whitelists can be set up domain-wide. See our Sender Rules document for more information on whitelists.
This setting is required to be enabled in order for any blacklist at any level to be enforced for this domain. When enabled, it will open a new section on this page where warnlists can be set up domain-wide. See our Sender Rules document for more information on warnlists.
This setting is required to be enabled in order for any blacklist at any level to be enforced for this domain. When enabled, it will open a new section on this page where blacklists can be set up domain-wide. See our Sender Rules document for more information on blacklists.
When this setting is enabled, the address used for the Configuration->General settings->Defaults->Support address will receive an email any time that a message was detected as spam but then a whitelist or warnlist is triggered. This email will contain the rule type, the sender and recipient and a copy of the email. This option is available for administrators who would like to be extra diligent about either addressing false-positives so that whitelists are hopefully no longer necessary, or to monitor in case a user is being reckless with whitelists.
Newslists are always enabled and so there is always a section on this page where newslists can be set up domain-wide. See our Sender Rules document for more information on newslists.
These options are only available to the top-level administrators since they result in direct modifications to the Exim configuration files.
This allows for the creation of IP blacklists which will apply during the Incoming MTA stage and will result in messages from the listed IPs to this domain being dropped without quarantining.
This allows for the creation of IP whitelists which will apply during the Incoming MTA stage and will result in messages from the listed IPs to this domain no being checked for SMTP filtering features including: RBL checks, host blacklists, blocked HELO names, spoofing prevention, invalid reverse DNS, SPF validation and DMARC validation
This will result in a score of 500 being applied for messages coming from the specified IPs and going to this domain effectively guaranteeing that these messages are quarantined.
This will result in a score of -500 being applied for messages coming from the specified IPs and going to this domain effectively guaranteeing that these messages will not be quarantined due to a high SpamC score. It may be quarantined by other modules.
These rules are reloaded when the Incoming MTA (exim_stage1) restarts.
The field on this page accepts a list of SpamC rule names followed by a score offset. These will be applied when the named rule hits and the recipient was from this domain. The result is that the offset score will also be applied. This does not directly override the default score, it accompanies it. So if rule MY_RULE has an existing score of 1 and you enter MY_RULE 2, then a new meta rule will be generate which will add another 2 points, resulting in 3 points total between the two rules. If you wanted to nullify a rule, you have to have it score the negative of the existing score, not 0.
These rules are reloaded when the SpamAssassin daemon (spamd) restarts.
These settings are provide one of the two ways of enabling outbound relaying (the other being Configuration->SMTP->Connection control->Allow external relaying from these hosts). See more about this is our the Outgoing Mail article.
These settings will also let you set up other validation measures and enable further relaying.
Enabling this will all users within the domain to send outgoing mail via MailCleaner by connecting on port 25 or 587 and using the AUTH mechanism send outgoing mail (to domains not hosted by that MailCleaner installation). Using port 587 is strongly recommended so that you can disable AUTH on port 25 (see Configuration->SMTP->SMTP Checks->Block authenticated relaying on port 25) and prevent public brute force login attempts.
Enabling this requires that connection to MailCleaner attempting to send outgoing mail use TLS/SSL encryption.
Enables BATV, which is a mechanism for signing bounce email sender addresses to verify that it is not using a forged return address. This helps others to reject Backscatter which should help maintain your domains reputation. Learn more here.
This is the private key used to sign the return address when BATV is enabled.
This defines whether to do DKIM siging for outgoing messages and if so, which signing keys to use.
Note that no signing will be done until the Incoming MTA is able to resolve a TXT record for the domain, so you do not need to worry about enabling signing before there is a valid key published. Upon selecting the signing method, the necessary TXT record will be provided.
- None
Do not DKIM sign outgoing messages
- Default domain
Use the key that was set up for the default domain in Configuration->SMTP->DKIM.
When this option is selected, you just need to ensure that the TXT record which is provided is published in this domain's zone file.
- This domain
This will set up a unique key for the domain you are currently configuring. It will also list the following options:
Selector - This is the further subdomain that will be prefixed to the _domainkey subdomain (eg. selector mailcleaner for domain domain.com would result in a TXT record for mailcleaner._domainkey.domain.com). This allows you to set up unique keys for different sources that also preform DKIM signing for your domain, without needing to share the private key.
Private key - This is the RSA private key that will be used to DKIM sign messages. You can paste one, if you like, or just click Generate new private key....
- Custom
This option will allow you to use a key for a different domain to sign messages. It uses all of the same options as the 'This domain' option above, except that you can also define the base domain name to be used. This will need to be another domain name that you control so that you can publish the necessary TXT record.
Enables additional relaying of outbound messages. When enabled, new settings will appear which match the settings from the Delivery section. See the descriptions above. The server(s) listed must be configured to relay messages from your domain.
This enabled the Configuration->General settings->Archiving configuration for this domain.
This alternative form of archiving simply appends a BCC address to every email. You can configure a dedicated archiving email address at any domain to silently receive a copy of all messages with the original sender and recipient details intact.
This lets you select which template files to use for users of this domain. See our Templating Guide for more information.
This is the name of the templates to use for the User Interface. Note that you cannot apply custom templates to the Admin interface. Also note that this template applies after the user logs in. At the login page, the template that will be used is the one defined here for the Configuration->General settings->Defaults->Default domain.
This is the name of the templates to use for the quarantine summary emails if the address is in quarantine mode. There are separate template files for the HTML, plain-text and digest options.
This is the name of the templates to use for the .txt attachments which are substituted in for potentially dangerous attachments with instructions to request that they be released.
The remainder of the interface will be documented soon.
--
Normally SPF checks only applies to the mail address given in the MAIL FROM: command in the SMTP session. This is more commonly referred to as the "Envelope" sender address throughout our documentation and will appear as the "From" addresses in the "Received" headers of the email.
Quite a lot of spams/phishing email attempt to spoof a trusted sending domain in other, so the BodyFrom setting allows for the SPF to be checked for the domain in the the "From" header (the one seen by the user in the mail reader) also. However, note that this is not required by the SMTP RFCs. It is perfectly compliance for the "From" header to use any arbitrary address and so a lot of legitimate sources choose to "spoof" this intentionally (eg. third-party newsletter companies using the client domain name, or a mailling list which uses the original sender's email domain instead of the mailing list domain). This setting will help catch a lot of spoofing attempts, but will also result in false-positives for these types of "legitimate spoofs".
This will only be enforced if the domain in the From header results in a "hard fail" result, not a "softfail", "pass" or "none" result.
See the "BodyFrom" setting. This is the same but applies to the address in the "Reply-To" field.
- Enable SPF control (BodyFrom)
This is the same setting as Configuration->SMTP->SMTP checks, but it applies at the SpamC level, so it is much safer.
- Enable SPF control (Reply-To)
This is the same setting as Configuration->SMTP->SMTP checks, but it applies at the SpamC level, so it is much safer.
- Installation
- Overview of Admin Interface
- General Administration and Maintenance Issues
- Clustering
- Upgrading
- FAQ
Expand ▶ Pages above to view the Table of Contents for the article you are already reading, or to browse additional topics. You can also search for keywords in the Wiki.