Details of the Custom Configuration Layer
Overview
Currently available checks
Proposed new checks
As shown in the diagram on the home page, at the heart of the Outbound Index query server is a custom configuration layer controlled individually by each email administrator.
The inbound server email administrator thus configures and controls:
- which checks run on his queries
- action to take or score increment/decrement on pass / fail of each check
- query response to send
And, of course, the email administrator has full control over what action is taken in the inbound server based on the query response. Examples: accept and skip further anti-spam processing, accept and insert header flag to trigger scrutiny by additional anti-spam processing, tempfail, reject, et al.
Check: One of many possible tests performed using input data such as the sending server IP address and/or sender domain of an email message.
Action: What result to return, depending if the result of a check was pass or fail. Examples of actions include, but are not limited to: set the query response code to one of [Accept, Reject, Scrutinize, Tempfail], Score or Continue.
Default Action: What result to return, if every check completes with an action of Continue. For example, if the process of running checks has not set the response code, the response code specified in Default Action will be set.
The default action is the query response you want sent back to your inbound email server in the event that none of the checks had a pass or fail result. In other words, the Outbound Index did not contain any facts about either the IP or the sender domain based on the checks you have specified. These messages would be classified as "unknown."
As the email administrator for your domain(s), you control:
- what "checks" will run on the queries you send
- the action taken for pass and fail of each check
- the default query response
You are solely responsible for your configuration choices and their results. We cannot tell you how to configure your Checks & Actions, and we have absolutely no control nor responsibility for how you or your vendors program your inbound email servers to process the query response information.
We provide factual information about IP addresses and domains. That is all we do.
If you need help with your settings/configuration, or confirmation of your settings/configuration, we are working on setting up a page listing third party experts that are available to advise you.
We can tell you what configuration of Checks & Actions some companies have used, configurations which they have stated works well for them:
Some users have reported that they like to subject these "unknown" email sources to further scrutiny, which is why we called this action "scrutinize." Some users scrutinize the "unknown" messages using such techniques as content analysis, challenge response, tar-pitting, rate limiting, flagging or subject / from modification.
| Order | Name of Check | If Pass | If Fail |
| 1 | network_allowed | Continue | Reject |
| 2 | domain_exists | Continue | Reject |
| 3 | domain_allowed | Accept | Reject |
| Default Action: Scrutinize |
Here is a list of presently available checks and a description of each:
network_allowed: The IP address of the sending server is checked against the database of "forbidden" IP addresses (those which cannot be used on an email outbound server). A reverse DNS lookup is done on the IP, and then a forward DNS crosscheck. If the forward DNS and reverse DNS match, the FQDN is compared to a database of "forbidden" FQDN patterns.
For this check, "pass" means the sending server IP address was not on either "forbidden" list, and fail means it was on one of the "forbidden" lists.
The "forbidden to operate an outbound server" list could include IP ranges and FQDN patterns of ISPs that have an AUP (Acceptable Use Policy), TOS (Terms of Service), or other contract forbidding customers from operating any type of email server on that ISP service.
The organization who has control over a block of IP addresses has the authority for the purposes of the Outbound Index, to specify which IP addresses may not be used on an outbound email server. "Control" is defined as: having an ASN or other assignment of IP addresses from ARIN, RIPE, APNIC, or other NICs recognized by ARIN; or demonstrating reverse DNS delegation; or verifying control of the domain name at the end of the FQDN of IP addresses with matching forward and reverse DNS.
domain_exists: A DNS record lookup is performed on the sender domain to verify the existence of the domain.
domain_allowed: A series of test are run by this check, each with the purpose of looking up whether the sender domain owner has authorized the sending server IP address.
If the sender domain is not yet listed, no action is taken. The result of any subsequent checks will determine the query response.
has_syncdns: Perform a reverse DNS lookup on the sending server IP address. Take the result and do a foward DNS lookup. If the resulting forward DNS lookup matches the original IP address, this check result is "pass."
Reverse DNS alone can be faked to show any fully qualified domain name, by anyone with reverse delegation. For example, if I wanted to forge mail from @aol.com from a non-AOL spammer server, I could set the PTR record to imo-r03.mx.aol.com. Anti-spam techniques that rely only on checking the reverse DNS of my outbound IP address might accept the forgery. However, doing a cross-check of the forward DNS for imo-r03.mx.aol.com, would reveal that it did not match my IP, exposing the PTR record forgery.
This check is used by other checks, to qualify data those checks are based on. "Has_syncdns" is useful for indicating a certain type of identifiability - failing this check should never be used as an indicator to reject mail. There are legitimate outbound email servers which have either no reverse DNS, or reverse DNS which does not match up with forward DNS. The value of this check is its usefulness in discovering definitive facts about the outbound servers who pass this check.
total_score: Optionally, you can set the action to take on pass or fail for each check to Score - and a scoring value. Then set a total_score threshold, and an action to take based on pass or fail of that threshold.
New types of checks and actions
The structure of checks and actions is designed to be flexible to adding new types of checks and new types of actions. For example, spf_allowed, tempfailing of unknown new ip/domain combinations, anti-phishing checks, identifiability/stability level check. Response codes beyond "Accept, Reject, Scrutinize,Tempfail" are also premeditated.
The Outbound Index community discussion wiki has a section for proposing and discussing new check and action functionality. It is our hope that the brain trust of email, DNS, and spam fighting gurus from around the world will dissect and examine proposals here from every angle.