Re: Setting the stage

At 16:14 01/02/2004, Chuq Von Rospach wrote:
> On Jan 30, 2004, at 9:33 AM, Paul Smith wrote:
> > > and "kill the dot". If you've done any kind of serious email hacking, 
> > > that phrase should make you twitch. And fundamentally, you can't take 
> > > SMTP out of the 7bit, 1200 baud modem era and still realistically call 
> > > it SMTP, or make it reasonably backwards compatible with SMTP.
> > Actually, those are two reasons that I think are NOT good enough to 
> > warrant discarding SMTP..
> > Neither of those reasons will bother your average user in the slightest!
> agreed. but they aren't intended to be. And to a good degree, I believe 
> that the migration from SMTP to mail-ng isnt' an end-user thing anyway, 
> but an admin thing, and that for the average user, should be primarily 
> invisible, or at worst, trivial.
Hmm, I'd bet most admins don't care about dots and base64 encoding either. 
It's only people who are 'immersed' in email who care.
Most admins would rather stick with something they know and that works than 
switch to something else just because it's newer.
For a change like that there either has to be a BIG advantage to them 
(which losing dots and binary encoding wouldn't be) or there has to be 
pressure from users.
Things like anti-spam/anti-virus help would be the thing to drive it as 
that'd benefit both admins and users.
> > > chance to take what we've learned, apply modern design methods to it, 
> > > and move on to something that doesn't require a PhD to send a bloody message...
> > Actually, that's not the problem.. It's really incredibly simple to send 
> > a message using SMTP..
> Trivial ones, yes. I spent 7 hours yesterday looking for the magic 
> incantation needed to convince a piece of perl code to send an e-mail in 
> Chinese and Korean without greeking the text. When you take SMTP, layer on 
> the 15 or 20 RFCs we've layered on top to wedge all of the things we've 
> wedged onto it in the last 15 years, and then try to use all of that stuff 
> to do what you need to do, and then watch as email clients all over the 
> network fry their little algorithms and get RFC compliant e-mail wrong...
> it's not simple any more. Except in trivial cases.
Yes, agreed.

But, (to play devil's advocate), let's assume that we take SMTP. Make all 
'user readable' headers (subject etc) into UTF8, make message content UTF8, 
make it support binary transport, etc, and make it so you KNOW that 
whatever mail server you talk to, it MUST support that stuff.
Now, would it be as hard to send that Korean text? Could you make it much 
simpler?
This is what I was saying MAY be an alternative to totally redesigning 
everything and throwing away all that has been learnt from SMTP.. I'm not 
saying that's the way it should go, just that this possibility shouldn't be 
ignored. It's not some more SMTP extensions, it's a new standard which is 
based on SMTP but with problems fixed.
(Actually, I'd like some features which are outside any current SMTP 
extensions, but many suggestions made so far aren't - they're in SMTP 
extension features, which, unfortunately, aren't universally supported, and 
probably won't ever be unless they're made mandatory)
Eg, I could easily think of an SMTP variant without dots and C-T-E. This 
would almost certainly be easier to implement in most cases than a totally 
new mail protocol, but it could fulfil *your* main requirements. Put this 
on a new TCP port, call it mail-ng, and have gateways (whose software 
probably almost already exists) - job done. Alternatively let's think up a 
totally new protocol, argue about it for a few years, spend a few more 
years getting the software up to the maturity of our existing mail 
software, then you've done the same thing, but spent a lot more time & 
money on it.
> > That's why you make 'SMTPV2' incompatible with SMTP, but built on the 
> > same building blocks to aid migration.
> I agree with the first part. The second part I have issues with, because 
> it lends itself to never pushing the legacy stuff out the door and into 
> retirement.
But why throw away mature, bug fixed code and bring in new, buggy code?

> If they're completely separate and gatewayed to each other, you can create 
> reasons to 'encourage' folks to make the migration. If you merge them 
> together, you're going to support both code bases for the rest of reality, 
> until mail-search-for-spock comes along and reinvents all of this a third time.
No, you still need the gateways, and MTA/MUA authors would (hopefully) stop 
enhancing their SMTP software. I'm not talking about 'merging' them. It's 
'take what we have, pick the best bits, make them mandatory, tidy up other 
bits, sort out some nasties, and base our new protocol on that', rather 
than 'let's think of something totally new where we need to start 
everything from scratch'.

Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/