Subject: [Asrg] Peer to Peer MTA network

From: [email-masked] (Claus Färber)
Date: 07 Mar 2003 00:00:00 +0000

Hallo,

I'd like to present an idea how MTAs could cooperate to stop spamming
hosts:

* Each MTA host calculates a "score" of each host (IP address) it
  receives mail from.

  Messages received from another host contribute to a bad score, if they
  eventually bounce, are filtered by a message filter or are registered
  as bad by any other means.
  Mail that is sucessfully delivered adds to a good score.
  (The idea is, of course, that bad hosts will send a large number of
  "bad" mail, i.e. mail that bounces or is filtered. On the other hand,
  mailing lists tend to send a large number of good messages.)

  It also calculates a degree of reliability of that score based on the
  number of messages used and/or the reliability of each individual
  value the calculation of the score is based on.
  (This would work well with filters whose output is also some sort of
  non-boolean "spamicity", e.g. Bayesian filters.)

* Each MTA shares its score of other hosts with other MTAs by using some
  sort of peer-to-peer network. (For example, UDP packets. Other hosts
  could be found automatically whenever a SMTP connection is made.) Of
  course, public keys are used for authentication.

* Each MTA compares the values it reveives from other hosts with its own
  calculated values and assigns each host (that is, each public key) a
  credibility factor based on how much its own calculated values agree
  with that of other hosts. Of course, it takes the reliabilty of all
  values into account.

  (For example, it host A a good score for a host C with a high
  reliability, it will assign a bad credibility for a host B that claims
  a bad score for C with a high credibility. It wouldn't give B such a
  bad credibility if either A or B had assigned a lower reliability for
  that score.)
  (The credibility is not only to detect rouge hosts, it can also be
  used against bad implementations or hosts that just tend to disagree.)

* Based on the own calculations and the data a host gets from other
  hosts, it calculates the probability that a host (IP) connecting will
  try to send "bad" mail.
  (This should be statistically equivalent to a calculation based on the
  good to bad ratio over all receiving MTAs.)

* Depending on this probability, it can then take counter-measures.
  As a general rule, counter-measures should only delay mail receipt of
  messages (and not cause bounces or even drop messages silently).

  Examples:
  * disabling PIPELINING (and checking that a host does not use it
    nevertheless, which is a common behaviour of spamming sites).
  * accepting only a low number of recipients per connection.
  * random generation of transient(!) errors.
  * refusing SMTP connections randomly.
  * Teergrubing, i.e. causing long delays by sending responses with a
    large number of continuation lines at long intervals.

The idea is that one host that start spamming will set off the alarm by
sending a large number of bad messages: messages that bounce or are
labelled as bad by filters. Ideally, it should not make a differencs if
a large number of messages is sent to a single host or a low number to a
large number of different hosts. In both cases, all hosts should quickly
assign a bad score to the spamming host.

The desired result is that the spamming host is slowed down more and
more until it can't send mail efficiently any longer. Hopefully, this
happens before the spammer has spammed most of the net.

Claus
-- 
http://www.faerber.muc.de/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg