NetBSD Problem Report #57269

From mouse@Stone.Rodents-Montreal.ORG  Tue Mar 14 20:59:00 2023
Return-Path: <mouse@Stone.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 3B9951A9239
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 14 Mar 2023 20:59:00 +0000 (UTC)
Message-Id: <202303142058.QAA02106@Stone.Rodents-Montreal.ORG>
Date: Tue, 14 Mar 2023 16:58:57 -0400 (EDT)
From: Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@NetBSD.org
Subject: nc(1) manpage includes broken example
X-Send-Pr-Version: 3.95

>Number:         57269
>Category:       bin
>Synopsis:       Incorrect example in 9.1 nc(1) manpage
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 14 21:00:01 +0000 2023
>Originator:     Mouse
>Release:        NetBSD 9.1
>Organization:
	Dis-
>Environment:
	Probably any; noticed on
System: NetBSD Finch.Rodents-Montreal.ORG 9.1 NetBSD 9.1 (GEN91) #0: Tue Mar 7 18:09:34 EST 2023 mouse@Finch.Rodents-Montreal.ORG:/home/mouse/kbuild/GEN91 amd64
Architecture: x86_64
Machine: amd64
>Description:
	nc(1) gives some examples of its use.  One of them is

	     More complicated examples can be built up when the user knows the format
	     of requests required by the server.  As another example, an email may be
	     submitted to an SMTP server using:

	           $ nc localhost 25 << EOF
	           HELO host.example.com
	           MAIL FROM:<user@host.example.com>
	           RCPT TO:<user2@host.example.com>
	           DATA
	           Body of email.
	           .
	           QUIT
	           EOF

	but this is invalid SMTP; it is not valid to send a command
	before receiving the response to the previous one unless
	pipelining has been negotiated on.  (Some SMTP servers may be
	willing to let the client get away with this anyway, but I
	think that, at the very least, this should be noted with the
	example.)  As RFC5321 puts it,

	                 The dialog is purposely lock-step, one-at-a-time,
	   although this can be modified by mutually agreed upon extension
	   requests such as command pipelining (RFC 2920 [19]).

	A PIPELINING-capable SMTP server _probably_ would let this
	pass, but it's not clear to me whether it's valid to do
	pipelining when using HELO, even if the server would have
	advertised PIPELINING if EHLO had been used - and I'm not sure
	it's ever valid for the client to do it before receiving the
	EHLO response advertising support for it.

>How-To-Repeat:
	Read `man nc'.  Compare against RFC 5321.
>Fix:
	Proposed change (the change consists of new text after the
	exmaple):

	     More complicated examples can be built up when the user knows the format
	     of requests required by the server.  As another example, an email may be
	     submitted to an SMTP server using:

	           $ nc localhost 25 << EOF
	           HELO host.example.com
	           MAIL FROM:<user@host.example.com>
	           RCPT TO:<user2@host.example.com>
	           DATA
	           Body of email.
	           .
	           QUIT
	           EOF

	     though this particular example depends on the SMTP server
	     not enforcing the requirement that pipelining be
	     negotiated before it is used (see RFCs 5321 and 2920).

Home	PR Database Search