RE: On the spam problem...

I'm not really sold on the "spam problem" being as serious as
it's made to sound.  As has been aptly argued in another thread,
the definition of what is spam lies solely with the user.  One
man's spam is another's ham.  However, the average user today
does not take advantage of even the limited control they MIGHT
have over the problem, via receive-side filters etc.  Most just
want the problem to "go away".  Another way to express this is
that they want service providers to block spam without the added
complexity that user control implies.  The REAL problem is
reducing the rate of false positives and false negatives.

My opinion is that we should add a "registered mail" facility to
allow recipients (or domains) to require the presence of a
keyed-HMAC token in their messages.  It would work like this:


1. Unsolicited e-mail from [email protected] arrives in mail server
in domain xyx.abc.com.

2. xyz.abc.com blocks delivery of the message, and sends back a
message (perhaps a new MDN type) containing an XML form
soliciting the keyed-HMAC extension, and including the secret key
for this sender.  If exclusion of automated messages is desired,
then the key can be represented as a distorted image to make
parsing difficult.

3. IFF [email protected] proves to be an accurrate address, they
will receive the form containing the key.

4. [email protected] employs the key in future messages to generate
an extension containing a keyed HMAC token that includes the
source address and a timestamp.

5. On receipt, xyz.abc.com will look up the key for
[email protected] in a local database of registered senders.

6. If the HMAC token is correct, the message passes.  If the HMAC
token if flawed, the message is blocked.  If the token extension
is absent, the MDN with XML form is sent.

7. If xyz.abc.com sends some number (exact # is a local matter)
of MDNs to spammer.foo.com, it could add [email protected] to a
local blacklist and cease responding.

8. Allow a facility for [email protected] to send an HMAC protected
extension to change their key in the local database.


This would give recipient users or domains a powerful tool to
reject mail from non-existent addresses, valid but usurped
addressed (because the usurped user won't respond to the XML
MDN), and messages from automated systems.  The approach supports
commonly desired policy constraint.  The recipient half of the
system can be implememented entirely on the server side.  The
cryptography used does not have to be extreme.  This seems to me
simple, but offering a lot of advantages.

Anyway, that's just my 2 cents.

Regards,
Chris




-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jacob Palme
Sent: Friday, February 06, 2004 06:01
To: [email protected]
Subject: Re: On the spam problem...



At 15.09 -0800 04-02-05, Einar Stefferud wrote:
>Hello Jacob -- Telephone systems ran a micropayment systems for 
>decades, Charging for calls by the minute.  the umbers I have
seen are 
>that the cost of the payment systems (aka Billing
>Dept) was in he order of 70% of the cost of phone service.
>
>This is why most have gone to flat fees for phone service,
because it 
>is competitive.  When the cost per unit becomes small enough
(like US 
>$0.10 cents) even the hone companies cannot afford to run the 
>micropayment system any more.
>
>The cost of the payment system will dwarf the cost of EMAIL.
>
>I understand the the list wants to openly consider any and all
ideas, 
>but lets not fail to discuss them in the light of reality.
>
>It is fine by me to include the idea, but not under false
assumptions 
>of cost.
>
>So, my comments are as legitimate as yours;-)...

But this was a long time ago. Computers and networks have become
much much less expensive in the last ten years. I do not
understand why they could not design a real low-cost micopayment
system.

But since they have not succeeded in doing this, I guess
you are right, there must be some hitch causing the cost to
be high even with todays equipment.

In Sweden, phone companies nowadays charge per call and
provide a detailed itinerary on the bill, usually once
every third month, of every single call, even local calls.
The typical price of a phone call between any two
fixed-line (non-cellular) phones in Sweden is around 3
cents in Sweden. The Swedish phone companies do not seem to have
any problem handling such small items in their bills!
-- 
Jacob Palme <[email protected]> (Stockholm University and KTH) for
more info see URL: http://www.dsv.su.se/jpalme/