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.