From nobody Sun Aug 7 13:05:18 2016 Return-Path: X-Original-To: usefor@ietfa.amsl.com Delivered-To: usefor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0124112D196 for ; Sun, 7 Aug 2016 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zwcq5ee3Lfv for ; Sun, 7 Aug 2016 13:05:15 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3813A12D09B for ; Sun, 7 Aug 2016 13:05:14 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d11 with ME id UL5B1t00E17Lgi403L5CKH; Sun, 07 Aug 2016 22:05:12 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Sun, 07 Aug 2016 22:05:12 +0200 X-ME-IP: 92.170.5.52 X-Mozilla-News-Host: snews://news.individual.net:563 From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ To: usefor@ietf.org Message-ID: Date: Sun, 7 Aug 2016 22:05:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [usefor] Trailing whitespace in header fields X-BeenThere: usefor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of usefor issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 20:05:18 -0000 Hi, I am currently looking at the checks an injecting server is supposed to perform regarding the syntax of header fields. I am a bit confused by Appendix A.1 of RFC 3977, that gives rules for the format of Netnews articles: A.1. Header Folding Both email and Netnews articles are required to have at least one octet other than space or TAB on each header line. Thus, folding can only happen at one point in each sequence of consecutive spaces or TABs. Netnews articles are further required to have the header name, colon, and following space all on the first line; folding may only happen beyond that space. Finally, some non-conforming software will remove trailing spaces and TABs from a line. Therefore, it might be inadvisable to fold a header after a space or TAB. For maximum safety, header lines SHOULD conform to the following syntax rather than to that in Section 9.7. header = header-name ":" SP [header-content] CRLF header-content = [WS] token *( [CRLF] WS token ) The ABNF syntax, as well as the introductory text in Appendix A.1: a/ allows a space as the only contents of a header field body; b/ allows header field bodies with only a space in their first line; c/ disallows trailing whitespace. This syntax is given as a SHOULD. If we have a look at Section 2.2 of RFC 5536, we have: o All agents MUST generate header fields so that at least one space immediately follows the ':' separating the header field name and the header field body (for compatibility with deployed software, including NNTP [RFC3977] servers). News agents MAY accept header fields that do not contain the required space. o Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non- whitespace character. NOTE: This means that no header field body defined by or referenced by this document can be empty. As a result, rather than using the syntax from Section 3.2.5 of [RFC5322], this document uses a stricter definition: unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP So, mixed together, it means that a/ and b/ are finally disallowed, which is fine (the MUST of RFC 5536 is stronger that the SHOULD of RFC 3977). But c/ is still disallowed as a SHOULD. It means that trailing whitespace SHOULD NOT be present in Netnews header field lines. (RFC 3977 uses a stricter definition of "unstructured" than RFC 5536!) Is it really a rule to enforce for Netnews articles? And does someone know why this is not mentioned at all in RFC 5536? -- Julien ÉLIE « Life is short… so eat dessert first! » From nobody Sun Aug 7 19:09:38 2016 Return-Path: X-Original-To: usefor@ietfa.amsl.com Delivered-To: usefor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5512D798 for ; Sun, 7 Aug 2016 19:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfSS3YuHZO9k for ; Sun, 7 Aug 2016 19:09:34 -0700 (PDT) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993F812D796 for ; Sun, 7 Aug 2016 19:09:34 -0700 (PDT) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 26709118143; Sun, 7 Aug 2016 19:09:32 -0700 (PDT) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 49D8FB414E8; Sun, 7 Aug 2016 19:09:31 -0700 (PDT) From: Russ Allbery To: Julien =?utf-8?Q?=C3=89LIE?= In-Reply-To: ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Sun, 7 Aug 2016 22:05:11 +0200") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Sun, 07 Aug 2016 19:09:31 -0700 Message-ID: <87vazc57vo.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: usefor@ietf.org Subject: Re: [usefor] Trailing whitespace in header fields X-BeenThere: usefor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of usefor issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 02:09:36 -0000 Julien =C3=89LIE writes: > It means that trailing whitespace SHOULD NOT be present in Netnews > header field lines. (RFC 3977 uses a stricter definition of > "unstructured" than RFC 5536!) > Is it really a rule to enforce for Netnews articles? And does someone > know why this is not mentioned at all in RFC 5536? I'm not sure how much we discussed this at the time, but normally trailing whitespace is a SHOULD NOT generate because it tends to get mangled by software and is very fragile. But if that's the only justification (and I can't think of another off-hand), it's not the sort of thing for a server to enforce, just for a client to not do because it may not survive transit. If the server *can* handle it, it probably should try. --=20 Russ Allbery (eagle@eyrie.org) From nobody Mon Aug 8 13:45:43 2016 Return-Path: X-Original-To: usefor@ietfa.amsl.com Delivered-To: usefor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBF12B02F for ; Mon, 8 Aug 2016 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAcXpn54TDV3 for ; Mon, 8 Aug 2016 13:45:40 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9E012B078 for ; Mon, 8 Aug 2016 13:45:39 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d25 with ME id Ukld1t00417Lgi403kld7u; Mon, 08 Aug 2016 22:45:38 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 08 Aug 2016 22:45:38 +0200 X-ME-IP: 92.170.5.52 To: usefor@ietf.org References: <87vazc57vo.fsf@hope.eyrie.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <9054684f-22c8-b631-08a1-6090322bf066@trigofacile.com> Date: Mon, 8 Aug 2016 22:45:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87vazc57vo.fsf@hope.eyrie.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [usefor] Trailing whitespace in header fields X-BeenThere: usefor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of usefor issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 20:45:43 -0000 Hi Russ, >> It means that trailing whitespace SHOULD NOT be present in Netnews >> header field lines. (RFC 3977 uses a stricter definition of >> "unstructured" than RFC 5536!) > >> Is it really a rule to enforce for Netnews articles? And does someone >> know why this is not mentioned at all in RFC 5536? > > I'm not sure how much we discussed this at the time, but normally trailing > whitespace is a SHOULD NOT generate because it tends to get mangled by > software and is very fragile. But if that's the only justification (and I > can't think of another off-hand), it's not the sort of thing for a server > to enforce, just for a client to not do because it may not survive > transit. If the server *can* handle it, it probably should try. OK, perfectly understood. Let's just satisfy the "Duties of an Injecting Agent" (per RFC 5537), that require amongst other things to check the syntax defined by RFC 5536. It therefore does not include any checks about trailing whitespaces. The general checks for headers are: - line length (998 octets), - no white-space-only lines in header field bodies, - no control chars (except of course \r\n for folding, and \t), - header name followed by colon+space and header body. I believe these 4 checks can safely be implemented. INN (nnrpd) already enforces the first. It does not enforce the fourth, which is tolerated by RFC 5536 ("News agents MAY accept header fields that do not contain the required space.") I believe it is OK to keep that tolerance. However, the second and third checks should be enforced. One can currently inject ^H in header names for instance. I hope it corresponds to the rules USEFOR had in mind to enforce. -- Julien ÉLIE « Life is short… so eat dessert first! » From nobody Tue Aug 30 13:31:02 2016 Return-Path: X-Original-To: usefor@ietfa.amsl.com Delivered-To: usefor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F83B12D08F for ; Tue, 30 Aug 2016 13:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_eIWCpSlLIw for ; Tue, 30 Aug 2016 13:30:58 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8214412D08C for ; Tue, 30 Aug 2016 13:30:57 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d09 with ME id dYWt1t00k17Lgi403YWuhL; Tue, 30 Aug 2016 22:30:55 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Tue, 30 Aug 2016 22:30:55 +0200 X-ME-IP: 92.170.5.52 To: ietf-message-headers@lists.ietf.org, usefor@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Tue, 30 Aug 2016 22:30:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [usefor] IANA registration of Cancel-Key, Cancel-Lock, X-Info and X-PGP-Sig X-BeenThere: usefor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of usefor issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 20:31:00 -0000 Hi, I suggest to add a few wide-spread header field names used for Netnews to the Message Headers IANA registry at . Do you have any comment? Header field name: Cancel-Key Applicable protocol: netnews Status: provisional Author/change controller: XXX Specification document(s): https://www.ietf.org/archive/id/draft-ietf-usefor-cancel-lock-01.txt Header field name: Cancel-Lock Applicable protocol: netnews Status: provisional Author/change controller: XXX Specification document(s): https://www.ietf.org/archive/id/draft-ietf-usefor-cancel-lock-01.txt Header field name: X-Info Applicable protocol: netnews Status: provisional Author/change controller: XXX Specification document(s): ftp://ftp.isc.org/pub/pgpcontrol/FORMAT Header field name: X-PGP-Sig Applicable protocol: netnews Status: provisional Author/change controller: XXX Specification document(s): ftp://ftp.isc.org/pub/pgpcontrol/FORMAT If you think the status of these header fields could be "standard", do not hesitate to tell. As for the author/change controller, what should I put? is it me? or the (closed) IETF USEFOR WG? or someone else? Thanks for your point of view about these suggestions. -- Julien ÉLIE « En voyant le lit vide, il le devint. » (Ponson du Terrail)