Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA08273; Thu, 7 Mar 1996 14:59:47 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.4); Thu, 7 Mar 1996 14:59:23 -0500 Received: from koobera.math.uic.edu by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA08215; Thu, 7 Mar 1996 14:59:19 -0500 Received: (qmail-queue invoked by uid 666); 7 Mar 1996 20:01:06 GMT Date: 7 Mar 1996 20:01:06 GMT Message-ID: <19960307200106.18212.qmail@koobera.math.uic.edu> From: djb@koobera.math.uic.edu (D. J. Bernstein) To: drums@cs.utk.edu Subject: Re: Message format document outline > Invisible continuation lines must not be generated. There then > becomes no requirement on how they are recognized or interpreted. This is incompatible with existing practice. Yes, it's unfortunate that such messages exist, but they do, and an 822bis parser shouldn't choke on a valid 822 message. Mail messages stick around forever. I suggest must-not-generate-but-must-interpret-properly. > I am clarifying in the BNF which nonterminals are lexical ``Clarifying''? RFC 822, section 3.3, makes perfectly clear what its lexical tokens are. You are _changing_ the rules. For example, disallowing whitespace in domains would break some RFC 822 examples. Has this been discussed? [ programs that understand only one timezone spec: ``GMT'' ] > aren't such programs hopelessly broken? Yes, they are, but there are enough of them that they're worth supporting. RFC 822 lets me support them. RFC 1123 says I shouldn't. You're saying that I can't. That's going too far. > > John has suggested that, for something to be ``reasonably considered a > > modern Internet MTA,'' it must store all mail messages in CRLF form. > I don't recall making this statement. You said that qmail ``has quite a ways to go to be reasonably considered a modern Internet MTA.'' You then gave a list of seven items, of which items 1 and 2 were that I ``should store messages in canonical RFC 822 format,'' by which you meant ``lines being CRLF-separated.'' > This is the definition that already exists in both RFC 822 and MIME. RFC 822 doesn't adequately distinguish between content and encoding. Anyway, even if that's the view taken in a few new RFCs, it's _wrong_. A mail message is a sequence of lines. Users know this. Most commercial UNIX mail software, including practically every OS vendor's built-in mail software, uses this model. I object to any attempt to impose a different definition. ---Dan