I an idea we work on is to keep SMTP as it is, and use it for mail
signaling (weemail). The interest is that nothing is to be changed except
to modify slightly the user agent and develop a new agent - a store and
retrieve mail server which may also be used as a gateway between the
current and the new system. The "you've got mail" is then not refering to a
piece of junk with emebeded virus you have been forfced to accept into your
computer and spend bandwidth for, but to a file of any kind you can chose
to disregard and leave on the sender's server or read totally or in part, etc.
This does not kill spam as there are ways to fake a server. But it makes
wild spam far more complex and drastically reduces the bandwidth usage.
The possibilties it easily allows, like dynamic distribution lists, also
permits to prioritize the reader interest and to leave the spam at the
bottom of the basket. Mail URLs also allows to more easily hunt for known
spam or to disregard known commercial sources - or already read posts.
It is there quite easy to use 0-Z numbering to name LHS and to have a
resolution system into any vernacular (ML, menus, emoticon, etc.).
jfc
At 02:47 26/01/04, william(_at_)elan(_dot_)net wrote:
First of all end-users would not care much what protocol it is when
"you've got mail" pops up.
And for designers, programmers, and quicker implementation its quite a bit
better if new protocol and old one share certain components. For example
MIME encoding/decoding, etc. It would faciliate process if protocol can
be implemented on same mail server software that would be able to decide
based on certain dns or other parameters what protocol to use when sending
email to the other end.
And look at the example of IPv4 vs IPv6 - IPv6. While there are substantial
improvements in features available with IPv6, as far as implementation and
design and application programmings, its not that different.
On Sun, 25 Jan 2004, Keith Moore wrote:
>
> I'm all for separating the envelope from the message content, but I'd
> be interested in investigating an even more radical change - (probably)
> scrapping SMTP entirely or (less likely) branching out of the SMTP
> state machine very early. Or in other words, I could see making the
> new protocol similar enough to SMTP that a single server could
> implement both, but that might just invite confusion.