Re: Reputation semantics

On Thursday, January 05, 2006 at 9:22 PM John Levine wrote:

> A reputation system will look something up.  The input is a
> domain name, or maybe an e-mail address or an IP address.
> The output is, well, what?  A single bit saying yes or no
> (like the typical use of a
> DNSBL?)  A score?  Multiple scores?  A little essay or the
> merits and flaws of the reputee?
>
> I don't know what the answer is, but it seems hard to start
> to build these things if we don't even know what the inputs
> and outputs are.
>
> Perhaps a reasonable way to start would be to survey what
> existing systems like the various DNSBLs and SIQ do.

If what DNS*W*Ls do is of any interest, I can write about how the Habeas
Safelist operates.

For the sake of this discussion, let's assume that the receiver is not
keeping a local copy of the Habeas Safelist and is querying a Habeas
accreditation server.  The input is a reversed IP address.  If the IP
address of interest is 1.2.3.4, enter the following command:

host 4.3.2.1.accredit.habeas.com

If the IP address 1.2.3.4 is included on the Habeas Safelist, then the
accredit server returns a response such as the following:

4.3.2.1.accredit.habeas.com has address 127.0.0.20

The IP address returned by the Habeas accredit server indicates the
permission level at which that IP address is certified; only the final
octet is significant.  The following table shows the values which can be
returned by the Habeas accredit server and their corresponding
permission levels:

Value	       Permission Level
 10	     One-to-one (personal)
 20	     Transactional
 30	     Confirmed opt-in
 40	     Personal referral
 50	     Single opt-in
 60	     Registered but not certified

Thus, in the example above, mail streams originating from 1.2.3.4 are
certified by Habeas as being transactional messages.

If the IP address is not on the Habeas Safelist, the server responds
with NXDOMAIN.

This method allows receivers to set policies about the types of messages
they are willing to accept.  If they are willing to accept one-to-one,
transactional and confirmed opt-in messages, but not personal referral
(e.g., greeting cards, forward-to-a-friend) or single opt-in messages,
they can compose filtering rulesets which will implement those policies.

As for DNS*B*Ls, the combined MAPS lists operated in a similar at one
point (I don't know if it still does).  The first iteration of the RBL+
combined the RBL, the RSS and the DUL.  The RBL+ server would return a
coded response which indicated on which list the IP address in question
appeared.

I hope this is a useful contribution to the discussion.  I'm happy to
answer questions to the extent I won't be disclosing proprietary
information.  The information above is included in my latest round of
additions to the knowledgebase, and will be published on our web site in
the near future.

Regards,

Nick

--

Nick Nicholas
Knowledge Engineer
Habeas Inc.
650-694-3320
nick <at> habeas.com