home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / mail / uucp / 1752 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.9 KB  |  54 lines
  1. Newsgroups: comp.mail.uucp
  2. Path: sparky!uunet!uunet.ca!xenitec!golem!davidf
  3. From: davidf@golem.uucp (David J. Fiander)
  4. Subject: Re: mail from SCO via SunOS has bad header
  5. References: <1317@bridge2.NSD.3Com.COM>
  6. Message-ID: <1992Sep06.213155.1386@golem.uucp>
  7. Keywords: bogus Return-Path:
  8. Date: Sun, 06 Sep 1992 21:31:55 GMT
  9. Lines: 43
  10.  
  11. According to camerons@NAD.3Com.COM:
  12. >
  13. >Fellow netters,
  14. >Mail from my home site arrives at its destination bearing
  15. >an extra header item of the form:
  16. >
  17. >Return-Path: <myuname!user>
  18. >
  19. >This line doesn't do anybody any good,
  20. >and causes some destinations or intermediate sites to bounce my mail
  21. >with various "protocol errors."
  22. >My local mail expert tells me the Return-Path item is illegal and
  23. >shouldn't appear in my mail at all while it is traveling.
  24.  
  25. Completely true.
  26.  
  27. >When I mail from my home to here at work,
  28. >the extra line appears in the middle of the header, between the "Received by"
  29. >from my uucp neighbor and the "Received: from" by the gateway machine here.
  30. >
  31. >My uucp-mail neighbor first explained I am using a "dumb" uucp
  32. >and I should get a "smart" one,
  33. >and then they said they are still "investigating."
  34.  
  35. UUCP is UUCP.  What they might be complaining about is that
  36. they think that you are using a "dumb" mail system like pure
  37. UUCP.  If you are using MMDF, then this is not the case.
  38.  
  39. >I have examined my outgoing messages in
  40. >/usr/spool/uucp and there's no Return-Path: line in them.
  41. >I found no mention of dumb nor smart in the Nutshell Guide
  42. >_Managing UUCP and Usenet_.
  43.  
  44. If the header is not in the outgoing UUCP queue files, then it
  45. is not your fault.
  46.  
  47. >My neighbor (whose name I'd prefer not be mentioned here) is a cluster
  48. >of Suns running a stock SunOS.
  49. >They don't know anything useful about SCO, AT&T, or mmdf.
  50.  
  51. Since the header is not in your outgoing uucp queue, and they
  52. are running sendmail, then I would be forced to conclude that
  53. it is their fault.
  54.