Re: Email Web of Trust - Defining the metrics

Mark Baugher wrote:

> Jeff,
>
> At 10:05 PM 3/16/2004, Jeff Silverman wrote:
>
>> Mark Baugher wrote:
>>
>>> ...
>>> 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."
>>>
>>> I'm fine with this if some other people are willing to contribute.
>>> Several postings to this thread tell me that several people are at 
>>> least thinking about this problem.
>>
>> ...
>>
>> Regarding the counters, I would like to see number of messages 
>> successfully sent and the number of messages successfully received.
>
>
> That would be sent to and received from a particular IP address or 
> owner of an IP address?

Actually, if the system can be rigged so that every unique E-mail 
address (username + ip address) is logged, then I think the combination 
of username and IP address is the key for the counters.   There is a 
decision tree to my thinking:

Username or not?
Include the username to discriminate between ordinary users and spammers 
on a single MTA.  If a spammer masquerades as an ordinary user, then the 
user should complain to the management of the MTA and the manager will 
boot the spammer for violating the AUP (Acceptable User Practices) 
agreement.

IP address or domain?
The problem is that a legitimate mailer can have separate IP addresses 
for inbound mail or outbound mail, and they can translate to the same or 
different domain names.  So the only thing you can rely to identify the 
origin of a message is the IP address.  It is possible for a given 
domain to have multiple IP addresses for handling mail - I don't see a 
way to deal with all of the possibilities other than some sort of AI 
that maps mailers and domain names.  My intuition tells me that this 
would be slow. 

I am trying to think like a spammer.  What if the spammer sends out ten 
thousand messages.  The counter would dutifully record that.  But then 
if he then sends himself ten thousand messages, from a different 
address, the counter would dutifully record that.  The ratio of inbound 
messages to outbound messages is still 1.0, so under my definition, I 
would conclude that he is not a spammer, even though he is.  If the 
counters count both senders and receivers, then the number of counters 
will increase by N^2,  where N is the number of unique E-mail 
addresses.  That's unreasonable.

Damm.  This is a hard problem, isn't it?

>
>> My observation is that spammers send thousands of messages and 
>> receive few - normal people receive few messages and send fewer.  So, 
>> in my mind, the ratio of inbound to outbound messages is telling.  
>> The other nice thing about the ratio of inbound to outbound messages 
>> is that it yields a floating point number which is directly related 
>> to the probabilty that a messages is spam.  If a given MTA has an 
>> outbound to inbound ratio of a thousand, then probably, it is a 
>> spammer.  If a given MTA has an outbound to inbound ratio of 0.5, 
>> then it is probably not a spammer.
>> The ISP that runs the MTA can look at these numbers himself and, if 
>> he finds one of his users is spamming, can invoke a contract 
>> provision to Do Something about it.
>
>
> That collection, analysis and presentation would be done by the SNMP 
> antispam MIB management application, which would poll or receive 
> alerts from the SNMP management entity.  The management entity 
> maintains the MIB as instrumentation to its protocol processing.
>
>
>> It is not clear to me who maintains the SNMP server that holds the 
>> counters, could somebody please address that question?
>
>
> There is the entity that maintains the counters and one or more 
> management applications that read them, reset them, and set alerts on 
> the counters.

Is this a service that my ISP provides, in addition to providing an 
MTA?  Is my ISP the entity?

>
> Mark
>
>
>
>> Jeff
>
Many thanks,


Jeff