Subject: [yam] deployment of 8BITMIME?

From: Tony Hansen <[email-masked]>
Date: Sun, 16 Aug 2009 17:50:40 -0400

Some of us have been having a side conversation about interoperability 
reports and deployment reports.

There's a point that John and Dave have been making that I think needs 
to be re-stated again:

When you're looking at the PS => DS stage, you're concerned with 
interoperability, that is, "how well do different implementations of the 
protocol get along with each other?".

But in the DS => FS stage, you're concerned with deployment, that is, 
"how far reaching has this protocol become?"

YAM really needs to be looking at the deployment of the standards.

Dave's latest pre-evaluation draft for RFC 1652 8BITMIME has this text 
in it:

       In the 15 years since publication, this specification has become
       an integral part of all professional SMTP software products and is
       widely supported [[and used?]] in Internet Mail operations.  There
       are no RFC Errata on this specification.

I'd like us to expand on this. It would be useful if members of the YAM 
working group can offer your first-hand knowledge of the deployment and 
use of the 8BITMIME option.

To start the ball rolling, I'll offer this as part of a "deployment report":

	AT&T's in-house MTA used in our ISP services, Maillennium, has
	had 8BITMIME deployed for about 12 years.

Please add to this list.

	Tony Hansen
	[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Aug 2009 18:56:50 -0400

--On Sunday, August 16, 2009 17:50 -0400 Tony Hansen
<[email-masked]> wrote:

> Some of us have been having a side conversation about
> interoperability reports and deployment reports.
> 
> There's a point that John and Dave have been making that I
> think needs to be re-stated again:
> 
> When you're looking at the PS => DS stage, you're concerned
> with interoperability, that is, "how well do different
> implementations of the protocol get along with each other?".
> 
> But in the DS => FS stage, you're concerned with deployment,
> that is, "how far reaching has this protocol become?"
> 
>...

Tony,

One more thought on that subject that occurred to me only while
reading your note.

I think it would be helpful to both us and the IESG --assuming
it is true-- to be able to state explicitly that the deployment
of the specification did not turn up any new interoperability
issues.  Without any issues of "interoperability testing",
deployment experience might indicate interoperability or clarity
problems that were not detected by the PS->DS testing.  We would
certainly be obligated to report such problems if they were
detected (and presumably move to remove the spec from the YAM
agenda so it can be improved, recycled in grade, or even bounced
back to Proposed). It is probably desirable to affirmatively
state that no previously-undetected problems have been found
with implementations that do not interoperate smoothly but that
are both consistent with the spec.

     john

---

From: Ned Freed <[email-masked]>
Date: Sun, 16 Aug 2009 22:21:58 -0700 (PDT)

Process Software's PMDF has supported 8BITMIME ever since the specification was
first released.

Sun's Messaging Server product is derived from PMDF, and has supported 8BITMIME
from it's inception. This MTA is used by many large ISPs around the world.

As for interop problem - really interesting question. We've implemented most of
the SMTP extensions that have been standardized, and most of them have had some
hiccups along the way. With ESMTP itself it was the hang up on bad command
thing, with SIZE it was not getting some error cases right, with PIPELINING it
was broken middleboxes, with NOTARY it was misunderstandings about parameter
encodings, and with CHUNKING it was missed corer cases.

But 8BITMIME? I can think of a single interop problem it has caused. (Mind you,
it's solved lots of such problems, but that's not relevant here.) This is
probably largely due to 8BITMIME being a parameterless announcement that in
practice introduces no new error states and doesn't alter the dialgue in any
significant way.

But regardlless of cause, I'd have to rank this as the least problematic
extension I've ever implemented and seen deployed.

				Ned

---

From: John Levine <[email-masked]>
Date: 17 Aug 2009 12:51:05 -0000

qmail, a popular freeware MTA for Unix and Unix-like systems has
supported 8BITMIME at least since version 1.03 in 1998. As a long
time qmail user and the author of a book on the package, I can say
that I have never encountered any interop problems related to
8BITMIME.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 17 Aug 2009 06:42:23 -0700

John C Klensin wrote:
> issues.  

The current draft already says that there are no Errata on the specification.

That ought to suffice.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Aug 2009 19:00:27 +0100

> To start the ball rolling, I'll offer this as part of a "deployment 

Isode M-Switch supports 8BITMIME since early 1998. It was deployed for 
the isode.com domain shortly after and I am not aware of any problems 
with it.