Revisions for Lists

??changed:
-
**NOTE:** If you object to the relevance or usefulness of some of the following criteria for sorting email, please <a href="#notes">read this</A> before commenting.

The following resources need to be kept up to date:

**Domain suffixes list** such as country tlds and multi-level suffixes. **Usage**: Used everywhere the domain part of email address or PTR is examined, to determine the "base domain." **Origin**: This list was created by merging several available lists. **Maintenance**: Propose that we add a web interface for submission of additions, deletions, corrections and establish criteria for testing the accuracy of submissions. Contact the sources of the original lists we merged, discuss their sources, determine how often to search for other such lists or updates.

**PTR** such as lists or regex for affirmed MTA / not MTA / dynamic / other verified reverse DNS. **Usage**: Whitelisting, testing, scoring, expressions which make use of the verified matching forward and reverse DNS of an IP address. **Origin**:   Sought PTR for dynamic IP ranges from existing lists, condensed to a table of patterns, added additional "dynamic" and claimed MTA records by observation, or patterns / ranges specifically affirmed in writing by the ISP which owns the domain. **Maintenance**: Propose to use Meng Wong's or other "broadband identifier" "looks like a broadband" or looks dynamic regex. Propose to use / improve on existing "looks like an MTA." The regex probably would work best supplemented by a table because some rules are specific to certain ISPs. Propose to collaborate with others who are working on the same issue of PTR identification, utilize our "no email" method of authenticatin domain owner / authorized person to add / remove / correct list. Engage regex experts to review any regexs utilzed.

**Domain registration creation dates** **Usage**: Test that require different criteria to pass for old domains vs new domains or domains obtained during certain gold rush periods or before / after certain usage of registration date for anti-spam was commonly assumed. **Origin**: The registry system is the obvious source of this data for com net org edu - however many other registries do not provide this data at all or not accurately. "Age for dollars" may also become a common practice in the future just as "Fresh IPs for $" or "Anonymous registration for $" is now. Therefore "first seen in the mail system" and other independent detection has been useful. We purchased several hundred million records and condensed out what was useful for establishing domain age and combined this with daily domain change parsing from registries. **Maintenance**: We update daily from available registry systems and first appearance for others. An issue to consider is a domain in use by a stable identifiable business that goes out of business - expiring and being deleted - then being picked up by a spammer. Or a domain never used in spam and having an old registration date - being sold to a spammer. Detecting change of ownership may be useful. However a spammer just as well could not make any changes to the registration record other than DNS and just pay for the right to use it. Speculation this would be a rare occurence and short-lived usefulness due to RHS listing.
<P>
<HR>
<P>
<a name="notes"></A>
<P>
We are successfully using the above data to serve the needs of business customers, with no other form of anti-spam needed. IE, no message body word / content analysis, no Bayesian, no hashing, no training. None of the above data is used by itself  to determine the status of an email. We don't "reject if no RDNS" and we don't "reject if the RDNS looks like a broadband."
However, if we may use the "looks like a broadband" or "looks dynamic" in combination with other test to require that it pass certain other tests if the PTR looks dynamic. To reiterate redundantly again, instead of IsolatedScoring, we use the results of multiple tests in logical expressions such as - simplified: "if the RHS domain passes the registration age test AND matches the end of the verified PTR AND the PTR looks dynamic, then other thresholds must be above X or it fails."