Re: Email Web of Trust - Defining the metrics

Mark Baugher wrote:
> At 10:17 AM 3/17/2004, Alan DeKok wrote:
> 
>> Mark Baugher <[email protected]> wrote:
>> >     I think we should try to capture the antispam counters as SNMP
>> > Management Information objects (SMIv2), we should define access to 
>> these
>> > counters using SNMPv3, and we should consider shortcomings and 
>> alternatives
>> > to SMIv2 and to SNMPv3.
>>
>>   I agree.  Having a standard for recording such information means
>> that it's easier to exchange data, and to talk about that data.
>>
>> > For example, can IPsec be used for providing privacy and antidos as
>> > well as confidentiality and integrity to SNMP protocol operations?
>>
>>   I would start off by defining what data needs to be recorded, and
>> worry about publication/exchange of that data later.
> 
> 
> Here is what I have gleaned from a few notes posted to this list.
> 1. count messages accepted from a source by the MTA
> 2. count messages accepted from a source by the MUA
> 3. count messages identified as spam from a source by the MTA
> 4. count messages rejected as spam from a source by the MUA
> 

Regarding the metrics above, we might want to separate the spam metrics 
from the judgement-independent metrics.

We should also take a look at the MIB for MTAs that you referenced 
earlier and see if any of those counters apply. Metrics from SenderBase 
might be a good idea also.

> The model is that the MTA is maintaining counters of actions that
> it takes upon receipt of a message and is maintaining counters of
> actions that an MUA takes in response to mail that it forwards to
> the MUA.  The protocol for this reporting is not yet defined, but
> I'd expect that some authentication requirement is needed.
> 

The filtering subgroup is currently talking about MUA/MTA 
communications. I can forward this idea into their discussion if we can 
state what we are looking for clearly. We can also concentrate on the 
MTA interaction only.

> 
>> > Is the SNMP management information (SMI) definition suitable for
>> > what we need or are there better ways to represent the information?
>>
>>   SNMP is probably sufficient.
> 
> 
> I can imagine using SNMP to fetch the data and manage the MTA.  This
> does not scale to large numbers of peers since it would burden the
> MTA with a plethora of SNMP get requests.  So after the data is fetched,
> it can be disseminated in a variety of ways and authenticated (e.g.
> http://www.cl.cam.ac.uk/ftp/users/rja14/wax.ps.gz )
> 

DNS has two advantages - caching and UDP. If we can achieve the same two 
advantages here, that should do the trick (a very weird idea would 
involve the initial information in SNMP and then propogated via P2P or DNS).

> 
>> >    This work should come after a description of one or two applications
>> > that can use the counters such as a trusted reputation service.
>>
>>   I would turn that around.  Once you define the foundation of a
>> service (what it's measuring), it's possible then, and only then, to
>> describe how that services uses that data.
>>
>> >   I expect we would undertake this work only if we are sure that it
>> > can support a trusted reputation service using, for example, a web
>> > of trust model where members trust other members to maintain counter
>> > integrity.
>>
>>   A system should be immune to attacks on the counters.  At the
>> minimum, if everyone maintains their own counters, you know how much
>> you can trust the data.
> 
> 
> I think there are two concerns.  One is how well the counter is implemented
> according to the natural-language specification.  This will vary between
> implementations but there should be a standard reference implementation.
> I don't know if there is a mail mib reference implementation but it is
> a draft standard so there is likely one out there.
> 
> The second concern is the integrity of the counters against subversion
> and attack.
> 

If any of the counters count spam, then the definition of spam by that 
MTA comes into the picture which of course makes this all much more muddy.

> 
>> >    This work could be considered as a formal RG work item and 
>> intended to
>> > be published as an Experimental RFC (such RGs publish on 
>> Experimental or
>> > Informational RFCs).  I would be willing to author or co-author the
>> > document.  I have previously done an SNMPv1 MIB using an SMIv2 
>> compiler,
>> > http://www.ietf.org/rfc/rfc2959.txt
>>
>>   Sounds good to me.
> 
> 
> How would you proceed?  I was going to just start on a MIB document but I
> think Yakov might like to see a counter list as a separate document, 
> possibly
> accompanied with some discussion for how the counters can be maintained,
> accessed and used.
> 

IMHO, it might make it easier for people to read about the idea if they 
don't have to parse through the MIB syntax. So one document with two 
parts - one for the list of counters + discussion, and the second with 
the actual syntax might be helpful unless MIB documents have that 
already. This of course is my personal opinion.

Yakov