Help Stats Lookup Sign in Join

Welcome : Policy and Features

Specific policy is always subject to change and will evolve.

When we first detect mail from a new host, we apply a base rule: The sending host must have a name and the name's next-level domain must have an MX (mail) record.

For example:

There are other initial automated checks which we will not reveal. This policy does not fit all networks and is only an initial guess. It should cause mail from poorly-regulated networks to be rejected. Networks which pass this test will be allowed to send within minutes of "appearing on our radar."

Many exceptions will be made to this rule. For example, some aol mail servers do not pass this test, but of course we wouldn't want to reject mail from aol. So we make an exception to the rule for that entire domain.

We make exceptions to reject mail from networks which do pass the base test as well.

Mail receivers can ask us to reject mail. Mail senders can ask us to accept it. The receiving network owner makes the final decision about what senders to allow on their own network, based on this feedback as well as their own knowledge and experience.

Sending networks will be assigned a status. Status is published to receiving networks via dns records which are queried in real-time by the receiving system.

Accepted mail should receive a tag in the headers including a URL which allows the recipient to ask that mail be rejected in the future. A postfix plug-in is provided to properly tag or reject mail. Plug-ins for other mail systems should be trivial to develop and will be published here when available.

Status codes

If sending hosts are properly associated with a domain, they will automatically inherit the status of their domain. Thus, if a domain has already been through a review process, it's hosts will skip the usual automated checks.

Hosts can change status with or without changing the status of their domain, depending on the circumstances. In this way, a host can be allowed even if it belongs to a domain that is rejected or vice-versa.

Hosts are associated with their true domain, the longest sub-domain they are part of. 2-0-0-127.dsl.example.com's domain is 'dsl.example.com', not 'example.com'. mx01.user.example.com's domain is 'user.example.com'. Mail senders are encouraged to use this feature in order to properly categorize their outbound mail. By doing so, the bad stuff does not hurt the good stuff.

Unfortunately, we are currently limited to allowing or rejecting mail from entire network hosts (mail servers). If a host's mail is blocked it will affect all mail from that host. Mail senders are encouraged to separate good mail from bad mail as best they can in order to mitigate this effect.

Blocked senders can appeal their status by clicking a link in the bounce messages they receive. Mail receivers may ask that mail be rejected by clicking a link in the headers of their received mail (this may be used as a "this is spam" button in their mail client).

When disputes arise, subscriber postmasters will be asked to review the case. A majority of voters is required in order to allow mail. The sender's case for allowing mail as well as the subsequent votes are published for community comment and review.

Receiving administrators always have the last word on their own mail acceptance policy. If they vote to allow or reject mail from a sending network, that preference will be applied to their own filters, even if they are in the minority. They may also elect to allow or reject mail from any network at their discretion, even absent any dispute - and these preferences are kept private.

Life-forms may monitor sending networks' status.

Setup and operation