Subject: [Asrg] A question on trust and trust propagation.

From: Devdas Bhagat <[email-masked]>
Date: Sun, 6 Mar 2005 01:10:55 +0530

(All the following is IMHO, please feel free to correct me where I am
wrong. Reply-To is set to the list).

Most trust mechanisms for trying to identify legitimate mail are trying
to push trust information based on the claimed SMTP sender/sender domain.
All these fail, because in general, they more or less trust what the 
sender claims to be.

The one really trustable bit of information in the entire SMTP
transaction is the IP address of the peer.
A large number of people (that I have dealt with) apparently dislike 
making hard blocking decisions based on the IP because of the possibility 
that a legitimate mail and spam may originate from the same source.

However, basing trust on the administrator of the peer IP address is far 
more useful than basing it on the domain of the sender or on the address 
itself. The primary reason for this is that there are currently fewer IP 
addresses than domains, and the majority of the IP addresses that a 
general user would be interested in whitelisting would be run by a 
competent and trustworthy [1] administrator.

Sender address trust based schemes have trouble dealing with forwwarding
email addresses. IP based schemes do not have those issues at all.
Currently, we have DNSBLs which blacklist a sending host, but do nothing
to whitelist one. DNS based whitelists are not as usable as DNSBLs, due
to the consequences of DNS queries failing.

Hence, using a local IP based list of trusted IP addresses makes sense.
However, a question of being able to maintain that whitelist in a
reliable fashion arises. Also, being able to rapidly respond to new 
sending hosts is required. I had drafted up a proposal for a DNSBL which
would allow multiple sites to communicate their trust of different IP
addresses, and also allow site administrators to define trust level for
other domains. This proposal is sitting at 
http://nixcartel.org/~devdas/multisystem-protocol-proposal.txt
With some modifications, a trust propagation mechanism for
whitelisting/blacklisting IP addresses can be generated in a useful
fashion.
This does require that the administrator of the software involved be a
bit more active in determining trust levels (it is not a fire and forget
solution).

Please feel free to rip the proposal apart. This message is being
written late at night because another random conversation triggered it
off, so it may not be as clear as it should actually be.

The core questions:
1> Should we be looking at trusting sending hosts, rather than trusting
sending domains/addresses?
2> Is the method of propogation of trust (based on GPG keys) usable?
Please ignore the usenet/email issues for now, the actual message
transmission format/medium is not relevant to the trust issue.

Devdas Bhagat
[1] A trustworthy administrator here would be one who actually terminates
spamming accounts, or prevents spammer signups in the first place.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 05 Mar 2005 23:17:33 +0100

Devdas Bhagat wrote:
 
> Sender address trust based schemes have trouble dealing with
> forwwarding email addresses.

Not really.  Yesterday I got my first "SPF FAIL" bounce (after
using it for about 9 months).  I resent the mail directly to
the indicated next hop, ready.  And because there was another
unrelated issue with the Admin-C address of galaxyvision I've
informed NetSol and the Tech-C about this issue, maybe they
didn't know it.

I didn't really look into your draft, but using UseNet instead
of DNS to distribute the "gossip" is an interesting idea...

> Please ignore the usenet/email issues

...oops, okay,  How do you define "spam trap" ?  Bye, Frank

---

From: Devdas Bhagat <[email-masked]>
Date: Sun, 6 Mar 2005 10:58:23 +0530

> informed NetSol and the Tech-C about this issue, maybe they
SPF without SRS has issues with forwarding.

> ...oops, okay,  How do you define "spam trap" ?  Bye, Frank
A spamtrap is an address which has never sent email, and will never send
email. The only mail it recieves is bounces from senders spoofing that
address and spam.

The usenet/email idea is one way of distributing the information. You
could do the same thing over any other protocol.

Devdas Bhagat

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 6 Mar 2005 22:34:07 +0100

> transaction is the IP address of the peer.
[...]
> whitelisting/blacklisting IP addresses can be generated in a useful

The main modification which would be necessary would be that
whitelisting information would have to be processed automatically, too.
Your current proposal explicitely forbids that. 

Maybe the information should not be a binary black/white, but a
probability/confidence value? "Mail from that IP is spam with a
probability of 99%" or something like that? For most IPs this will
usually be close to 0% or 100%, but it should be somewhere in between
if there are too few samples, or if the host is transitioning from bad
to good or vice versa.

(I have to look a GOSSiP again - I think that was quite similar)

> sending domains/addresses?

Currently, yes. This may change as spammers move from direct-to-mx
sending to using the smarthost of the zombie, but even then the sending
host will be an entity which you can trust more (if the provider has
effective spam-prevention deployed) or less (if it hasn't).

Sender domains/addresses are currently completely useless as trustable
entities. SPF, DomainKeys etc. may change this, but I'm not optimistic.
Widespread use of cryptographic signatures together with a working PKI
would change it, but I'm not seeing that, either.

> 2> Is the method of propogation of trust (based on GPG keys) usable?

I think so, yes. My proposal for an "email web of trust"
(http://www.hjp.at/projekte/mail-wot/outline.rxml) also uses GPG keys.

> transmission format/medium is not relevant to the trust issue.

How large do you expect the messages to be? A complete record of all
Zombie IP-Adresses seen in the last month or so can easily be a few
million records.

	hp

-- 
   _  | Peter J. Holzer    | Weil wir die materielle Welt nicht so
|_|_) | Sysadmin WSR       | wahrnehmen, wie sie ist, sind Sachen wie
| |   | [email-masked]         | JPEG, MP3 usw. möglich.
__/   | http://www.hjp.at/ |   -- Heiko Schlenker in drsm.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Devdas Bhagat <[email-masked]>
Date: Mon, 7 Mar 2005 08:50:50 +0530

> Your current proposal explicitely forbids that. 

The idea was to have the processing software summarize the whitelisting
records and send them to the admin in a form suitable for updating, with
a list of peers who think that a host should be whitelisted.
This was to prevent spammers from flooding the system with whitelisting
requests.

> if there are too few samples, or if the host is transitioning from bad

Possibly. However, the only thing that I would like to be doing is ether
accepting all mail from the host, or none of it. Rather than trying to
associate the IP with a probability, I am associating the signer with a
trust level. What this person says about this IP is likely to be 99%
true, etc. So you will need more peers before the system will even
prompt the administrator for whitelisting the host.

> effective spam-prevention deployed) or less (if it hasn't).

Exactly.

> Zombie IP-Adresses seen in the last month or so can easily be a few

I expect to see a large initial message, and then smaller hourly
messages. The hourly messages would be a few thousand lines at most,
during a bad spam run.

Devdas Bhagat