Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA23914; Sun, 3 Nov 1996 21:09:21 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.7); Sun, 3 Nov 1996 21:09:12 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id VAA23886; Sun, 3 Nov 1996 21:09:11 -0500 Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [128.248.178.247]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA23880; Sun, 3 Nov 1996 21:09:08 -0500 Received: (qmail 624 invoked by uid 666); 4 Nov 1996 02:14:20 -0000 Date: 4 Nov 1996 02:14:20 -0000 Message-ID: <19961104021420.623.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: About that 8-bit discussion..... > So lets then talk about the number of legal 8 bit mime MTAs I've already discussed this. Every version of sendmail since 6.57, by default, violates the 7-bit restrictions in RFC 821 and RFC 1652. > While you are thinking about this, You are falsely assuming that your arguments are new. In fact, they're the same tired old ``why does everybody violate the 7-bit restriction?'' whimpering that we've been hearing from Q-P proponents for years. > Oh, so instead of you having to rewrite your mail server to handle MIME, Why would I want to implement something that hurts the users? > you want us to rewrite ours to handle JustSend8? If you can't handle a message, you must bounce it. This is the fundamental responsibility of an MTA. > Fact: if you go against the specs and send 8 bit data on a 7 bit > channel (as noted by the specs), you have no guarantee that your > data will get to the other server okay. This is tautological. Just-send-8 is, by definition, a strategy for handling cases where where no guarantee is available. Q-P is another, much less effective, strategy. ---Dan