RE: [Asrg] Hello- and my 2 cents

At 10:31 AM 4/22/2003 -0700, you wrote:
> Perhaps we could get to some minimal requirements for any proposed solution:
>
> 0A) MUST actually reduce the amount of spam.
>
> 0B) MUST NOT cause wanted messages to be lost.
>
> 1) MUST be acceptable to end users, both senders and receivers.
>
> 2) MUST be acceptable to all parties required to deploy infrastucture in
> order to support it.
>
> 3) MUST be robust in the face of minimal effort couterstrategies on the part
> of spam senders.
>
>
> The 'minimal effort' clause meaning that a proposal need not be completely
> foolproof but should certainly not increase costs for the defender that are
> higher than those of the attacker. So proposals for legislative and
> litgation based approaches are acceptable even though there is a well known
> counter-strategy 'move abroad' since that is actually a high cost
> counterstrategy.
>
> So far the commonly proposed solutions that we keep seeing fail as follows:
>
> Challenge/Response
>         Fails criteria #1, this proposal is simply unacceptable to many
> senders who receive unwanted messages. It is also unacceptable to many
> receivers since the wanted mail loss rate is very high - at least on the
> anecdotal evidence we have to date. I would like to propose that any further
> proposals on this topic be acompanied by empirical measurement of that
> point.
Why would the wanted mail loss be high?  If for example messages that did 
not pass the challenge / response test were simply routed into a mailbox 
specifically for such messages rather than thrown away, there should be no 
mail loss any greater than is the case now.  Furthermore, if approval 
messages etc. were to come from a mailing list, one could simply check this 
mailbox for them.
Personally, I do not care if I were to receive 10MB/day of spam -- as long 
as it all could be automatically categorized into a mailbox specifically 
for that purpose.   And sure, I would not bother to look in that mailbox 
_ever_.
Mail clients do not have to throw away messages that fail the challenge / 
response system.  They could simply route those messages that fail into a 
mailbox for that purpose.  People could check that mailbox as often as they 
like. Eventually, I believe, everybody would switch over and that old 
mailbox would be like the USENET alt.* groups that are so full of spam 
nobody bothers to read them anymore.
>         Fails criteria #0B, This proposal is actually very unreliable when
> both the sender and receiver deploy the same scheme. Challenges from one 
> are in turn challenged by the other, or silently discarded, or provide a way of
> circumventing the scheme.
This is only the case if the challenge were sent via e-mail.  It need not 
be so or the challenge could be sent via e-mail but be in a recognizable 
format that would prevent it from being challenged.  (It would also not be 
displayed directly to the user either so to keep it from being used for 
spamming purposes.)
>         Fails criteria #3, there is a simple couter attack that has been
> used already, simply scan archives of mailing lists and forge the from
> address and to address so that the messages appear to come from that list,
> or from a list member.
As I mentioned earlier, the whitelisting does not have to be on the 
sender's e-mail address but could be on a digital signature (stored in a 
special header line) that only the sender would have the keys to 
sign.  Sure, somebody could forge a return address but they would not be 
able to forge the signature.
Thus this counter-attack would fail miserably.

>         Fails criteria #3, another simple counter attack is to simply
> install a responder tha automatically replys to to challenges. This can be
> countered by use of a turing test type approach which then creates serious
> accessibility issues. While these do not trouble many proponents they are a
> concern to many, they are also a concern to the users of RIM and pocket PC
> devices where this type of challenge is simply not possible to match.
Sure, if the challenge were a simple reply to this message then yea, it 
could be easily circumvented.  However, there are two issues here.  If that 
were simply the challenge, there would in this case be an IP 
number/domain/user etc. that uniquely identifies the spammer which is far 
more than we have now.
Furthermore, the challenge could be graphical in nature.  i.e., show the 
faces of 10 people from a side profile and have another picture with a 
front profile and have the user identify which is the same person.
It need not all be in English.  People could set up challenges in whatever 
languages they communicate in.  Personally, I do not care if my challenge 
were in English simply because all the e-mail I can read is in English.  If 
I were to get a message in Chinese it would simply be thrown away anyway 
since I can't read it.  It would be a simple matter for the protocol to 
specify what language the sender would like the challenge in and if it is 
available, then the challenge could be in that language.
I think as far as the challenge / respoonse system is concerned, you are 
throwing up obsticals where none need exist.
I am not saying it is the best system but it sure is one that would work 
given the proper set up.

> Sender Pays,
>         Fails Criteria #0, There is no evidence that suggests that the spam
> senders have less motivation to send email than other parties. While it is
> clear that spam becomes unecconomic at some price point it is far from clear
> that this price point is lower fro spam senders than other senders.
Well, considering the response rate for spam is far less than 1% and is in 
fact from what I understand a fraction of that, "user pays" would soon 
become uneconomical simply due to the poor response rate.
The "User Pays" solution I like somebody posted here some weeks ago.  It is 
that the message would have a signature, message ID, etc. that would key to 
a third party.  If the recipient likes the message, then nothing 
happens.  If the user does not like the message, they could simply press a 
button in their mail client and the sender's account would be debited say : 
$0.05 or $0.10.  The proceeds could go to a charity of the recipient's 
choice to prevent abuse on the recipient's end.  The fact that the 
recipient charged the sender would be sent to the sender so that they can 
take appropriate actions whatever they may be.
Thus for legitimate mail, there would be no cost even though it is 
technically "sender pays."
>         Fails Criteria #1, This proposal is unacceptable to the vast
> majority of people who host IETF mailing lists or any other legitimate bulk
> email solution.
Well, if the recipient were allowed to decide which messages were spam or 
not legitimate mailing lists and legitimate bulk e-mail would incur no cost 
whatsoever.
I suppose part of the question is what "legitimate" bulk e-mail is.  When 
they were passing the Utah spam laws, I watched the president of 
Ancestry.com get up and argue that the solutions in the law wouldn't work 
because it would interfere with their "legitimate" bulk e-mail. (The 
requirement was a toll-free number so people could unsubscribe.)  Now, it 
turns out that somebody I know sends the messages for Ancestry.com and I 
don't remember what the numbers are but it was somewhere in the order of 
10,000,000 bulk e-mail messages a month.
Now as big a company as Ancestry.com is, they in no way have 10,000,000 
members.
The best way to describe what is and what is not spam is that it is in the 
eye of the recipient.  And because of that, it would be fair to let the 
recipient decide if it is spam or not.
>         Fails Criteria #1, There is a built in incentive to cheat and be the
> last to pay the sender charge since recipients are forced to accept email
If the money is held in escrow by a third party, then this isn't an issue.

