Re: [Asrg] A method to eliminate spam

> First of all the problem is not limited to web clients. It's a problem for 
> everyone who offers a free email service, regardless what clients their 
> "customers" use.
No, the "problem" is that you're applying the current E-Mail system to a 
different method.  If you read the method through, you'll see that there 
are no relay agents in the protocol.  There are send clients(computer users 
trying to send mail), mail hosts(server which houses mail messages for 
later retrieval by an end user), and end users(people who are getting the 
mail).  When you send mail, you're sending to the mail host, you do not 
send to an ISP SMTP server which in turn relays the message to the final 
server.  Like every other server/client setup on the Internet, if the mail 
host is down, your message cannot be sent at that time it does not get 
"cached" somewhere until the SMTP server decides to bounce it back.
> Your "simple solution" is bad.
I think you're misunderstanding it.

> Example:
> Dial-In user ---> ISP's/freemailer's relay
> relay --> final destination (temporally unreachable)
> Dial-In user goes offline
> relay (retrying) --> final destination
>
> If the final destination is a malicious pseudo server, the *relay* will 
> have to handle the requested, impossible authentication task.
There are no relay servers.  If the mail host gives you an impossible task, 
only the send client will be tied up.  Why would a mail host give a mail 
sender an impossible task? and if they did, who's to say that the mail 
sender cannot push a "Cancel" button?  These tasks are designed to take on 
an order of 10 seconds to 1 minutes max, it will be very apparent to a mail 
sender that the task is not completing correctly.  First of all, it's not 
practical for a mail host to give out impossible tasks; mail hosts want 
mail to go through, not to be bounced. Second of all, with no relays how is 
erroneous problems debilitating in any way? when only the mail sender has 
the remote possibility of getting an impossible task, how is it not 
possible to cancel or retry sending?
> Even if you would solve this, so a original sender would not be able to 
> take down relays by using malicious pseudo servers, there remains a problem.
> What if a former normal server would be replaced by a malicious pseudo 
> server (by virus/worm or hack)? All clients would try to solve impossible 
> authentication tasks, given from the "new" server, no matter wheter the 
> were whitelisted at the original server or not.
No relay servers.  Yes, what if a server was replaced by a malicious pseudo 
server and all clients were given impossible tasks?  This question is 
analogous to asking what if a site's web server was replaced with a fake 
one and was giving out bogus web pages.  No admin would should allow his 
server to be replaced by a "malicious pseudo server"; and even if it was, 
how is this problem specifically related to the implementation?  This is a 
problem with any un trusted network and has no bearing on what the overview 
trying to implement.

> In short: If the destination requests an impossible problem solution (in 
> result of error, manipulation or whatever) the sender is the one who 
> suffers. And the sender will not be able to discover this before it has to 
> suffer.
Yes, it is the sender who suffers, how is this an issue?  No bandwidth is 
being used, no CPU time is being used by the mail host when the send client 
is working, only sender computation time, which could be stopped with the 
infamous "Cancel" button.
Yes the sender can discover errors within a finite period of time.  I'm 
sorry for not giving out explicit details in the overview as it was trying 
to portray an idea, not a specific implementation.  In the case of a mail 
sender not knowing when to stop searching for a key; the mail host would be 
able to give parameters to the mail sender as to how large the key is.  If 
the sender is unwilling/unable to find the key of a specified size, it 
knows there was an error and only a few seconds of CPU time was lost.

> > You do bring up an a valid point that web clients would be harder to 
> > implement, but I truly believe the benefits of this method far outweigh a 
> > slightly harder web client implementation.
> I don't think it's a good idea to "solve" problems of the concept in the 
> implementations. "Needs workaround by design" stinks.'
This is not a work around, you're misunderstanding the idea.


> Erm ... and what about replying to the list next time?
My mistake.

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