weemail (was Proposal to define a simple architecture ...)

At 01:28 08/09/03, Keith Moore wrote:
> there are a lot of ways to solve the spam problem that will work if 
> "everybody does it my way."  so far, nobody has figured out how to impose 
> their will on the rest of the net.
True.

As you may know Intlnet is a old non-prof oriented toward community network 
support. I though we could publish drafts documenting our proposed 
solutions. I found we cannot foot the cost of such worthless debates as you 
note it. So we will try to gather all our needs (DNS, IPv6, mail, security, 
etc.) and used words and concepts into a one single "Intlnet-needs 
information draft". We hope this way we might help presenting worked on 
users demands, and worked out yet inexpert users solutions. In return we 
hope we will get expert comments from IETF.

We have a major spam problem and a solution I wish to discuss here as it 
fits the mission of no IETF group as I understand it (this for Harald).

First for you to understand, we use the word "ULD" for "User Level Domain". 
This is a community upper (TLD or SLD) level domain. This helps making the 
concept more generic. An ULD is defined as a community space of naming, 
trust, exchanges and services. It can be designed as a DNS "virtual zone". 
A virtual zone results user defined common characteristics used in a DNS 
file generator. The DNS files are then set-up to support it. So an ULD may 
span several layers or TLD or be a restriction of a zone.

One of our Members is to develop an ULD project implying millions of mail 
addresses in a primary spam target thematic area. They do not want to buy 
thousands of terra byte mail severs with huge bandwidth to filter or carry 
an expected 90/95% spam traffic.
So we devised weemail, I would thank you to review.


"Mail" was defined by a Programing Software Note 49 of Louis Pouzin end of 
1964 and first programmed by Tom Van Vleck. He did it in adding text (first 
on top of) to the recipient mailbox understand as a file. It followed the 
postal model, Louis is very keen of (datagram, zones). I come from a 
different experience and asked Tom and Louis why they did not just transfer 
indexes as I did when developing my own solution 20 years after for a QNX 
based network OS. Louis asked by return if I meant "URL" today? and Tom 
said he developed the pointer concept, that it worked the same.He 
documented the same problems I met. But on the systems he then used 
(Tandem) the needed demon was a complex issue (while it was a QNX adman was 
simple).
So we started discussing the ways, the cons and pros. We are now looking 
for a large provider to help the development phase, run it experimentally 
and then commercially.
1. we name it "web-e-mail" or "wee mail", so weemail. The 
http://weemail.org site is just in French right now. By lack of English 
competence? We should also update the information there.
2. The SMTP protocol is fully respected. There is NO change whatsoever in 
the network itself. Only possible modules to be added. We may want to speed 
some processes in telling in the header that a mail is a weemail. We think 
of a Mail-ID format not to change SMTP.
3. The mail text is only a weemail header (weeheader) made of the frist few 
lines, all starting with "weeXXX:" where XXX is a parameter freely defined 
at ULD level. Everything more is supposed to be stripped off somewhere on 
the path. No attachment, no worms.
4. The basic idea is to send "weeURL: xxx://abc.def.gh?cgi...=zzz" as a 
main or only weeheader information. Some more information of class 
(community of senders) or groups (community of sendees), classing, 
priority, language, type of information, protection and intensification 
etc. can also be passed in the weeheader.
5. This means that the only modifications are at the mail agent. To send a 
weemail it sends the weeheader and stores the message at the URL. To read a 
weemail (if the sendee wants it) it retrieves the messages at the URL.
6. As noted this kind of solution may dramatically increase the number of 
spam attempts. But:
    - the message must be actually stored at an identified URL what is 
more complex and compromising than sending an SMTP burst. We advocate an 
IPv6 address concatenating routing and addressing addresses with a single 
Host ID per host, facilitating the tracking of the Spaming hosts.
    - determining what is spam is a human decision. To track trapped 
copies may be complex. We think that a spammer needs to send 5 times more 
messages if the text stays only one hour in line (delay of mail propagation 
and short time for an equivalent population to retrieve it). This will make 
spam more costly and more noticeable. But also it will make spam far more 
easily identified though its weeURL an information easy to get and track. 
We expect spammers to harp on URLs, but they will need to keep a pattern 
(Domain name, IP, etc.) permitting to identify and report them. We intend 
to experiment to that end two new propositions : OPES for filtering and 
reacting and RID-DOS for inter operator real time alarms and reacting..
   - as you note - we need to impose a solution - to impose it on a 
consistent protected space. To that end only weemail will be accepted in 
every ULD mailboxes. Weemails will have to initiate from ULD dolman names 
and concern ULD weeURLs or partnering URLs..
7. The development as we see it consists first in a prototype mail agent 
and in proposing the acquired experience to main agent developers. Then we 
need to update MTA with a weemail module stripping everything from the 
weemails except the weeheader. Then we need to give an URL to every mailbox 
(this is a policy of the ULD to replace Whois by the web and get an 
universal directory). Eventually we expect to use weemail servers made of a 
webservice dialoguing with the mail agents. The last step could be to 
sometimes use OPES and OCP as a fast alternative to SMTP when an end to end 
service can be provided.
8. as users we see several additional netix advantages (we name "netix" the 
user network operating system like management). We can freely use any 
document format and intensification system with more flexibility than IRM 
and be compatible with many other architectures through simple message 
passing solutions (weeENTRIES in the header). The mail-agent/weemail server 
relation might be easily extended to support extended (global community) 
services. May be all could be made OPES directly running OCP.
jfc