I agree with much of what Meng says, but I think we need to go a bit
further.
The biggest weaknesses with the blacklist concept is that they attempt to
cover the entire IP address space, they do not cover the more important
domain name space and they only provide negative reports.
With any form of authentication (SPF etc.) you can move from negative
blacklisting to positive accreditation. Rather than trying to identify the
bad guys, identify the good guys.
At present blacklists often create more problems than they solve. It is very
difficult to see who a blacklist is responsible to - in cases like SPEWS
they attempt to deny all accountability.
When spam was a small proportion of email it made sense to list the bad
actors. Today it is much easier to list the good actors - and if nobody can
list you as good the assumption you are a spammer is likely to follow.
I propose adding a mechanism to SPF to allow accreditation records to be
advertised. An acreditation record could work using the same DNS hack as
current day blacklists. The data structure for the accreditation entry would
be something like:
AccreditationNotice :
List ( Accreditation ) Accreditations
Accreditation :
String Protocol // The notification protocol,
usually DNS
String Name // Location of the service
String Prefix // Optional Prefix to add to the DNS address
This could be encoded in a variety of ways - probably best not to overload
the SPF record itself, but it would be useful to be able to know from the
spf record
;; ANSWER SECTION:
example.com. 255 IN TXT "v=spf1
ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24
ip4:205.188.156.0/24 ip4:205.188.157.0/24 ptr:mx.aol.com
accredit:dns:class3accredit.verisign.com:www -all"
The accredit clause is interpreted as follows:
1) Identify the accreditation service
If the service is unknown then this particular email will
get no points for having referred to it. But it is still usefull to know
about the accreditation since feedback type filters can build up a score for
the service.
2) If the service is a known quantity, perform a lookup for an A
record for a DNS address formed as [prefix].name.service. In this case
www.example.comclass3accredit.verisign.com.
3) The greylist score for the service is calculated as some portion
of the returned A record. Folk can suggest a scheme here to work well with
existing services.
So for example say the A record www.example.comclass3accredit.verisign.com
contains 127.0.0.230.
This might mean that the address example.com had a score of 230 points out
of 255. The filter then consults a table to work out the probability that a
genuine message from that address is spam.
The table values are worked out using previous experience of messages with
that type of accreditation. Note that we do not assume that 230 points out
of 255 is good or bad. Obviously it is more likely to be good than bad given
that the owner of example.com was willing to advertise the fact an
accreditation existed.
The interpretation of this data is for spam filters to work out - the same
way that spam assassin works out the value of many other message features in
spam recognition.
The prefix is there to allow existing accreditation data from PKI
certificates to be used as the basis for an accreditation. VeriSign has half
a million DNS addresses which we have spent a lot of time an money
authenticating the owner of. Obviously the fact that a party can get a class
3 certificate does not mean that they are a spammer, but the fact that any
party is willing to give an honest address at which legal process can be
served certainly reduces the probability that they are a spammer.
Phill
-----Original Message-----
From: Meng Weng Wong [mailto:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
Sent: Monday, January 12, 2004 10:38 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] how blacklisting will work in the future
On Mon, Jan 12, 2004 at 04:07:47PM +0100, Dr. Ernst Molitor wrote:
|
| please be serious. If a single vote saying a spam trap has been hit
| would be sufficient to block an e-mail server, this would open up a
| simple way to shut down virtually all e-mail traffic within
minutes. You
| wouldn't want that kind of DOS attack, would you?
|
Today, we have DNSBLs. DNSBLs return a binary yes/no response: either
"known bad" or "no response". All the IPs that could potentially be
"known good" are lumped in with "no response". Already we see a
precision problem.
DNSBLs try to discriminate the entire IPv4 space. As I wrote in my
Linux Journal article:
IPv4 space is 32 bits wide. 2^32 is about 4.2 billion.
4.2 billion
grains of sand would just about fill a pickup truck.
Imagine trying to
paint each individual grain black or white.
IP-based blacklists are a valiant effort, but they
operate at too low a
level. A good DNSBL has to decide whether an IP address
is spammy or
not, and get it right, for each of 4.2 billion IP
addresses. No wonder
DNSBLs come and go: their maintainers burn out and give up.
On Friday, Eric Raymond will talk about greylisting as an
antispam tool
to work in combination with SPF.
This is how greylisting works. If you return 4xx to a legitimate MTA,
it will queue the message for later retry. If you're talking to a
known-good sender, you don't need to greylist. If you're talking to a
known-bad sender, you don't need to greylist. But if you don't know
whether a sender is known good or bad, you need to give your
reputation
provider some time to arrive at a decision.
Greylisting and DNSBLs don't work well together because the
"known-good"
are lumped in with the "no data known".
So, in the future, things may work something like this.
- suppose a spammer goes out and buys a new domain, 32434offerz.com
- the spammer goes out and infects 10,000 new windows machines
- those the domain is not listed in RHSBLs
- those machines are not listed in DNSBLs
- the spammer starts a spam run.
- one of those 10,000 machines connects to your MTA.
- your MTA asks the DNSBLs about the client IP.
- the DNSBL returns "no-data".
- the DNSBL would also return "no-data" for a known good server.
- you cannot make a spam/nonspam decision based on the DNSBL.
- your MTA asks the RHSBLs about the client IP.
- when I say RHSBL, I mean a next-generation RHSBL that gives
a richer answer.
- the RHSBL says:
- i have no reported data about 32434offerz.com.
- this itself is unusual.
- it could be because the domain is new.
- new domains could be good or could be evil. we don't know.
- i recommend that you ask me again the next time they connect.
- you return a 4xx tempfail response. this is greylisting.
- at some point in the next ten minutes, the spammer will hit
a spamtrap.
- let's say the spamtrap will report the spammer to DNSBLs and RHSBLs.
- a DNSBL that gets a report from the spamtrap now knows
about the bad client IP.
- that bad client IP is one out of 10,000.
- an RHSBL that gets a report from the spamtrap now knows
about the bad domain.
- the entire spam run is conducted with that domain.
- an hour later, the spammer tries to connect again. you
check back with the RHSBL.
- the RHSBL says:
- The following statistics count SPF-validated transactions only.
- 32434offerz.com has been known to me for X hours.
- 32434offerz.com has reportedly sent a total of N messages.
- 32434offerz.com has been reported by M spamtraps.
- 32434offerz.com has been reported by H humans as a spammer.
- you have your own policies which use the above numbers as
inputs to an algorithm.
- you decide whether to
- reject the message with a URL saying "you look like a spammer"
- accept the message, but content-filter it
- accept the message without further scrutiny
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