Re: Replacing SMTP Et Al

I don't disagree with you about necessity to not dwell on existing protocol
compatibility and that we need to design a very usefull system that will 
make it worth it for people to start using it.

However lets not discard also that completely "alien" system will take 
longer to design and implement. There have also been a lot of ideas from 
existing protocol and they should be reused if possible. And completely 
separate mail system will also not work quite as well with end-users.
What is needed is something that can be implemented into end-user mail 
system together with existing mail system. In fact, what is needed is that 
client system will determine if its possible to deliver email using new 
system to the other end and if so use it as well as make new features 
availale to end-user, if its not possible new features may not be 
available to end-user. At some very very future point some may begin only 
accept email through new system, but it should not be our goal for it to 
be done immediatly upon first implemention. 

P.S. My understanding is that current SMTP as came from RFC2822 is not 
prototype at all and people who extended it beyong RFC822 through they 
added enough provisions for new features to be added to the system 
without necessity for it to be redisigned completely from the ground-up.

On 30 Jan 2004, James Craig Burley wrote:

> 
> I can't remember who said this, but it has been said many times: it
> may be pointless to create and deploy an NG email system, as long as
> clients have the option of using SMTP.
> 
> I agree with this line of reasoning to this extent: making NG email
> gratuitously difficult to deal with, compared to its practical
> advantages, dooms it as long as people are willing to receive SMTP
> email.
> 
> But I don't agree with the more-cynical interpretation that, no matter
> how good NG email is, it'll never fly because SMTP email will always
> be available.
> 
> My focus is to propose, for NG email, practical, cost-effective,
> short-term-implementable, yet long-term-worthwhile concepts that make
> it substantially *better* than SMTP email.  To do that, we shouldn't
> fret too much over compatibility with the last two or three decades of
> email; instead, let's think about what we would, ideally, want email
> (and the Internet) to be like for the next four or five decades,
> taking into account some cool stuff like voyages to Mars (but maybe
> not worrying about more-theoretical stuff like lightspeed voyages or
> going through wormholes ;-).
> 
> As sites deploy NG email to try it out, they will, at some point, come
> to appreciate the ability to exercise more-fine-grained control over
> delivery of envelopes vs. messages (header+body), enjoy better overall
> performance, and so on.
> 
> Meanwhile, they'll still be dealing with all the spam and vermin they
> get via SMTP.  That won't likely go away.
> 
> As more of their *valid* clients switch sending via NG email, they'll
> utilize the fine-grained controls to deal more effectively with spam
> and vermin that adapts to use NG email instead of SMTP...
> 
> ...because SMTP can and will be made *artificially* more expensive via
> tactics such as Greylisting, Defer Hostility, Tarpitting, and so on.
> 
> (Note that Dan Bernstein's QMTP is probably very narrowly deployed,
> yet, apparently, there are spamware/verminware exploiters of it!)
> 
> As an example, consider an email that is coming from a
> previously-unknown source, but doesn't look all that suspicious to a
> server receiving it.
> 
> With NG email (as I conceive it anyway ;-), the server can indicate
> that it can and will deliver the envelope, but that it won't take
> responsibility for the message, yet it "will call" for it later on if
> desired.
> 
> Since SMTP email doesn't allow for that, the server receiving the same
> message via SMTP might well decide to defer the message several times,
> tarpit the connection, and do other things that would be more annoying
> and expensive for both legitimate clients and spamware/verminware.
> 
> So there *is* the potential for plenty of incentive for both clients
> and servers to upgrade to NG email as it becomes available, and slowly
> (or swiftly) mothball SMTP email.
> 
> For now, I think we shouldn't worry about this too much, and focus on
> just designing the best, cleanest, simplist email system we can, based
> on our understanding of today's system, which, after all, was just a
> prototype, right?