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