Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5140B9FB3DA; Mon, 29 Jan 2007 19:36:57 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 17030-07; Mon, 29 Jan 2007 19:36:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from momjian.us (momjian.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id CA8AE9FB3D2; Mon, 29 Jan 2007 19:36:53 -0400 (AST) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id l0TNata12560; Mon, 29 Jan 2007 18:36:55 -0500 (EST) From: Bruce Momjian Message-Id: <200701292336.l0TNata12560@momjian.us> Subject: Re: Email issues unanswered In-Reply-To: <64196BA371E746FF3C0DCF47@ganymede.hub.org> To: "Marc G. Fournier" Date: Mon, 29 Jan 2007 18:36:55 -0500 (EST) CC: Andrew Sullivan , PostgreSQL www X-Mailer: ELM [version 2.4ME+ PL123] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/121 X-Sequence-Number: 11388 Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > - --On Monday, January 29, 2007 18:11:38 -0500 Bruce Momjian > wrote: > > > My long subject email going out looks like: > > > > From bruce Fri Jan 26 21:00:37 2007 > > Subject: Re: [GENERAL] Predicted lifespan of different PostgreSQL > > branches > > Looks like something has add a carriage return at the end of PostgreSQL, which > breaks the RFC ... if it was all one line (as per the RFC quote that Andrew Yes, my emaler does that, but see below on the RFC issue. > sent), it wouldn't have gone through (as per the valid long Subject that I just > sent to you) ... > > You are talking about 'multi line' (against RFCs) vs 'long subjects that wrap' > (not against RFCs) ... Right, I am talking about multi-line, and here is the RFC part Andrew mentioned: 2.2.3. Long Header Fields Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. It seems clear here that my emailer is fine and following the RFC. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +