mail-ng
[Top] [All Lists]

Re: [mail-ng]: Some existing proposals for next-generation email

2004-01-29 18:43:37

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.



<Prev in Thread] Current Thread [Next in Thread>