(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.
Attachment:
pgpd7Eoh32unh.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg