enger@seka.scc.com (Robert M. Enger) (06/10/91)
Hi: I found that my site is having difficulty handling a strange message-id that contains TWO '@' characters. (At least I think that's what's upsetting it!) We apparently received and correctly processed the article about two days ago. Today, a different site has been attempting to send us the article over and over and over again. They are sending it to us MULTIPLE times per NNTP session, and They are sending it to us in SUCCESSIVE NNTP sessions! One problem this evidences is obvious: My NNTPD isn't telling the sending end that we already have the article in the database. (see output at bottom) I believe it indicates a second problem: How can the other site be offering me the same message MULTIPLE times in the same nntp session? I am accepting each transfer successfully each time, so the sender can't be retrying because he detected an error from me. The sender's software must somehow be destabilized by this wierd message ID (or whatever the problem really is) too! Below is some data for your consideration. It shows the offending Message-ID, as well as evidence that the message exists in my database already, and that the NNTPD does not believe that the message is already in my database. I am running C-News and NNTP version 1.5.11 on an old Encore Multimax 310. Any guidance on how to patch things so that my site correctly handles this message ID would be greatly appreciated. If this is some old problem that is well known to others I appologize in advance for taking up everyone's time. Thanks in advance, Bob The OFFENDING message ID: <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> OUTPUT of Database query using NEWSHIST (shows message-id IS in the Database): <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> 676309800~- misc.forsale.computers/12316 Response from NNTPD to Article command (shows that NNTPD has made a mistake): 430 No article by message-id <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu>, sorry. LOG of (apparently destabilized) NNTP peer repeatedly giving me same article. (Actually its a log of the very astute CNEWS discarding the bogus duplicates that NNTPD has repeatedly accepted and queued for processing by Newsrun!): Jun 9 06:11:41.771 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:41.829 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:41.864 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:41.900 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:41.976 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:42.015 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:42.050 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:42.086 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:42.125 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:42.164 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.729 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.787 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.829 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.865 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.934 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:52.970 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:53.005 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:53.042 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:53.077 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:11:53.115 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:02.955 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.013 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.051 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.088 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.173 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.210 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.246 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.284 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.326 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:03.362 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.248 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.312 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.347 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.387 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.464 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.503 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.540 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.576 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.616 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:14.654 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.190 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.250 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.286 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.322 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.363 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.401 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.438 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.477 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.515 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:25.551 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:35.949 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.009 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.048 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.086 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.127 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.164 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.199 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.237 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.278 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:36.313 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:47.860 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:47.918 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.593 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.675 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.712 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.750 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.787 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 06:12:49.827 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.268 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.327 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.362 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.398 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.468 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.506 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.543 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.580 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.622 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:42.661 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.333 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.390 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.426 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.462 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.505 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.541 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.580 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.617 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.657 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:11:52.696 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.002 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.061 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.104 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.141 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.183 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.220 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.257 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.297 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.340 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:03.376 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:14.829 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:14.890 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:14.927 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:14.965 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.046 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.086 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.122 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.159 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.276 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:15.320 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.138 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.201 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.237 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.272 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.312 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.350 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.387 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.423 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.461 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:25.499 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:34.917 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:34.978 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.016 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.055 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.097 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.134 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.172 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.210 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.251 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:35.288 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:43.370 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 07:12:43.429 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.172 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.237 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.273 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.310 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.350 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.390 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.426 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.462 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.502 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:11:50.537 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.682 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.739 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.777 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.813 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.861 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.896 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.933 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:00.970 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:01.013 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:01.052 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.396 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.454 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.490 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.526 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.600 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.643 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.679 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.716 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.753 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:17.795 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.105 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.163 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.199 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.237 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.304 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.340 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.376 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.412 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 08:12:19.456 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.564 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.647 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.716 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.753 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.795 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.842 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.878 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.916 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.956 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:40.993 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.460 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.519 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.559 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.595 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.636 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.673 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.711 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.764 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.806 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:11:51.846 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.616 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.676 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.713 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.750 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.831 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.875 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.912 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.951 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:02.994 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:03.032 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:06.986 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.045 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.082 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.120 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.180 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.223 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.262 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.298 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.338 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:07.377 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.341 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.399 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.436 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.478 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.556 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.593 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.630 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 09:12:12.668 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.414 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.496 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.536 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.582 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.628 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.679 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.718 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.759 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.820 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:38.859 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.570 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.629 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.666 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.703 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.744 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.782 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.818 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.856 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.895 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:48.933 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.648 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.706 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.743 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.780 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.822 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.858 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.894 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.931 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:58.967 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:11:59.007 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:10.974 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.034 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.071 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.108 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.149 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.186 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.229 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.265 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.305 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:11.342 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.016 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.075 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.113 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.150 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.192 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.228 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.265 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.326 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:21.362 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:29.941 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:30.001 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:30.040 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:30.078 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:30.126 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 10:12:30.164 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.247 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.306 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.342 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.379 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.421 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.458 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.495 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.537 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.576 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:40.612 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.291 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.357 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.395 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.432 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.474 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.512 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.565 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.607 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:11:53.645 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.300 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.358 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.395 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.432 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.474 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.516 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.553 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.590 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.631 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:05.667 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.561 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.619 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.657 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.694 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.736 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.773 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.810 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.848 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.888 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:16.926 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.018 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.078 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.114 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.152 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.194 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.231 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.267 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.305 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.346 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:28.383 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.032 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.096 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.133 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.171 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.214 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.258 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.297 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.335 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:39.375 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:46.166 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:46.225 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 11:12:46.263 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.381 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.444 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.480 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.517 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.559 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.596 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.633 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.670 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.710 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:40.748 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.441 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.499 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.538 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.575 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.617 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.655 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.693 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.731 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.772 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:11:50.811 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.196 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.255 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.293 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.330 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.372 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.409 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.446 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.483 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:00.525 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.159 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.219 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.257 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.295 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.337 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.375 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.413 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.475 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:12.513 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.385 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.443 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.482 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.519 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.561 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.599 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.637 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.676 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.717 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:22.755 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:40.900 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:40.960 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:40.997 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:41.040 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:41.081 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:41.135 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:41.172 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:41.214 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:50.811 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:50.869 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:50.907 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:50.944 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:50.985 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:51.024 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:51.061 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:51.120 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:12:51.156 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:02.851 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:02.912 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:02.950 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:02.988 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.030 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.069 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.107 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.145 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.186 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:03.224 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:23.885 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:23.946 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:23.983 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.020 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.101 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.139 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.176 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.214 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.255 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:24.293 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:33.544 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:33.582 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:33.620 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 12:13:33.661 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.220 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.279 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.319 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.357 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.473 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.511 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.550 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.590 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:44.630 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:55.913 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:55.998 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:56.113 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:56.167 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:56.209 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:11:56.247 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.313 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.354 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.392 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.464 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.501 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.539 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.577 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:16.636 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.156 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.195 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.254 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.291 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.328 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.366 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.407 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:28.443 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.634 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.689 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.768 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.806 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.860 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:41.901 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.378 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.443 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.481 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.556 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.611 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:12:54.652 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.531 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.592 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.629 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.667 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.731 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.769 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.807 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.849 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:17.887 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 13:13:25.756 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 14:11:46.221 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 14:11:46.260 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 14:11:46.353 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 14:12:00.834 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate Jun 9 14:12:01.055 noc.sura.net - <HOLMES@NEFX4.91Jun7101949@nefx4.ncsuvx.ncsu.edu> duplicate -- Robert M. Enger CONTEL Federal Systems enger@seka.scc.com (Internet)
sob@tmc.edu (Stan Barber) (06/10/91)
In article <1991Jun9.232828.17956@europa.asd.contel.com> enger@seka.scc.com writes: >I found that my site is having difficulty handling a strange message-id that >contains TWO '@' characters. (At least I think that's what's upsetting it!) Any message id with two '@'s in it is illegal. NNTP 1.5 does not process illegal messages ids very well. >We apparently received and correctly processed the article about two days ago. One might argue that if Cnews throws away articles with bad dates, why doesn't it throw away articles with bad Message-ids? >Today, a different site has been attempting to send us the article over >and over and over again. This must be a bug in the sending software. Since nntpxmit and nntplink are the most common, I have looked at nntpxmit and find that if installed as shipped, it only cares the if the message-id has angle brackets around it. >Any guidance on how to patch things so that my site correctly handles this >message ID would be greatly appreciated. If this is some old problem that >is well known to others I appologize in advance for taking up everyone's time. I will add it to the bug list for consideration in the next release of NNTP. I would like to hear if the CNEWS guys have a response to my question posed above since that would also address the problem. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
enger@seka.scc.com (Robert M. Enger) (06/10/91)
Hi Stan: Thanks for responding to my call for help/guidance. I too took a look at the code, but at the NNTPD server. I can't figure out WHY it does not recognize the fact that the 'bogus' message id is ALREADY in the database. NNTPD correctly looks for the LAST '@' in the string, and lower-cases what is after it, etc. This looks like good behavior. I could not spot any string variables which were ripe to overflow, etc. Any ideas why it doesn't work right? The only difference I could spot was that NNTPD used 'fetch' to access the data base, while NEWSHIST ultimately called dbzfetch. Do these behave differently under this 'unusual' circumstance? Thanks again for responding. Bob ps Is there someone responsible for notifying the offending site that they are generating bad message-id fields? -- Robert M. Enger CONTEL Federal Systems enger@seka.scc.com (Internet)
ronald@robobar.co.uk (Ronald S H Khoo) (06/11/91)
sob@tmc.edu (Stan Barber) writes: > One might argue that if Cnews throws away articles with bad dates, why doesn't > it throw away articles with bad Message-ids? It should. I'd hazard a guess that the reason it doesn't already do so is simply because Zmailer doesn't choke on two '@'s in a message-id. But that's a guess. If you can show that this particular violation of the RFC's breaks an existing installed software base, I would urge the C News maintainers to drop these too. And while I'm here, I'm going to mount my soapbox. .nntp readers can leave here. Followups are redirected to .software.b. In this current storm, mostly stirred by Sean "mathew" Murphy @ mantis.co.uk, people seem to have forgotten that all this article dropping isn't Henry's idea anyway. In fact, Henry's well on record for opposing the "guerilla tactics" of deliberately being cruel to force people to get their software up to scratch. I have to disagree with that point of view. The truth of the matter is that only squeaking wheels get fixed. Henry knows this, he's just too soft. (:-) At the end of the day, networking is about getting stuff implemented from all different directions to talk to each other. You can't do this without adhering to standards. While software should be lenient in accepting non-conformant rubbish, the other half of that maxim says that it must not let that stuff escape out. That's the "conservative in what you generate" half. Current C News software does this. The error reporting may not be all things to all men, but it's good enough. I don't really want to spend lots of cpu time picking up the the rubbish left behind by non-conformant software -- that would be ridiculous. Why should I suffer for their errors ? You can't network in a vacuum either. To those who complained about Henry's warnings being not sufficiently loud, I have only this to say: If you're maintaining or writing software that interoperates with B News, you're problems have only just started if you don't subscribe to news.software.b. This is (IMHO) the paramount reason for not splitting off news.software.c. Maintainers of systems, and implementers of the software need to know what each other are doing, hence both need to read news.software.b and news.admin. Both groups have a reasonably good signal to noise ratio if you put /@mantis.co.uk/h:j into your kill file. All the current furore serves to do is waste the precious time of Henry Spencer. Many of us are waiting for time when he can put down this C News project and go back to the things he's left behind -- like the superfast string library. I wish I could put that above-mentioned line into Henry's Kill file for him. Anyway, it's time for bed. flames > /dev/null please. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
henry@zoo.toronto.edu (Henry Spencer) (06/13/91)
In article <5930@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >One might argue that if Cnews throws away articles with bad dates, why doesn't >it throw away articles with bad Message-ids? What is a "bad" message ID? RFC1036 does not outlaw multiple @s, although it warns you that RFC822 does. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/13/91)
In article <1991Jun10.164931.21555@europa.asd.contel.com> enger@seka.scc.com writes: >NNTPD correctly looks for the LAST '@' in the string, and lower-cases >what is after it, etc. This looks like good behavior. >I could not spot any string variables which were ripe to overflow, etc. >Any ideas why it doesn't work right? Probably nntpd and dbz are in disagreement on the case mapping. This sort of problem is why dbz provides interfaces (dbzfetch and dbzstore) which do *all* the case mapping internally, so the client never has to worry about how to do it. Nntpd with CNEWS defined really ought to be using those, not the old dbm interface. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
sob@tmc.edu (Stan Barber) (06/15/91)
In article <1991Jun13.043253.20660@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <5930@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >What is a "bad" message ID? RFC1036 does not outlaw multiple @s, although >it warns you that RFC822 does. Hmmm. As I read RFC1036, it follows RFC822/1123 for all headers defined in those documents and sets standards for those headers not defined in RFC822/1123. To me, that means that a Date field that does not conform to RFC823/1123, it is illegal. You and Geoff seem to agree with that. Now, we have Messages IDs that don't conform and you say that that is ok despite what RFC822/1123 say. Does this mean we need a new RFC that sez which RFC822/1123 fields we will follow as defines and which we won't? Here is some quotes from the RFC1036. [From the introduction....] The primary consideration in choosing a message format is that it fit in with existing tools as well as possible. Existing tools include implementations of both mail and news. (The notesfiles system from the University of Illinois is considered a news implementation.) A standard format for mail messages has existed for many years on the Internet, and this format meets most of the needs of USENET. Since the Internet format is extensible, extensions to meet the additional needs of USENET are easily made within the Internet standard. Therefore, the rule is adopted that all USENET news messages must be formatted as valid Internet mail messages, according to the Internet standard RFC-822. The USENET News standard is more restrictive than the Internet standard, placing additional requirements on each message and forbidding use of certain Internet features. However, it should always be possible to use a tool expecting an Internet message to process a news message. In any situation where this standard conflicts with the Internet standard, RFC-822 should be considered correct and this standard in error. 2.1.5. Message-ID The "Message-ID" line gives the message a unique identifier. The Message-ID may not be reused during the lifetime of any previous message with the same Message-ID. (It is recommended that no Message-ID be reused for at least two years.) Message-ID's have the syntax: <string not containing blank or ">"> In order to conform to RFC-822, the Message-ID must have the format: <unique@full_domain_name> where full_domain_name is the full name of the host at which the message entered the network, including a domain that host is in, and unique is any string of printing ASCII characters, not including "<" (left angle bracket), ">" (right angle bracket), or "@" (at sign). For example, the unique part could be an integer representing a sequence number for messages submitted to the network, or a short string derived from the date and time the message was created. For example, a valid Message-ID for a message submitted from host ucbvax in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>". Programmers are urged not to make assumptions about the content of Message-ID fields from other hosts, but to treat them as unknown character strings. It is not safe, for example, to assume that a Message-ID will be under 14 characters, that it is unique in the first 14 characters, nor that is does not contain a "/". The angle brackets are considered part of the Message-ID. Thus, in references to the Message-ID, such as the ihave/sendme and cancel control messages, the angle brackets are included. White space characters (e.g., blank and tab) are not allowed in a Message-ID. Slashes ("/") are strongly discouraged. All characters between the angle brackets must be printing ASCII characters. This sez to me that in all cases RFC822/1123 definitions hold, even if they conflict with RFC1036. If this is true and CNEWS does not police this, like it does the Date: header, then CNEWS is doing the wrong thing as defined by the appropriate RFCs. NNTP is assuming that RFC822 conforming messages ids are the only ones in valid articles. While this assumption SHOULD be valid, it is not. This will be addressed in NNTP 1.6. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
nntp@tmc.edu (06/15/91)
In article <1991Jun13.043555.20773@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Probably nntpd and dbz are in disagreement on the case mapping. This sort >of problem is why dbz provides interfaces (dbzfetch and dbzstore) which do >*all* the case mapping internally, so the client never has to worry about >how to do it. Nntpd with CNEWS defined really ought to be using those, >not the old dbm interface. This will be done in NNTP 1.6 and conditionalized on the use of dbz, not CNEWS unless the same interface is use regarless of the dbm approach used by the installer of the cnews at the site. Please let me know if dbzfetch/dbzstore (NNTP only need dbzfetch) is specific to dbz or just a badly-named front-end to whichever dbm the installer uses.
eggert@twinsun.com (Paul Eggert) (06/16/91)
sob@tmc.edu (Stan Barber) writes: >As I read RFC1036, it follows RFC822/1123 for all headers defined in >those documents and sets standards for those headers not defined in >RFC822/1123. To me, that means that a Date field that does not conform to >RFC823/1123, it is illegal. You and Geoff seem to agree with that. Now, >we have Messages IDs that don't conform and you say that that is ok >despite what RFC822/1123 say. C News needn't discard _incoming_ articles with nonconforming Message-IDs; it is allowed to, but it doesn't have to. However, it must _generate_ articles with conforming Message-IDs. Unfortunately, C News's policy of passing through headers unaltered means that, if it wants to conform to the RFCs, it must check that incoming headers strictly conform to the RFCs before passing them through to the next news host. Instead of ``be generous in what you accept and strict in what you produce'', C News must be strict in what it accepts because it mustn't pass through bad headers. In practice, C News isn't this strict, accepts and passes through mistakes like Message-IDs with two `@'s, and therefore doesn't conform strictly with the RFCs. I suspect there are several reasons for this: The RFCs are too complicated. Making C News strict would cause even more of an uproar than the recently added loose header checking. Being strict would make C News a little less efficient. Which is more important, obeying the RFCs precisely, or transporting news effectively? The lessons for NNTPD should be clear (:-).
sef@kithrup.COM (Sean Eric Fagan) (06/16/91)
In article <6014@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: > In order to conform to RFC-822, the Message-ID must have the format: Is it the intenet of this section of the RFC to mean that a Message-ID *must* conform to RFC-822? To me, it is ambiguous: it can mean that this section of the header need not conform to 822, but if you want it to, it should do <this> (which I deleted). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sob@tmc.edu (Stan Barber) (06/17/91)
In article <1991Jun15.212751.1558@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >C News needn't discard _incoming_ articles with nonconforming >Message-IDs; it is allowed to, but it doesn't have to. However, it >must _generate_ articles with conforming Message-IDs. This is inconsistant. If CNEWS is discarding articles with bad dates (and those articles are being discarded during RELAY, not when first posted), then it should do that for all headers. It has already been stated by others that CNEWS will gladly generate bad Messages-IDs if improperly installed. I think most any news software (transports or posters) can do this. There must be some software that checks to be sure that the Message-ID is valid. Some have suggested that inews is the right place (when the article is first posted). I agree with this. However, not every news transport (anu-news, various MS-DOS systems, ATARI systems, etc) may be totally compliant (witness the messages involving "Give CNEWS a *HUG*"/"CNEWS MUST DIE"). This means more checking is necessary. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
sob@tmc.edu (Stan Barber) (06/17/91)
In article <1991Jun16.063341.13609@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Is it the intenet of this section of the RFC to mean that a Message-ID >*must* conform to RFC-822? To me, it is ambiguous: it can mean that this >section of the header need not conform to 822, but if you want it to, it >should do <this> (which I deleted). I take the meaning of the RFC as a whole and avoid looking at a section all by itself. I believe the intent of the RFC is as is stated in the opening section where it plainly sez that if this RFC disagrees with RFC 822, RFC 822 (as modified by RFC 1123) is correct. It even goes on to say that it is more restrictive than RFC 822. It makes no sense to me to assume that an RFC would define a field to be less restrictive than the definition in another RFC claimed to be less restrictive. I believe the section on the Message-ID was placed there to insure that writers of news software would know that Message-IDs could be of any length and always had angle brackets around them. It is not an attempt by the RFC to set a NEW standard for Message-IDs, but rather to document usage of the field at the time the RFC was written. As an aside, I would note that BNEWS always uses the <number@site> format for any articles it adds message-ids to when those articles are first posted. If "site" is a valid domain name (.UUCP notwithstanding), then it is a valid message-id. BNEWS doesn't allow this format to be altered unless you alter the source code itself. CNEWS provides a shell script the generates the message-id. I believe that many people have decided to alter the format of the standard CNEWS message-id because it's pretty easy to hack on shell scripts. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
eggert@twinsun.com (Paul Eggert) (06/17/91)
sob@tmc.edu (Stan Barber) writes: >This is inconsistant. If CNEWS is discarding articles with bad dates ... >then it should do that for all headers. Actually, C News is consistent in not checking for complete RFC conformance. It doesn't check _dates_ completely either; e.g. it accepts nonconforming dates like `Sonntag, 16 Jun 91 22:47:05 GMT'. It would be tricky and a little expensive for C News to check for complete conformance to the RFCs, because the rules are so convoluted. C News does the checking that's cheap and easy, and doesn't bother with the rest. Alas, this means C News can output a non-RFC-conforming article that was originally posted from another host.
henry@zoo.toronto.edu (Henry Spencer) (06/18/91)
In article <6020@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>C News needn't discard _incoming_ articles with nonconforming >>Message-IDs; it is allowed to, but it doesn't have to. However, it >>must _generate_ articles with conforming Message-IDs. >This is inconsistant. If CNEWS is discarding articles with bad dates >(and those articles are being discarded during RELAY, not when first >posted), then it should do that for all headers. C News doesn't do 100% RFC822/1036 header enforcement because that is complex and time-consuming and unnecessary. We generally enforce only those restrictions that appear to be necessary for some specific reason. (In the case of dates, it is essential to have a parsable date to avoid recirculation of stale news.) We are somewhat reluctant to tighten up checking just because somebody else's software is breaking -- we tend to feel that this is the breakee's problem -- although we have done so on occasion. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/18/91)
In article <6014@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>What is a "bad" message ID? RFC1036 does not outlaw multiple @s, although >>it warns you that RFC822 does. > >Hmmm. As I read RFC1036, it follows RFC822/1123 for all headers defined in >those documents and sets standards for those headers not defined in >RFC822/1123. To me, that means that a Date field that does not conform to >RFC823/1123, it is illegal. You and Geoff seem to agree with that. Now, >we have Messages IDs that don't conform and you say that that is ok >despite what RFC822/1123 say. The problem here is that the relationship between 1036 and 822 is confused and ambiguous. 1036 does *not* "follow 822/1123 for all headers defined in those documents"; it often tightens up the rules in one way or another. A superficial reading of 1036's comments on message IDs suggests a loosening of rules, although this is arguably contradicted by the phrasing about news articles conforming to 822. I'm not saying that "this is ok"; I'm saying that it is not entirely clear that it is *not* ok, because it's less than crystal clear just whose rules apply. This is not a final exam. It is proper, indeed desirable, to admit that there is insufficient information for a definitive answer. >Does this mean we need a new RFC that sez which RFC822/1123 fields we will >follow as defines and which we won't? No, we need some clarifications in 1036 about its relationship to 822. Plus preferably a tightening-up of its spec for message IDs so that they are clearly a subset of the 822 ones. (We don't want full 822 message IDs, including obscenities like quoted white space, to be legal in news... if only because most news systems have never accepted them.) -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/18/91)
In article <5120@lib.tmc.edu> nntp@tmc.edu writes: >>... dbz provides interfaces (dbzfetch and dbzstore) which do >>*all* the case mapping internally, so the client never has to worry about >>how to do it. Nntpd with CNEWS defined really ought to be using those... > >This will be done in NNTP 1.6 and conditionalized on the use of dbz, not >CNEWS ... Good point. The old version of dbz didn't provide them, but it should by now be thoroughly obsolete -- it had a lot of problems -- and I would say it need not be considered. >Please let me know if dbzfetch/dbzstore (NNTP only need dbzfetch) is >specific to dbz or just a badly-named front-end to whichever dbm the >installer uses. dbzfetch and dbzstore are original with my improved dbz, although C News does include a compatibility package that provides them as wrappers for other dbm implementations. (That was done so that our code could always use the same interface; we dislike #ifdef.) Arguably the most correct behavior would be to use them when using *either* dbz or C News. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/18/91)
In article <6021@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >... I believe that many people have decided to >alter the format of the standard CNEWS message-id because it's pretty >easy to hack on shell scripts. Actually, the consistency between Rick Adams's "version" control-message census and our statistics based on message-ID format strongly suggests that very few people have in fact hacked the ID format. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
eggert@twinsun.com (Paul Eggert) (06/18/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >A superficial reading of 1036's comments on message IDs suggests a loosening >of rules, although this is arguably contradicted by the phrasing about news >articles conforming to 822. Perhaps a superficial reading of 1036 suggests looser rules, but Stan Barber's more careful reading is the only supportable one. RFC 1036 emphatically states that every article must conform to RFC 822, and justifies this restriction at length. Although it's a natural mistake to not know that section 2.1.5 of RFC 1036 does not exempt an article from the overall RFC 822 requirement, this mistake deserves no more sympathy than the even more natural mistake of not knowing that RFC 822 is amended by RFC 1123. >(We don't want full 822 message IDs, >including obscenities like quoted white space, to be legal in news... if >only because most news systems have never accepted them.) Fortunately, we don't have to worry about this: RFC 1036 section 2.1.5 clearly allows only non-white-space, printing ASCII characters in a conforming Usenet Message-ID.
sob@tmc.edu (Stan Barber) (06/18/91)
In article <1991Jun17.191642.27639@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >C News doesn't do 100% RFC822/1036 header enforcement because that is >complex and time-consuming and unnecessary. We generally enforce only >those restrictions that appear to be necessary for some specific reason. >(In the case of dates, it is essential to have a parsable date to avoid >recirculation of stale news.) We are somewhat reluctant to tighten up >checking just because somebody else's software is breaking -- we tend >to feel that this is the breakee's problem -- although we have done so >on occasion. I see. I guess this means that badly installed CNEWS sites are no cause for concern. It is interesting to hear that a CNEWS author considers to be irrelevant if implementing the standard is too hard or too complex. However, I do believe we now have seen a case where it is necessary. There is news posting software out there that generates bad message-ids. This should be stopped by the news transport software. Otherwise, USENET will eventually stop transporting some news....Ummm. Actually, I guess this has already happened. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
sob@tmc.edu (Stan Barber) (06/18/91)
In article <1991Jun17.192620.27934@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >The problem here is that the relationship between 1036 and 822 is confused >and ambiguous. 1036 does *not* "follow 822/1123 for all headers defined >in those documents"; it often tightens up the rules in one way or another. >A superficial reading of 1036's comments on message IDs suggests a loosening >of rules, although this is arguably contradicted by the phrasing about news >articles conforming to 822. I'm not saying that "this is ok"; I'm saying >that it is not entirely clear that it is *not* ok, because it's less than >crystal clear just whose rules apply. I very much disagree. RFC1036 CLEARLY says that where RFC1036 and RFC822 differ, RFC822 is taken to be correct. I don't believe that this is can be debated to any person who reads the RFC and does not try to read something into it. When you and Geoff wrote Cnews, you claimed to following RFC1036. Obviously, you followed YOUR interpretation of RFC1036. I am saying that interpretation is flawed. You can believe that mine is. I am willing to cope with software that does not conform to my interepretation of RFC1036. You stand firm on what you believe it sez. Sounds like a good approach to interoperability to me. (sarcasm in previous sentence....) >Stan Barber wrote.... >>Does this mean we need a new RFC that sez which RFC822/1123 fields we will >>follow as defines and which we won't? > >No, we need some clarifications in 1036 about its relationship to 822. Plus >preferably a tightening-up of its spec for message IDs so that they are >clearly a subset of the 822 ones. (We don't want full 822 message IDs, >including obscenities like quoted white space, to be legal in news... if >only because most news systems have never accepted them.) I think you mean the answer is really YES. You say "NO" and then go on to state that we need some clarification. How does this community clarify things? Urban Myths? Certainly, the various software implementing news transports are in disagreement about this, so that is no valid source of clarity unless it is something like an RFC. Please, what do you propose to do to insure clarity? -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <6038@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>C News doesn't do 100% RFC822/1036 header enforcement because that is >>complex and time-consuming and unnecessary. We generally enforce only >>those restrictions that appear to be necessary for some specific reason. >... >I guess this means that badly installed CNEWS sites are no cause for >concern. I'd be interested to know how you reached that conclusion from what I said. I plan to tighten up build's checking on site names and such, and fussier checking of message IDs will at least be considered. >It is interesting to hear that a CNEWS author considers to be irrelevant >if implementing the standard is too hard or too complex. If you have a fast, small, easy-to-use parser for full RFC822, Geoff would love to hear from you. We do not consider the standard "irrelevant", we consider it "expensive", and prefer to avoid implementing features that contribute nothing to the functioning of a news system except slowness. This does mean that we occasionally have cause to revise our opinion of some feature, when it turns out that its lack causes problems. >However, I do believe we now have seen a case where it is necessary. >There is news posting software out there that generates bad message-ids. >This should be stopped by the news transport software. I am inclined to agree, although I would like to see a concise description of *exactly* what restrictions should be enforced, since full 822 parsing is ridiculously complex and expensive and appears to be overkill. If it's just the absence of multiple @s, that ought to be feasible. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <6039@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>... it is not entirely clear that it is *not* ok, because it's less than >>crystal clear just whose rules apply. >I very much disagree. RFC1036 CLEARLY says that where RFC1036 and RFC822 >differ, RFC822 is taken to be correct. I don't believe that this is >can be debated ... It can't be debated, but it is nonsensical. 1036 explicitly differs from 822 on a number of points; that statement *has* to be read with a different meaning than its literal one. The most plausible interpretation is that 822 dominates *except* where 1036 is imposing additional restrictions -- so that 1036 can stiffen but not relax 822 rules -- but the standard does *not* say that and the matter cannot be resolved merely by pointing to the existing wording. 1036 contradicts itself, and just how you resolve the contradiction matters. >>>Does this mean we need a new RFC that sez which RFC822/1123 fields we will >>>follow as defines and which we won't? >> >>No, we need some clarifications in 1036 about its relationship to 822. Plus >>preferably a tightening-up of its spec for message IDs ... > >I think you mean the answer is really YES. You say "NO" and then go on to >state that we need some clarification. How does this community clarify things? In this case, by revising an old RFC rather than writing a new one. The existing document does precisely what you were suggesting, i.e. amends 822 for purposes of news rather than mail, it just doesn't do it clearly and precisely enough to resolve some issues without guesswork and appeals to what someone thinks the authors probably meant. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
sob@lib.tmc.edu (Stan Barber) (06/19/91)
In article <1991Jun17.193252.28272@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Actually, the consistency between Rick Adams's "version" control-message >census and our statistics based on message-ID format strongly suggests >that very few people have in fact hacked the ID format. Okey. Let's look at the following article. My comments are in square brackets. ---------------------------------------------------------------------------- From: eggert@twinsun.com (Paul Eggert) Newsgroups: news.admin,news.software.b Subject: Recently observed nonconforming Message-IDs (discussion) Message-ID: <1991Jun12.071111.29652@twinsun.com> Date: 12 Jun 1991 07:11:11 GMT Sender: usenet@twinsun.com Organization: Twin Sun, Inc Lines: 79 Xref: lib news.admin:12899 news.software.b:6601 Nntp-Posting-Host: twinsun [first paragraph deleted] I looked at a sample news history file containing 63381 recent Usenet Message-IDs, and found 388 nonconforming Message-IDs. Here is a table of reasons for lack of conformance, together with the number of corresponding Message-IDs. #articles conformance problem, and example nonconforming Message-ID 217 The local-part may not contain an unquoted `:'. <17169:Jun1122:04:5791@kramden.acf.nyu.edu> [This looks like it might have been a CNEWS message id.] 47 A domain may not end with `.'. <25590171@hpcvra.cv.hp.com.> [This looks like it might be bnews or notes. Since it is hp, it is probably notes.] 42 A domain may not begin with `.'. <9106052317.AA01532@.devon.prepnet.com> [Looks like something sendmail might generate.] 36 A Message-ID cannot contain two unquoted `@'s. <1991Jun6.165406.70@%boot.decnet@edwards-tems.af.mil> [Looks like CNEWS again.] 32 The local-part may not end with `.'. <k#mh7z.@rpi.edu> [Hard to know here.....] 22 The local-part may not begin with `.'. <.+9+WD_@cs.widener.edu> [Ditto] 17 Two adjacent unquoted `.'s may not appear in a Message-ID. <9105211421.AA10695@mailserv.zdv.uni-tuebingen..de> [Looks like sendmail....] 12 The domain may not be empty. <1991Jun5.192745.1945@> [Looks like CNEWS....] 2 The local-part may not contain an unquoted `]'. <]ocdj2.cj7@cat.de> [Can't guess.] 2 Quotes must match. <"<9105141856.AA26881@cnmus.cnm.us.es> [Sendmail?] ---------------------------------------------------------------------------- Out of the 10 given in the article, four look like Cnews. That a pretty big percentage, but 10 is small. Perhaps, only four people either didn't know how to install Cnews properly or just didn't want to generate legal Message-ids. It is interesting to note that none of them were generated by bnews. Unless that hp site was running bnews.
sob@lib.tmc.edu (Stan Barber) (06/19/91)
In article <1991Jun18.191531.10098@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >I plan to tighten up build's checking on site names and such, and fussier >checking of message IDs will at least be considered. Excellent. In the meantime, I have asked a group of NNTP managers to test a fix for NNTP to cope with the problem. I hope that means that everyone wins. >This does mean that we occasionally have cause to revise our opinion of >some feature, when it turns out that its lack causes problems. Excellent. I am happy to see that you are willing to reexamine your opinions. I frequently came away with a belief that you were unwilling to consider the possibility of being incorrect on some issue. >I would like to see a concise description of *exactly* what restrictions >should be enforced, since full 822 parsing is ridiculously complex and >expensive and appears to be overkill. If it's just the absence of multiple >@s, that ought to be feasible. Perhaps this should be the subject of a revision of RFC1036 you proposed. At the very least, only one @ should be allowed. How would you like to proceed?
sob@lib.tmc.edu (Stan Barber) (06/19/91)
Then let's revise RFC1036 then. Who wants to contact the IAB?
brendan@cs.widener.edu (Brendan Kehoe) (06/19/91)
sob@lib.tmc.edu wrote: >In article <1991Jun17.193252.28272@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >>Actually, the consistency between Rick Adams's "version" control-message >>census and our statistics based on message-ID format strongly suggests >>that very few people have in fact hacked the ID format. > >Okey. Let's look at the following article. >My comments are in square brackets. >---------------------------------------------------------------------------- >From: eggert@twinsun.com (Paul Eggert) >Newsgroups: news.admin,news.software.b >Subject: Recently observed nonconforming Message-IDs (discussion) >Message-ID: <1991Jun12.071111.29652@twinsun.com> >Date: 12 Jun 1991 07:11:11 GMT >Sender: usenet@twinsun.com >Organization: Twin Sun, Inc >Lines: 79 >Xref: lib news.admin:12899 news.software.b:6601 >Nntp-Posting-Host: twinsun > >[first paragraph deleted] > >I looked at a sample news history file containing 63381 recent Usenet >Message-IDs, and found 388 nonconforming Message-IDs. Here is a table >of reasons for lack of conformance, together with the number of >corresponding Message-IDs. > >#articles conformance problem, and example nonconforming Message-ID > > 217 The local-part may not contain an unquoted `:'. > <17169:Jun1122:04:5791@kramden.acf.nyu.edu> >[This looks like it might have been a CNEWS message id.] > 47 A domain may not end with `.'. > <25590171@hpcvra.cv.hp.com.> >[This looks like it might be bnews or notes. Since it is hp, it is >probably notes.] > 42 A domain may not begin with `.'. > <9106052317.AA01532@.devon.prepnet.com> >[Looks like something sendmail might generate.] > 36 A Message-ID cannot contain two unquoted `@'s. > <1991Jun6.165406.70@%boot.decnet@edwards-tems.af.mil> >[Looks like CNEWS again.] > 32 The local-part may not end with `.'. > <k#mh7z.@rpi.edu> >[Hard to know here.....] > 22 The local-part may not begin with `.'. > <.+9+WD_@cs.widener.edu> >[Ditto] > 17 Two adjacent unquoted `.'s may not appear in a Message-ID. > <9105211421.AA10695@mailserv.zdv.uni-tuebingen..de> >[Looks like sendmail....] > 12 The domain may not be empty. > <1991Jun5.192745.1945@> >[Looks like CNEWS....] > 2 The local-part may not contain an unquoted `]'. > <]ocdj2.cj7@cat.de> >[Can't guess.] > 2 Quotes must match. > <"<9105141856.AA26881@cnmus.cnm.us.es> >[Sendmail?] >---------------------------------------------------------------------------- > >Out of the 10 given in the article, four look like Cnews. That a pretty >big percentage, but 10 is small. Perhaps, only four people either didn't >know how to install Cnews properly or just didn't want to generate >legal Message-ids. > >It is interesting to note that none of them were generated by bnews. >Unless that hp site was running bnews. -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone "Ya know, kitten tacos are really better than anything you've ever tasted before!" "Oh, really." -- Rush Limbaugh
kre@cs.mu.oz.au (Robert Elz) (06/19/91)
sob@lib.tmc.edu (Stan Barber) writes: >Okey. Let's look at the following article. >From: eggert@twinsun.com (Paul Eggert) >Subject: Recently observed nonconforming Message-IDs (discussion) And then shows lots of bugus message id's again, with explanations, including these ... > 32 The local-part may not end with `.'. > 22 The local-part may not begin with `.'. > 17 Two adjacent unquoted `.'s may not appear in a Message-ID. Since this is the second time (third if you count the later reposting of this article without comment, and for no apparent reason) I'm bewildered as to why no-one has commented on these. Exactly why are these things supposed to be invalid. The example given for the latter had the two adjacent dots in the domain part, which certainly is illegal, but that's not the explanation given. What's supposed to be so magic about dots in the local part that anyone would want to limit their use? I would submit that <...@cs.mu.oz.au> is a perfectly good Message-ID - if not likely to be a very useful one to use, but only because it will start getting absurdly long if the technique to make unique variants was just to add more dots. This breaches all three of the "rules" above, but nothing in any of rfcs 822 1123 or 1036. kre
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <5128@lib.tmc.edu> sob@lib.tmc.edu (Stan Barber) writes: >>This does mean that we occasionally have cause to revise our opinion of >>some feature, when it turns out that its lack causes problems. >Excellent. I am happy to see that you are willing to reexamine your opinions. >I frequently came away with a belief that you were unwilling to consider >the possibility of being incorrect on some issue. We do have strongly held opinions on a lot of things, but we do change them when the evidence clearly points the other way. We still don't like having to parse dates, for example, but it appears to be necessary -- our original belief that longer histories would suffice to deal with recirculation of stale news was incorrect. (It's still the technically-right solution, actually, but the length of history needed is impractical.) >>I would like to see a concise description of *exactly* what restrictions >>should be enforced, since full 822 parsing is ridiculously complex and >>expensive and appears to be overkill... >Perhaps this should be the subject of a revision of RFC1036 you proposed. >At the very least, only one @ should be allowed. How would you like to >proceed? By taking a long vacation. :-) Getting the RFC revised is likely to be a fairly lengthy process, although it is becoming clear that we need to tackle it soon. I'm going to pursue that when I get back from an imminent short vacation. Meanwhile, I *think* limitation to a single @ is the only urgent item, and this is being looked into. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <5129@lib.tmc.edu> sob@lib.tmc.edu (Stan Barber) writes: >Then let's revise RFC1036 then. >Who wants to contact the IAB? As the obvious victim, I tentatively plan to do that shortly. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <5127@lib.tmc.edu> sob@lib.tmc.edu (Stan Barber) writes: >>Actually, the consistency between Rick Adams's "version" control-message >>census and our statistics based on message-ID format strongly suggests >>that very few people have in fact hacked the ID format. > >Okey. Let's look at the following article. You can't learn anything by just looking at message IDs; you also have to know what software posted the stuff. There is *a lot* of gatewaying between Usenet and other networks. The single largest category of message IDs in my analysis results is "other", and comparing this to Rick's statistics indicates that most of the "other" sites don't answer control messages, i.e. they are on the other side of gateways and *probably* are running neither B nor C News. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
eggert@twinsun.com (Paul Eggert) (06/20/91)
sob@lib.tmc.edu (Stan Barber) writes: > 217 The local-part may not contain an unquoted `:'. > <17169:Jun1122:04:5791@kramden.acf.nyu.edu> >[This looks like it might have been a CNEWS message id.] No, this ID was Dan Bernstein's responsibility; he fixed this format after learning of the problem. >Out of the 10 given in the article, four look like Cnews. The 10 in the article were chosen as examples of each kind of error, and their distribution isn't representative of the whole sample. Of the 388 nonconforming IDs, only 38 have C News format; they seem to result equally from NNTP woes with double @ signs and from installers choosing nonconforming domain names.
eggert@twinsun.com (Paul Eggert) (06/20/91)
kre@cs.mu.oz.au (Robert Elz) writes: >I would submit that <...@cs.mu.oz.au> is a perfectly good Message-ID ... At first I thought the same thing, but when I wrote a Message-ID checker directly from the spec I discovered that I was wrong. The relevant part of the RFC 822 grammar is: local-part = word *("." word) word = atom / quoted-string atom = 1*<any CHAR except specials, SPACE and CTLs> specials = ... / "." / ... That `1' is easy to miss, but it means atoms can't be empty, and therefore `.'s can't begin or end a local-part, and unquoted `..' cannot appear anywhere in a local-part.
lear@turbo.bio.net (Eliot) (06/20/91)
Henry, It was my intent to take on updating of the News article description as the next task for our working group. I don't forsee that happening now until September or October. -- Eliot Lear [lear@turbo.bio.net]
henry@zoo.toronto.edu (Henry Spencer) (06/25/91)
In article <Jun.19.17.06.43.1991.1890@turbo.bio.net> lear@turbo.bio.net (Eliot) writes: >It was my intent to take on updating of the News article description >as the next task for our working group. I don't forsee that happening >now until September or October. That sounds reasonable to me. Heaven knows I'm in no hurry to take it on; I just wanted to make sure it got done. I'll probably be able to supply a revised draft as a starting point, but I'm just as happy if somebody else handles the IETF interfacing. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry