mail-ng
[Top] [All Lists]

Re: Replacing SMTP Et Al

2004-01-30 02:12:30


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?


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