Re: Email Web of Trust - Defining the metrics

Yakov Shafranovich <[email protected]> Thu, 18 Mar 2004 01:29:35 -0500
Newsgroups gmane.ietf.asrg.smtpverify
Organization SolidMatrix Technologies, Inc.
Message-ID <[email protected]>
Mark Baugher wrote:
> At 12:40 PM 3/16/2004, Yakov Shafranovich wrote:
> 
>> Mark Baugher wrote:
>>
>>> Yakov,
>>>    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.  For example, can IPsec be used 
>>> for providing privacy and antidos as well as confidentiality and 
>>> integrity to SNMP protocol operations?  Is the SNMP management 
>>> information (SMI) definition suitable for what we need or are there 
>>> better ways to represent the information?
>>
>>
>> IMHO, I think we should first define what types of counters we are 
>> including and then how they are represented. This split can help us 
>> evaluate the benefit vs. cost of the idea itself separate from 
>> implementation details.
> 
> 
> Regarding "implementation details," I think that use of SNMP is more 
> than an implementation detail because it entails a certain model that 
> may or may not be what we want for a reputation service.  SNMP v1/2 have 
> a management-application to managed-entity model of interaction, for 
> example, and some types of management data can be represented easily 
> while others cannot.  SNMPv3 also has a security model that may or may 
> not meet the needs of a reputation service.  We should definitely look 
> into it and treat it as a strawman approach that lets people experiment, 
> critique, and maybe even reject following analysis and experience.
> 

Sorry for not responding before, I am trying to plow through all of my 
mail right now :(

I agree with using it as a strawman approach. My *only* concern is that 
an MIB syntax might be hard for non-SNMP people to read so it might be 
better to include something in plain english separate from the actual 
MIB definition.

> Regarding the counters, I think this is something that the entire 
> subgroup needs to participate in and contribute to.  If it were up to 
> me, I would have two classes of counters, one for the mail that the 
> relay flagged as "probably spam" and the second class of counters would 
> be for mail that the user rejected as "spam."  This is probably naive.  
> And it assumes that there is some authenticated means for a user agent 
> to communicate the disposition of a message to a designated MTA.
> 
> There are probably other objects appropriate for an "antispam MIB" that 
> have nothing to do with reputation such as counts of messages labelled 
> as "probably forged."
> 

We should think about separating the judgement-dependent ("this is 
spam") counters from judgement-independent (average volume, etc.)

Yakov