Received: from cnri by ietf.org id aa15788; 24 Mar 97 16:57 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa20099; 24 Mar 97 16:57 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id PAA21311 for ietf-nntp-outgoing; Mon, 24 Mar 1997 15:32:18 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id PAA21303 for ; Mon, 24 Mar 1997 15:32:15 -0600 (CST) Received: from owlman.academ.com (sob@OWLMAN.ACADEM.COM [198.137.249.5]) by academ.com (8.8.5/8.7.1) with ESMTP id PAA07590; Mon, 24 Mar 1997 15:32:14 -0600 (CST) Received: (from sob@localhost) by owlman.academ.com (8.8.5/8.6.9) id PAA02281; Mon, 24 Mar 1997 15:32:13 -0600 (CST) Message-Id: <199703242132.PAA02281@owlman.academ.com> From: Stan Barber Date: Mon, 24 Mar 1997 15:32:13 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ietf-nntp@academ.com, nntp-extensions@academ.com Subject: ietf-nntp New version of "Common Practices" Internet Draft is available Sender: owner-ietf-nntp@academ.com Precedence: bulk See ftp://ftp.ietf.org/internet-drafts/draft-barber-nntp-imp-06.txt Comments are welcome. Please mail them to the ietf-nntp list since that will also impact the next version of the RFC977bis draft (coming real soon now). [My apologies for being so long in getting this out. It turned out that I had a far more busy first quarter than I had projected. While this is good for my bank account, it did adversely impact the pro-bono work I was/am doing.] -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.   Received: from cnri by ietf.org id aa16733; 27 Mar 97 17:30 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa22839; 27 Mar 97 17:30 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id QAA10126 for ietf-nntp-outgoing; Thu, 27 Mar 1997 16:13:52 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id QAA10119 for ; Thu, 27 Mar 1997 16:13:50 -0600 (CST) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by academ.com (8.8.5/8.7.1) with ESMTP id QAA11452 for ; Thu, 27 Mar 1997 16:13:44 -0600 (CST) Message-Id: <199703272213.QAA11452@academ.com> Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca) by bcarsde4.localhost; Thu, 27 Mar 1997 15:56:39 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <08140-0@bcarsfba.bnr.ca>; Thu, 27 Mar 1997 16:00:07 -0500 Date: 27 Mar 1997 15:16 EST To: ietf-nntp@academ.com From: Chris Lewis Subject: ietf-nntp Issues with Latest extensions draft Sender: owner-ietf-nntp@academ.com Precedence: bulk Regarding AUTHINFO GENERIC: - second paragraph: INN 1.4x sends a "480" for authentication required, not 380. This is consistent with AUTHINFO USER/PASS. I believe this is true for nntp 1.5.x as well, but I haven't checked it recently (or INN1.5). -- Chris Lewis, Senior Network Security Analyst, Nortel. clewis@nortel.ca; Dept 8M86, Ottawa, Canada. (613) 763-2935.   Received: from cnri by ietf.org id aa17086; 27 Mar 97 17:34 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa22892; 27 Mar 97 17:34 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id QAA10195 for ietf-nntp-outgoing; Thu, 27 Mar 1997 16:30:01 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (sob@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id QAA10187 for ; Thu, 27 Mar 1997 16:29:59 -0600 (CST) Received: (from sob@localhost) by academ.com (8.8.5/8.7.1) id QAA11691; Thu, 27 Mar 1997 16:29:46 -0600 (CST) Message-Id: <199703272229.QAA11691@academ.com> From: Stan Barber Date: Thu, 27 Mar 1997 16:29:46 CST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Chris Lewis , ietf-nntp@academ.com Subject: Re: ietf-nntp Issues with Latest extensions draft Sender: owner-ietf-nntp@academ.com Precedence: bulk INN 1.5.1 does do 480, not 380. I will revise the draft. I guess I missed that when I went though it this time. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.   Received: from cnri by ietf.org id aa17167; 27 Mar 97 17:36 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa22947; 27 Mar 97 17:36 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id QAA10131 for ietf-nntp-outgoing; Thu, 27 Mar 1997 16:13:54 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id QAA10125 for ; Thu, 27 Mar 1997 16:13:52 -0600 (CST) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by academ.com (8.8.5/8.7.1) with ESMTP id QAA11454 for ; Thu, 27 Mar 1997 16:13:50 -0600 (CST) Message-Id: <199703272213.QAA11454@academ.com> Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca) by bcarsde4.localhost; Thu, 27 Mar 1997 15:48:58 -0500 Received: from bnr.ca by bcarsfba.bnr.ca id <04474-0@bcarsfba.bnr.ca>; Thu, 27 Mar 1997 15:50:59 -0500 Date: 27 Mar 1997 15:05 EST To: ietf-nntp@academ.com From: Chris Lewis Subject: ietf-nntp BCP for RFC977 server/RFC1036 interaction Sender: owner-ietf-nntp@academ.com Precedence: bulk I'm resending this with some minor modifications from the last time (December I think). Once we have one more pass of comments, I'll try to do the formal "convert it to IETF BCP" thing. Changes marked with a "|". I've been musing on the subject, and I think the best approach for discussing how NNTP servers interact with certain news headers is to attempt to write a Best Current Practises document on the subject - as was discussed in the December WG meeting. The introduction would say something like "It is intended that this document would be superseded by a new RFC superseding RFC1036". The title would be something along the lines of "Best Current Practises regarding Usenet traceability in an NNTP environment as it pertains to Usenet news article headers". Which is quite a mouthful ;-) Note that I'm specifically not trying to stop anonymous posting from anonymizing servers. Just ensure that everything can be traced back to the originating site and the originating site's notion of user. I post this here to garner comments, but as it's been ruled off-topic for RFC977bis itself, it's probably best to keep the discussions short and sweet. Or, email me only, and I'll summarize. The rationale/FYI stuff is contained in []. Section 1 (the stuff we talked about at the BOF) is essentially one of the following three alternatives: 1) NNTP-Posting-Host: NNTP servers should place the FQDN or IP address of the originating client host in a "NNTP-Posting-Host: " header. | a) During POST, the news server should ensure that any pre-existing | NNTP-Posting-Host is correct, and if not, replace it with a correct | one. [Existing practise with current NNTP Ref and INN implementations.] 2) NNTP-Posting-User: During POST: NNTP servers using identd for user authentication should place the userid in a "NNTP-Posting-User", in addition to (1). During POST, the NNTP server should discard any pre-existing NNTP-Posting-User. [Existing practise in some identd installations I've seen.] |3) Sender: During POST: if the NNTP server performs authentication (eg: one | of the AUTHINFO variants), it should set the Sender: to a RFC-1036 | "From address format" compliant address that uniquely identifies the | originator. It is anticipated that most implementations would | insert the email address of the originator, or some | @ token which can be utilized | by the system administrator to identify the originator. | | During POST, the NNTP server should ensure, if there is a pre-existing | incorrect Sender, that it is replaced with a "correct" one. [AUTHINFO GENERIC implementations in INN and NNTP REF both do this - the authenticator modules return a generated email address from the authentication sequence. It is minimally acceptable to use the AUTHINFO USER/SIMPLE value and the NNTP server's configured domain name. Some existing configurations of NNTP (particularly NNTP reference implementations under some circumstances), will unconditionally generate a Sender of "@", where "userid" is the userid under which the NNTP software itself is running. I believe this to be wrong (as did Stan when we discussed this some time ago), and should be deprecated in favour of setting it to the authenticated address. Netcom, amongst others, are also doing this via mechanisms I presume to be non-AUTHINFO based.] Some addition[s] worth thinking about: 1) NNTP servers should provide a mechanism by which IHAVE connections which are desired to be "wild-carded" (where you allow access from non-prearranged sources) provide additional tracing information. Rather like Sendmail inserting IP addresses | in Received lines, so forged HELOs can be identified. Systems | should usually configure their feed access to only trusted peer | servers, but in some cases, opening up the server wider is desirable. | This additional tracing information can be a configurable option in | the server. Suggested behaviours during IHAVE: a) Do a reverse domain lookup, and if the name doesn't match the first element in the path, prepend the reverse domain on it before adding ones own name to the path. b) Unconditionally prepend the IP address of the connecting server before adding ones own name to the path. [UUNET is presently doing (b) - UUNET's open NNTP IHAVE port had become a spammer/forger magnet, but since (b) was implemented, the occurance of such injections has fallen off dramatically. (a) is preferred, but is quite difficult to do in some cases, and forces the reverse lookup which is undesirable in some high loading situations.] [DELETED] 2) During POST: discard any pre-existing Path:. Informational: 1) One intermediate release of NNTP ref generated "X-NNTP-Posting-Host". This should be deprecated in favour of NNTP-Posting-Host. -- Chris Lewis, Senior Network Security Analyst, Nortel. clewis@nortel.ca; Dept 4C16, Ottawa, Canada. (613) 763-2935.   Received: from cnri by ietf.org id aa10448; 28 Mar 97 15:57 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa19445; 28 Mar 97 15:57 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id OAA13384 for ietf-nntp-outgoing; Fri, 28 Mar 1997 14:52:16 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id OAA13379 for ; Fri, 28 Mar 1997 14:52:14 -0600 (CST) Received: from office.demon.net (office.demon.net [193.195.224.1]) by academ.com (8.8.5/8.7.1) with SMTP id OAA19602 for ; Fri, 28 Mar 1997 14:52:11 -0600 (CST) Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction To: Chris Lewis Date: Fri, 28 Mar 1997 20:52:09 +0000 (GMT) From: "Clive D.W. Feather" Cc: ietf-nntp@academ.com In-Reply-To: <199703272213.QAA11454@academ.com> from "Chris Lewis" at Mar 27, 97 03:05:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <859582329.2142.0@office.demon.net> Sender: owner-ietf-nntp@academ.com Precedence: bulk Chris Lewis said: > 1) NNTP-Posting-Host: NNTP servers should place the FQDN or IP address of > the originating client host in a "NNTP-Posting-Host: " > header. Can I suggest "FQDN and IP address" ? We've seen at least one case of (email) spam where the connecting machine managed to get a false FQDN into the headers (that is, a name unrelated to that anyone else gets when they look up the address that also appeared). -- Clive D.W. Feather | Director of Software Development Tel: +44 181 371 1138 | Demon Internet Ltd. Fax: +44 181 371 1037 | Work: | Home:   Received: from cnri by ietf.org id aa27196; 28 Mar 97 22:40 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa26441; 28 Mar 97 22:40 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id VAA13908 for ietf-nntp-outgoing; Fri, 28 Mar 1997 21:33:21 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id VAA13903 for ; Fri, 28 Mar 1997 21:33:18 -0600 (CST) Received: from postman.osf.org (postman.osf.org [130.105.1.152]) by academ.com (8.8.5/8.7.1) with ESMTP id VAA22488 for ; Fri, 28 Mar 1997 21:33:16 -0600 (CST) Received: from sulphur.osf.org (sulphur.osf.org [130.105.1.123]) by postman.osf.org (8.7.6/8.7.3) with ESMTP id WAA26128; Fri, 28 Mar 1997 22:32:45 -0500 (EST) Received: (from rsalz@localhost) by sulphur.osf.org (8.7.5/8.7.3) id WAA24206; Fri, 28 Mar 1997 22:32:43 -0500 (EST) Date: Fri, 28 Mar 1997 22:32:43 -0500 (EST) From: Rich Salz Message-Id: <199703290332.WAA24206@sulphur.osf.org> To: clewis@nortel.ca, clive@demon.net Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction Cc: ietf-nntp@academ.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-nntp@academ.com Precedence: bulk >Can I suggest "FQDN and IP address" ? Yuck. Hosts should do forward/backware IP/name lookups to verify Put the one you can "trust" there.   Received: from cnri by ietf.org id aa00026; 28 Mar 97 23:02 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa26790; 28 Mar 97 23:02 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id VAA14005 for ietf-nntp-outgoing; Fri, 28 Mar 1997 21:58:29 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id VAA14000 for ; Fri, 28 Mar 1997 21:58:26 -0600 (CST) Received: from fs.campus.mci.net (fs.campus.mci.net [204.71.74.16]) by academ.com (8.8.5/8.7.1) with ESMTP id VAA22532 for ; Fri, 28 Mar 1997 21:58:21 -0600 (CST) Received: from girl.campus.mci.net (girl.campus.mci.net [204.71.74.15]) by fs.campus.mci.net (8.8.5/8.8.5) with ESMTP id TAA18191; Fri, 28 Mar 1997 19:57:49 -0800 (PST) From: Kenneth Herron Received: (from kherron@localhost) by girl.campus.mci.net (8.8.5/8.8.5) id TAA00579; Fri, 28 Mar 1997 19:57:48 -0800 (PST) Date: Fri, 28 Mar 1997 19:57:48 -0800 (PST) Message-Id: <199703290357.TAA00579@girl.campus.mci.net> To: rsalz@osf.org Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction Cc: ietf-nntp@academ.com X-Sun-Charset: US-ASCII Sender: owner-ietf-nntp@academ.com Precedence: bulk >>Can I suggest "FQDN and IP address" ? > >Yuck. Hosts should do forward/backware IP/name lookups to verify > >Put the one you can "trust" there. Hmm, that would almost mandate that the one be the IP address. After all, we're talking about an authentication aid here; the bad guy could change his DNS, make his post, and change it back, for example. Considering readability, trustworthiness, and current practice, I'd lean toward NNTP-Posting-Host: hostname ([IP]) as at least a recognized--dare I say recommended?--form. (I'd probably also have put the authenticated user name in there too somewhere, instead of making a whole 'nother header for it.)   Received: from cnri by ietf.org id aa10153; 29 Mar 97 7:27 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa07166; 29 Mar 97 7:27 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id GAA16073 for ietf-nntp-outgoing; Sat, 29 Mar 1997 06:23:14 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id GAA16068 for ; Sat, 29 Mar 1997 06:23:11 -0600 (CST) Received: from postman.osf.org (postman.osf.org [130.105.1.152]) by academ.com (8.8.5/8.7.1) with ESMTP id GAA28041 for ; Sat, 29 Mar 1997 06:23:10 -0600 (CST) Received: from sulphur.osf.org (sulphur.osf.org [130.105.1.123]) by postman.osf.org (8.7.6/8.7.3) with ESMTP id HAA01913; Sat, 29 Mar 1997 07:22:31 -0500 (EST) Received: (from rsalz@localhost) by sulphur.osf.org (8.7.5/8.7.3) id HAA24912; Sat, 29 Mar 1997 07:22:29 -0500 (EST) Date: Sat, 29 Mar 1997 07:22:29 -0500 (EST) From: Rich Salz Message-Id: <199703291222.HAA24912@sulphur.osf.org> To: kherron@campus.mci.net, rsalz@osf.org Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction Cc: ietf-nntp@academ.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-nntp@academ.com Precedence: bulk >Hmm, that would almost mandate that the one be the IP address. After >all, we're talking about an authentication aid here; the bad guy could >change his DNS, make his post, and change it back, for example. Not if you do forward/backward address lookups, right? Or am I confused? /r$   Received: from cnri by ietf.org id aa10411; 29 Mar 97 7:59 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa07544; 29 Mar 97 7:59 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id GAA16194 for ietf-nntp-outgoing; Sat, 29 Mar 1997 06:55:38 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id GAA16189 for ; Sat, 29 Mar 1997 06:55:35 -0600 (CST) Received: from Twig.Rodents.Montreal.QC.CA (root@Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by academ.com (8.8.5/8.7.1) with ESMTP id GAA28085 for ; Sat, 29 Mar 1997 06:55:32 -0600 (CST) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.7.5/8.7.3) id HAA16004; Sat, 29 Mar 1997 07:55:22 -0500 (EST) Date: Sat, 29 Mar 1997 07:55:22 -0500 (EST) From: der Mouse Message-Id: <199703291255.HAA16004@Twig.Rodents.Montreal.QC.CA> To: ietf-nntp@academ.com Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction Sender: owner-ietf-nntp@academ.com Precedence: bulk >>> [use the one you can trust] >> Hmm, that would almost mandate that the one be the IP address. >> After all, we're talking about an authentication aid here; the bad >> guy could change his DNS, make his post, and change it back, for >> example. > Not if you do forward/backward address lookups, right? Not until dnssec is widely enough deployed that one can be certain the forward DNS lookup hasn't hit a server the attacker managed to confuse (eg, force trash into the cache of), and perhaps not even then - prima facie, the IP address itself is more trustworthy than anything derived therefrom. Personally, I would prefer to see both the original IP address and the name it mapped into at the time (which is not necessarily the name it maps into now, even aside from DNS-corrupting attacks). der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B   Received: from cnri by ietf.org id aa08732; 30 Mar 97 6:55 EST Received: from ANNOUNCER.ACADEM.COM by CNRI.Reston.VA.US id aa06756; 30 Mar 97 6:55 EST Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.7.3) id FAA18792 for ietf-nntp-outgoing; Sun, 30 Mar 1997 05:49:38 -0600 (CST) X-Authentication-Warning: announcer.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.7.3) with ESMTP id FAA18787 for ; Sun, 30 Mar 1997 05:49:35 -0600 (CST) Received: from office.demon.net (office.demon.net [193.195.224.1]) by academ.com (8.8.5/8.7.1) with SMTP id FAA09016 for ; Sun, 30 Mar 1997 05:49:29 -0600 (CST) Subject: Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction To: der Mouse Date: Sun, 30 Mar 1997 12:49:21 +0100 (BST) From: "Clive D.W. Feather" Cc: ietf-nntp@academ.com In-Reply-To: <199703291255.HAA16004@Twig.Rodents.Montreal.QC.CA> from "der Mouse" at Mar 29, 97 07:55:22 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <859722561.21208.0@office.demon.net> Sender: owner-ietf-nntp@academ.com Precedence: bulk der Mouse said: > Personally, I would prefer to see both the original IP address and the > name it mapped into at the time (which is not necessarily the name it > maps into now, even aside from DNS-corrupting attacks). Indeed. -- Clive D.W. Feather | Director of Software Development Tel: +44 181 371 1138 | Demon Internet Ltd. Fax: +44 181 371 1037 | Work: | Home: