Re: [domainrep] At long last, some drafts and a charter

[Alessandro Vesely <[e-mail]>]

On 05/Jun/11 08:12, Murray S. Kucherawy wrote:
>>> 
>>> We don't have a discovery mechanism for RBLs now.  Do we need one?
>> 
>> It wouldn't hurt.  But then a few RBLs can be enough to work with.
>> We already know how they work.  How about The Spamhaus Whitelist or
>> DNSWL.org?  I'll be grateful if someone reports some news about how
>> they are doing.
> 
> I'm still confused.  How would we write this into a protocol?

We may not write it at all.

> If you're talking about a reputation vocabulary for describing
> reputation services, the current framework does support such a
> thing.  Perhaps you could construct and propose one.  :-)

Yes, if I had experience with it I would.  I'm just saying that we
don't know.  You and Nathaniel have much more email experience than I,
thus your guesses are much better educated than mines, but we are
still guessing.  After we'll have been using the experimental example,
even if we build it using hacks that we'd never dare to write in an
RFC, we may be able to adjust our guesses and fine-tune the protocol.

Isn't that the plan you have in mind, more or less?  But implementing
such an example should be important enough to compare on the charter.

> But that's not the same thing as a discovery mechanism, which means
> a system with no state can make a query someplace and find out
> where reputation services can be found.  RBLs have been plenty
> successful without such a mechanism so far.

Discovery is one such guess, based on the huge number of reputation
providers that would be required for manually inspecting each domain's
practices --see below.

> Why would a positive assertion be any more difficult to do than a
> negative assertion?  Both involve collecting history about
> something and then doing some analysis work to form an opinion.

IME, there are many more black lists than white ones, and while some
BLs are used to make final decisions, e.g. rejecting a message, WLs
only contribute to a message's score.  (I recall discussing software
changes needed for whitelisting just some months ago, and they're not
yet implemented in the particular MTA I use.)  I conclude that the
difficulty gap must be relevant.

> I don't think the protocol needs to change, though in either the
> positive or negative case the vocabulary must be carefully chosen.

You may well be right...

>> For some kinds of assertions, one has to consider abuse-reports
>> and investigate a domain's reaction to receiving them. How about
>> assertions such as reacts-to-abuse-reports, has-personal-ids?
> 
> Sure, the current framework supports stuff like this as well.
> Perhaps you'd like to try writing a vocabulary draft for this kind
> of thing?

They are two other guesses.  I have a rough idea on how to evaluate
the first one, hinged on banning users from sending as a reaction to
abuse reports.  No idea for the second one, except manually trying to
get an account at the relevant domain --see above.  Even assuming such
assertions would be undoubtedly useful, they are useless if they
cannot be computed and retrieved.  Thus, I would not write them in an
RFC, at this stage, because useless vocabulary entries would diminish
the overall value of the protocol.