home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / vmsnet / networks / tcpip / multinet / 2411 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.6 KB  |  73 lines

  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!usc!news.service.uci.edu!unogate!mvb.saic.com!tgv.com!info-multinet
  3. Date: 20 NOV 92 21:05:31 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From:    SYSTEM@TEX.AC.UK (UK TeX Archive Manager <system@uk.ac.tex>)
  7. From: SYSTEM@TEX.AC.UK
  8. Subject: Unnecessary host routing in addresses resent by this list
  9. X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
  10. Organization: The INFO-MULTINET Community
  11. Message-ID: <36A00FB320NOV92210531@TGV.COM>
  12. Nntp-Posting-Host: Mvb.Saic.Com
  13. Lines: 58
  14.  
  15. I've noticed a strange (well, perhaps not:-) phenomenon about the headers of
  16. mail resent by this list.  Please excuse the appearance within what follows of
  17. addresses given in the UK's "big-endian" format: the Internet-Janet relay,
  18. nsfnet-relay.ac.uk performs this reversal on all entities that it recognizes as
  19. possibly forming the name of a host, and it's too much effort for me to
  20. [attempt to] re-reverse them into what I conjecture would have been their
  21. original format.
  22.  
  23. Anyway, the phenomenon is that mail from some senders, in particular [I think],
  24. those outside the "original" Internet (com, gov, mil, edu, etc.) gain a
  25. source-routing address such that any reply would be sent through tgv.com.  Here
  26. is an example coming from the University of Turku, Finland:
  27.  
  28. > Date: Thu, 19 Nov 1992 02:08 EET
  29. > From: HANNU (Hannu Pajunen) <HANNU%fi.utu.cc.sara@COM.TGV>
  30. > Subject: Vaporware
  31. > To: info-multinet@COM.TGV
  32. > Message-id: <01GRBHYUY1Y88WZRY1@sara.cc.utu.fi>
  33. > X-Envelope-to: info-multinet@tgv.com
  34. > X-VMS-To: IN%"info-multinet@tgv.com"
  35. > Sender: info-multinet-relay@COM.TGV
  36.  
  37. Now if I had wanted to reply to this mail, I could have sent it to the Finnish
  38. Internet just as easily as the poor over-burdened m/c at TGV: in fact, I could
  39. probably have sent it better, because traffic to Scandinavia from the UK shifts
  40. a lot faster than that going across the Atlantic, especially that which has to
  41. go TWICE.  So the address could just as easily have appeared as:
  42.  
  43. > From: HANNU (Hannu Pajunen) <HANNU@sara.cc.utu.fi>
  44.  
  45. which is, I'm sure, the form in which it appeared when it arrived at TGV.  Why
  46. provide this source-routing at all?  Surely there aren't sites (presumably
  47. running MultiNet) that don't know how to route outside the continental US, so
  48. have to be spoon-fed and sent via TGV?  Seems pretty unsatisfactory to me.
  49.  
  50. BTW, one criticism I have of this list, compared to many others, is that the
  51. return address appears as that of the original submittor of traffic: the lists
  52. I run (using home-grown DCL procedures and Deliver_Mailshr), and others such as
  53. the MX list (which presumably uses MX's excellent facilities) all tag the mail
  54. with the address of the list itself, so that replies can be disseminated to all
  55. and sundry.  In fact, *my* lists tag the mail (by use of two addresses in a
  56. Reply-To header) with the original sender's identity AND the list's name, IFF
  57. the original sender is NOT a subscriber to the list: that way, both he/she AND
  58. the subscribers get to see the original correspondence and the replies.
  59.  
  60. If, on the other hand, I want to reply to something that's come in through
  61. info-multinet, and ensure that it goes to everyone else too, I have either to
  62. remember to say /CC on the VMS-mail REPLY command, or use FORWARD and re-send
  63. to just the list alone [as I did with this message].  But when using FORWARD, I
  64. have to remember to give the RE: subject...
  65.  
  66. Perhaps the best solution might be to install MX --- I'm sure Matt could find
  67. time :-)
  68.  
  69. Brian {Hamilton Kelly}
  70. System Manager for the
  71. UK TeX Archive at Aston University
  72. 
  73.