Re: RBL - Back to basics
Hello!
On Fri, May 03, 2002 at 10:34:09AM +1000, Glenn Hocking wrote:
> Hi again
>
> Really the comparison between rbl lists is academic. It is good that
> there are many different and evolving systems to block spam accordingly
> with different success rates.
>
> However from a 'email service provider' point of view (as per my
> original email) I do not wish to block ANY legitimate email. The more
> spam that is bounced the better BUT my requirement is purely 'If it
> blocks legitimate email, the rbl is useless'.
>
...
Let me resume, what means do we have, to fight spam:
First: some users kind of want Spam, they don't want that any kind
mail directed to them be restricted, even unsolicited comercial
Email, but we (the sysadmins) don't want this to be
Email-avalanches like dictionary attacks.
We can check at least, if the user-account mail sent to exist,
at an early stage before we accept the Email, so bounces do not
occur on our server (never have seen this - anybody has this
implemented in Qmail? :-)
Second: we can do contents (and credibility) analisys, a la
spam-assasin, and this way decrease our users incomfortability
with manual mail sorting, because we have marked the majority
of Spam-mail for them. The charge is on us.
Third: Fight spam propagation. On the supposition, that Spam-mail
never comes alone we encourage our user to report a
Spam-message to a database, where a checksum is drawn and
published. We further do not accept messages with a checksum
found in the database: Vipul's Razor.
This includes yet loosing messages.
Fourth: Some forms of spam take advantage of flaws in the SMTP
protocol, open relays, forged sender addresses, etc. We can
decide to negate Email globally from servers who allow abuse of
the flaws - RBL. The ones I heard from are:
- remote host is known to allow spammers to use it (most RBL's)
- remote host is an open relay (ordb.org)
- remote host has no account or address where to complain about
spam or other problems (www.rfc-ignorante.com).
The RBL-method tries to educate the remote sysadmin to watch
it's setup and control it's users.
Fifth: We can decide to negate email from invalid senders. (Don't know
if "global" sender validation exists inlined into the
mailserver).
However there are e.g. Mailing lists, where you have to reply
to a subscription notification to activate your subscription -
the purpose is, that the receiver checks if Email to your
supposed (return) address really get's through to the person
who send the initial request.
TMDA - Tagged Message Delivery Agent is a method which brings
this feature to anybodies Mailbox. The user can have a
Blacklist of unwanted sender adresses, a Whitelist of sender
addresses which just should pass through, and everyone else is
requested to confirm manually any Email sent supposedly upon
her/his name.
While I think, that the last one is the smartest way of doing things
for the end user, as spam with forged reply addresses will end up in
the trashbox, without ever touching the users or sysadmins mind, it also
burdens the system, and the whole Internet Mail infrastructure.
The RBL-method is surely the one, which raises the most discussions on
a social level, because it includes pointing at somebody with the
finger "you are bad", and we all know that the most dificult and
ambiguos is to divide good from evil.
Vipul's Razor could suffer the same destiny, as it grows, because it
involves public exposition of personal judgement, although it is
somewhat more dificult to abuse then RBL.
Anyway, I do not see a lot of gain from discussing improvements to the
RBL-method and the like, as they are "social-patches" to a design flaw
of message delivery. Better cure the problem, not the symptoms.
There are several projects which discuss a substitution of traditional
Email with a more modern infrastructure, and I think it is time to
spent effort on pushing this forward and stop loosing time with
preventing what's inevitable - abuse of SMTP.
Personally I just enlisted in one of these projects - im2000 -
http://cr.yp.to/im2000.html, which aparently has been kind of sleepy
during two years, but actually is kind of awakening.
To prevent Spam (really), an Email system has some criteria to
fullfill, I will point out some of them here:
- Sender and Receiver Identity have to be verifyable by the underlying
protocol.
- Transmission of the message contents has to be initiated by the
receiver, not by the sender, to allow beforehand trust/cost
negotiation between the two parties: actual Email always puts the
cost on the (helpless) receiver.
- User configurable comercial advertisment: An Email user shall be
able to allow advertisers to send offers, by criteria defined by the
user.
One of the biggest problems of traditional Email is, that it has an
"open door" policy - any mail from anyone is allowed to get at me.
A new Email system has to implement a "closed door - open mind"
policy, which simpy does not lend to itself to propagate junk to *@*.
As allways - too lengthy and sorry about it, but with
Best Regards,
Jorge-León
P.S.: Probably somebody bravely reading until here has noticed, that
this Email also has the purpose of motivating people to put
forces together with the im2000 effort or some similar proposal.
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: