On Fri, Oct 22, 2004 at 02:28:06PM -0400, Jim Whitescarver wrote:
Trust networks are needed to avoid malicious blocking. Participants
should be able to negotiate the degree of confirmation desired before
blocking and choose trusted and untrusted sources. There need to be
mechanisms for sharing black lists, whitelists, incidents, reprieve
requests.
This is one of the ideas of DNS-MTAMARK. In reverse DNS mark a IP as a
designated mailserver.
I also introduce the use of "honey pot" email addresses for spam
identification, which is an idea I have not seem elsewhere.
There are thousands of the and they are in wide use.
Please let me know if there are any relevant activities in Collaborative
real time spam blocking standards activities.
spamcop has a blacklist that is feeded by spam reports and uses a short
time to live for entries, so that active spews can be blocked fast.
However there are a lot of problems involved in blacklists (and
whitelists also):
1) stale entries
we have our own maintained blacklists with entries dating back to
2001. The list has about 100 million IP addresses listed and it
for sure has stale entries.
2) grouping addresses
remember: some admins at ISPs a fscking dumb.
I have seen cases where they had one or two official mailservers in
the same /24 as their dialin accounts. And as they use some automatic
DNS maintenace tool the rev DNS for that mailservers is even the same
as for the dialin lines. You have 5 incidents from that subnet, you
group and block the whole /24 and your tech hotline has some fun with
angry customers.
3) classification
we operate a network of some hundred mailservers for our customers.
These include virus checking. We had the idea to automatically run
a blacklist of "virus spews" (that are also spam spews in a lot of
cases) by sending UDP messages to a centralized server that puts the
IPs from that messages in a blacklist.
Bad idea.
Really a lot of the messages going to the mailservers are forwards
that are routed through mailservers without virus checking. Within
24 hours we had tons of large, official mailservers of large ISPs and
organisations on the blocklist. Luckily in the test phase we used it
for tagging only and didn't block hard.
Even setting a timeout of 4 hours for the entries didn't change much.
4) the same problem above for viruses applies to spam messages, too.
For dialup customers we provide outgoing relays (smarthosts). Although
we have a close monitoring of those servers and abuse is detected
very fast usually and we block the customer (open relay, virus,
feedback script on the webserver).
However even the e.g. 500 messages going through may trigger honey
pots and have the server blacklisted. Due to some latency (managing
the blacklists) the entry may even be done after we already have
fixed the problem.
5) we do artificial backup MX
spammers and even viruses prefer to connect to backup MX server
because they have weaker policies than the best MX servers usually.
The greylisting success principle "spammers fire and forget" makes
the artifical backup MX servers also very successful.
Same idea as for the virus detection: feed the hosts connecting to
the backup MX if the best MX is running to a blacklist.
Bad idea.
Even some official mailservers have their own "idea" what to do on
delivery failures (temp or perm) to the best MX and quite some of
them connect do MX servers with a longer distance (bigger prio
number).
During a four weeks test phase we collected about 800000 unique IP
addresses, but through the fact - even it if where only very few -
some of them where from legitimate mailservers it renders this mechanism
useless. Having a big mailserver that makes 300000 connections a day
to the mailservers under your control on the block and be it for
15 minutes does a lot of damage. Even though customers hate spam
they hate it even to have messages blocked they are waiting for,
because they need them urgently or they are of big value.
All this automated blocking looks very good and promising at first glance,
but the devil is in the details ...
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg