[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] New take on emerging idea. (Query/C-R system?)

From: Brad Templeton <brad@templetons.com>
People are free to run C/R systems.  A system designed for widescale use
should indeed follow a set of principles:

    a) Properly handle mailing list mail
    b) Never challenge a reply to an E-mail you sent, even if you sent
       it from elsewhere and a different account which aliases over to
       the real mailbox.
    c) Include protections against loops, obviously and challenging other
       challenges, autoresponses etc.

    d) Provide a means to allow the user to review all their blocked mail
       (sorted by spam score) to catch the people who did not respond
       to the challenge.  Yes, these happen regularly even with simple
       challenges, and not because the other person is lazy.

    e) If you don't do (d), provide some other means for anonymous mail
       and yes, mail from people with broken mailers, to make it to you.
ok. here is my system. i posted one on my site, but i don't think anybody read it, so i post the revised system here:

=================================================================

Administrator maintained public "choicelist"(functions as a whitelist, and a blacklist) database:
2 types of entrys:

1. entry.
Each entry contains a name.
Each entry contains email addresses that are safe to recieve from.
Each entry contains subscription addresses, and posting addresses.
Each entry has a unique identification number.
Each entry has contact information.

2. address.
each entry has a list of id #s of entrys it is an authorized sender or reciever for.
this type of entry is created, and maintained by the system, and is only precompiled to reduce search time for type 2 requests.

2 types of requests:
1. entry: returns list of valid sending and recieving addresses for that id#.
2. address: returns list of id #s that it is a valid sender or reciever for.


Responsabilitys:

Database curator:
1. maintain the public database in an operable manner.
2. protect the security of the database against unauthorized changes.
3. Personally take responsability for helping hijacked entrys return to their rightfull controler.
4. keep multiple time stamped backups going back: yesterday, every 5 days for a month, monthly till 1 year ago, and yearly since inseption. Or MORE often.
5. publicly announce changes to message request formats.
6. maintain backwards compatability, as long as some people use old formats.
7. scale the system as needed.
8. Prevent abuse. eg: a human starts to get involved if some entrys get too large, or other problems appear.
9. any other action needed to maintain the system.
10. Perhaps require that entrys be renewed periodialy.


List operator:
1. create an entry.
2. Keep database of addresses up to date.(change the entry if you change addresses)
3. be responsible for your lists contents.
4. give id# of the list's entry to subscribers so they can recieve the list, or use a system where they send the first message to subscribe to the list.
5. transfer control of the entry to the next list operator.


User:
1. enter # given when you sign up for a list if your mail service supports it, or send a subscribe message to the list.


Mail service operator:
1. allow user to enter id #s.
2. NEVER challenge an address in the database.
3. NEVER deliver mail from an address in the database unless an id matches one on the users list, and the user has enabled this system.
4. Do 1,2 AND 3 above, or do none of them (no partial support).
5. incorporate any other features you want.


This system does not disrupt existing systems in any way(it is completely backward compatable):

A list operator who creates an entry continues to send their list as they have in the past(with the limitation on the signup proces).

A Mail service that chooses to supports this system can continue to handle non registered email in any way they choose.

A user can still send and recieve email as they have in the past, yet now they can have added whitelisting/blacklisting/sorting options for registered mail.



to promote adoption, this sytem must have no profit model.
this system benefits all users of the system.
this system will help increase the productivity of the average computer user, and thereby increase tax revenue.
this system allows inovation by service providers, and does not force anyone to use it. People will use it by choice, or not at all.
this system, once in place, will be usefull untill email and the internet are obsolete.
this system, once in place, must remain in place as long as it is being used.


For all these reasons, I believe the best solution is to lobby for the creation of a new government entity to follow through with this plan. Perhaps as an extension of the postal service. Though they can't be trusted to keep the system free.
====================================================================
and
====================================================================

Here is an overview of a Challenge/Response web-mail system compatable with the "choicelist database"

When a new user joins the system:
1. They choose a user name, and a password.
2. they enter contact info, to prvent hijacking.
3. they are presented with a synopsys of challenge response, as well as the mailing list problem.
3. They create a challenge.
4. They gain access to the mail system.

While logged in a user can:
Check inbox
manage messages
manage challenges
manage list id numbers
manage whitelist


When a message arives:
#1 Each time your system recieves an email message the senders address is checked against a whitelist.
If the name IS on the list deliver the message. end
If the name IS NOT on the list procede to #2.
#2 Check the choicelist database, and compare the numbers returned against the users choicelist. If no number is returned go to #3 If the number is in the users choicelist deliver the message. end
If the number is not in the users choicelist delete the message. end
#3 Check the sender against the list of sent tests. If there is no previous test pending completion go to #4 If there is a pending test, store the message for delivery upon test completion. end
#4 Store the message and send a random test from the users test database to the sender with a new serial number. end



When a test answer is recieved:
#1 If the answer's serial number does not match a previously sent test, delete the test.else go to #2
#2 If the answer matches a correct response expected for a correct serial#, deliver the original message (and any others stored), send a small congatulations to the sender, and add the sender to the whitelist with a "pending aproval" flag. else: go to #3
#2 if the message has a correct serial number, but incorrect answer, send the entire Original message (and all others) back to the sender with an explanation that their answer was incorrect.


When a message is sent to an unlisted address:
#1 Check the choicelist database to see if the address is in there.
#2 If it is, ask the user if they would like to add the lists that it belongs to. end
#3 If either answer is no, then create an "aproval pending" entry in the whitelist allowing [not less than two] messages from that address(or system) to bypass the authorization process. this will allow the user to take the test that will be sent back by the other system.



You will notice that this system makes no provisions for a "spam box" or "failed test box". I do this on purpose. this my ideal system, a system that will allow me to live my life, and never worry about spam again. if there was a "spam box", I would feel like I had to check it. with this system I am blissfully unaware of any problems. Missing an email for me is not the end of the world. Anything critical will get to me, a challenge test won't stop that, and choicelisting handles automated messages. My hour spent dealing with spam is more valuable than your 10 seconds.

John Fenley
www.pontifier.com


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg