Re: Setting the stage
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
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. We shouldn't *have* to convince
average users to support this upgrade, any more than an average user
should be involved in deciding whether or not to upgrade to IPV6.
No, you didn't read far enough. Having mandatory SMTP extensions - eg
8 bit data would be fine IF it was called a different protocol and
didn't have to maintain backwards compatibility with SMTP - eg on a
different port with gateways to communicate with SMTP servers.
Okay, I see the point. Not sure I agree with it, I see it.
We'll need gateways anyway for whatever new protocol is designed (if
any), so why throw away the good with the bad.
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
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.
(for the record, the reason it was greeking was a data store problem --
it turns out pieces of the text weren't in UTF8 as they were supposed
to be, and when you take big5 and send it out as UTF8, bad things
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. 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.