Re: : Some existing proposals for next-generation email

At 21:15 29/01/04, Paul Crowley wrote:
>IM2000 (mail lives on sender's server): http://cr.yp.to/im2000.html
>PETmail (sender needs permission): http://www.lothar.com/tech/spam/
>AMTP (policy driven SMTP+TLS): http://amtp.bw.org/
>EMSD (fewest round-trips for mobile devices): http://www.emsd.org/
>X.400 (ITU standard still favoured by some): http://www.alvestrand.no/x400/

weemail (uses any mail system to document mails on a store/retrieve/forward 
server): http://weemail.org
Info in post-scriptum. Not as a proposition but as an example.

Before we start talking about solutions and architectures, I would be 
interested to known what is available about e-mail traffic evaluation; 
modelization tools and statistics. There are so many figures going around.

Thank you. jfc

-------

NB. Weemail stands both for web-service for e-mail.and as "wee" e-mail 
because it uses any existing mailing service to send very small 
"weeheaders". That weeheader is simply a value added pointer to the mail 
(an attachment to retrieve on a on a store and retrieve (and forward 
compatible) server. The weeheader syntax will welcome an unlimited capacity 
for value added/extended services.

The difference with IM2000 - as I understand IM2000 - is that it is 
transparent to the existing mail system (ISPs are not involved). Storing 
and retrieving (coming in) /sending (going out) can be carried by weemail 
servers acting as a "gateway" between the current and weemail services. You 
should even be able to use Outlook safely - but you would probably lose a 
lot of services.

One of the basic features is "writers classes and readers groups". This 
permits to prioritize/screen received mails, and to create dynamically 
prioritized "reading lists". Spam is not filtered out this way, but left at 
the bottom of the readers global reading list.

Wild spam is defeated by the necessity of a referenced e-mail URL. This 
permits to build anti spam real time black databases (urls, hosts, IP). 
OPES [open pluggable edge services running an OCP anti-spam underlays] and 
next generation ONES (open network extended services) between wee-x-changes 
could filter them out on the fly..

Spam saturation (like an atomic explosion once reached a critical mass - 
what some "spammers" are at) is not that easy, because worms cannot send 
mails to world anymore - just to the weemail server.or they have to 
populate the mail servers themselves.

On the implementation side, weemail can be degraded into current mail and 
progressively upgraded by areas of destination (some weemail ULD [user 
level domains] can be imagined under OCP, since a weemail server can be 
thought as an intelligent store/retrieve/(forward during transition) 
dispatcher.

The interest is that LHS vernacular is easily supported (weemail servers 
can support alliasing menus; conversion from 0-Z numbering to Unicode, 
etc.). So are multilinguism and multi format. Mails can be anything from 
text to videos. Many additional features like partial reading, control of 
the mail by the author until the reading time, mail-updates, mail 
databases, statistics, paid mails, etc. etc. can easily be imagined.