>         Fails Criteria #2, There is no major ISP that is interested in
> supporting such a scheme, in public or in private.
You keep talking about wanting people to provide proof for their ideas and 
assertions.
Could you please document where the facts came from that "No major ISP that 
is interested in supporting such a scheme, in public or in private."
I would be not only interested in the results but in how they were collected.

>         Fails Criteria #2, Financial transfer systems are expensive to
> maintain, whether or not the charge is convertible or not. The DNS system
> currently costs 0.005 cents per read-only transaction, this amount is
> several orders of magnitude less than those charged in the telephone system.
> This charge is subject to a significant level of complaint. A transfer
> system would cost at least double to maintain and likely an order of
> magniture. The lowest realistic cost that could be charged for maintaining a
> simple ledger based system is $0.05 cents, a level that would render many
> existing Internet uses impossible. It would cost $350 a year to run a
> mailing list with 100 subscribers with 20 posts a day.
Well, I don't see why the DNS system can't be the same as is in current use 
that doesn't seem to have any problems.  Besides, DNS systems don't have to 
be consulted every time due to caching. Thus the DNS would only have to be 
consulted once in a blue moon.
If the recipient were to decide what were spam or not, there would be no 
charge to the mailing list owner.
Besides, it would be trivial to set things up so that there was a 
whitelisting mechanism that as I mentioned earlier keyed on a digital 
signature rather than the sender's mail address.  So, even at the price you 
mentioned, it would cost $0.05 per user to sign up which in this case would 
be $5.00 and afterwards there would not have to be any further 
charge(s).  I think I could afford $5.00 to get a mailing list of 100 
people that wanted to be there.  In fact, I'll pay you $10 for one.
>         Fails Criteria #2, The above calculations are for a system that has
> no protection against fraud. Digital signatures etc significantly increase
> the cost of any solution, whether or not secure hardware is used.
The last time I checked, digital signatures didn't cost me anything to 
generate.
>         Fails Criteria #2, There are well over 1 billion emails sent per day
> to AOL alone. At the above chaging rate that would mean a cost of $180
> million per year.
A cost to who?  To the sender?  Well, I don't see what the deal is.  You 
are talking $180 million across all the users of the Internet not AOL.  And 
as I mentioned, there need not be a cost associated with every e-mail.
In fact, you could look at the "User Pays" as the challenge in a 
challenge-response system.  Whitelisting and the ability for the end user 
to decide what is spam or not would reduce the costs significantly if not 
to infinitesimal levels.  If it cost say: $0.05 per new person you 
contacted you could contact 100 people for $5.00 -- that would go a long 
way.  (Whitelisting etc. would keep you from being billed each and every 
time you contacted the same person.)
>         Fails Criteria #3, There is a simple method of counterattack, simply
> pay the money.
Sure.  And if you send out 1,000,000 spams and if you were billed say: 
$0.02 apiece, it would cost $20,000.  Now let us take one of the 
all-time-favorite spam products -- penis enlargers.  Let us say the product 
cost is $45.  The spammer would have to sell 446 of them just to cover the 
costs of the mailing -- not even the cost of the product.  If the markup 
were 50% (most product markup is 30%), then the spammer would have to sell 
892 of them.  Given that, then the spammer would need a one in 112 response 
rate -- just to break even and not even to make any money.
So, sure, there is a simple counter attack.  But it would quickly become 
uneconomical and the spammer would have to either find products that we all 
want (which won't happen but if they could it wouldn't be spam in many 
people's books anyway) or they would have to go out of business.
>         Fails Criteria #3, Financial tranfer systems are likely to be the
> target of fraud, both to obtain stolen credits and for direct financial
> gain.
If there were several trusted financial transfer systems (i.e., not 
Microsoft nor everybody and their dog) then this isn't a 
problem.  Financial transfer systems could be accredited and as long as the 
"Sender Pays" token comes from an accredited financial transfer system then 
it shouldn't be a problem.
> Blacklists
>         These also fail, but we all know that, that is one reason that spam
> has suddenly become a live issue again, the spam senders are simply to big a
> problem and the scaling problems of blacklists are significant.
Now we agree.  Blacklists are useless in many respects, are open for abuse, 
and often allow people who were unfairly targeted no-recourse to fix the 
problem.
Again, I think you are throwing hurdles in front of solutions.  These need 
not be the ultimate solution but each of the arguments you provided has 
simple workarounds that make the objection moot and make the system a 
workable solution.
-Art


--
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg