home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / headers / 429 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.2 KB  |  47 lines
  1. Newsgroups: comp.mail.headers
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!linac!mp.cs.niu.edu!rickert
  3. From: rickert@mp.cs.niu.edu (Neil Rickert)
  4. Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
  5. Message-ID: <1993Jan11.175033.25548@mp.cs.niu.edu>
  6. Organization: Northern Illinois University
  7. References: <1993Jan10.162048.22777@blilly.uucp>
  8. Date: Mon, 11 Jan 1993 17:50:33 GMT
  9. Lines: 36
  10.  
  11. In article <1993Jan10.162048.22777@blilly.uucp> bruce@blilly.uucp (Bruce Lilly) writes:
  12. >I have found a few discrepancies between RFC821 and RFC822 regarding the
  13. >contents of the Received header.
  14. >
  15. >1)    RFC821 section 4.1.1 requires the "from" and "by" clauses, while
  16. >    RFC822 4.1 lists them as optional.
  17.  
  18. I don't believe this is a discrepancy.  RFC821 is only discussing the
  19. new "Received:" header it adds, and is not referring to any pre-existing
  20. header.
  21.  
  22. >2)    RFC821 prohibits unquoted special characters (including '<', '>',
  23. >    and '@') in the optional "id" clause, while RFC822 requires that the
  24. >    format of the msg-id used in that clause, if present, is
  25. >        "<" local-part "@" domain ">".
  26.  
  27. The "id" clause is not the same as the msg-id.  That is, the msg-id, or
  28. more fully, the "Message-ID:" header is a unique identifier of the
  29. message.  The "id" clause in the "Received:" header could be just a
  30. transaction ID with purely local meaning.  It might, for example, be an
  31. identifier which can be used to locate log records retained on this
  32. host.
  33.  
  34. >                                                              If the "by"
  35. >clause is always provided, mail loops can be more quickly and more reliably
  36. >detected by processing the information in the headers, but it is not
  37. >acceptable for the machine to place any interpretation on comments.
  38.  
  39. If you really want to process the contents of "Received:" headers for
  40. finding mail loops, what you need is the requirement that such headers
  41. not be modified.  Then if there is a previous header from your own host,
  42. there is a loop.  The exact syntax of headers generated by hosts other
  43. than yours would seem to be of no importance.  I presume that your
  44. sofware can be designed to recognize the "Received:" headers it has
  45. generated.
  46.  
  47.