home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / headers / 431 < prev    next >
Encoding:
Text File  |  1993-01-12  |  4.8 KB  |  103 lines

  1. Newsgroups: comp.mail.headers
  2. Path: sparky!uunet!psinntp!monymsys!sonyd1.broadcast.sony.com!bruce
  3. From: bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly)
  4. Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
  5. References: <1993Jan10.162048.22777@blilly.uucp> <1993Jan11.175033.25548@mp.cs.niu.edu>
  6. Organization: Bruce Lilly
  7. Date: Tue, 12 Jan 93 14:48:30 GMT
  8. Message-ID: <1993Jan12.144830.7116@sonyd1.Broadcast.Sony.COM>
  9. Reply-To: lilb@sony.compuserve.com
  10. Lines: 91
  11.  
  12. In article <1993Jan11.175033.25548@mp.cs.niu.edu>,
  13.  posted to comp.mail.headers,
  14.  rickert@mp.cs.niu.edu (Neil Rickert) wrote:
  15. >In article <1993Jan10.162048.22777@blilly.uucp> bruce@blilly.uucp (Bruce Lilly) writes:
  16. >>2)    RFC821 prohibits unquoted special characters (including '<', '>',
  17. >>    and '@') in the optional "id" clause, while RFC822 requires that the
  18. >>    format of the msg-id used in that clause, if present, is
  19. >>        "<" local-part "@" domain ">".
  20. >
  21. >The "id" clause is not the same as the msg-id.  That is, the msg-id, or
  22. >more fully, the "Message-ID:" header is a unique identifier of the
  23. >message.  The "id" clause in the "Received:" header could be just a
  24. >transaction ID with purely local meaning.  It might, for example, be an
  25. >identifier which can be used to locate log records retained on this
  26. >host.
  27.  
  28. In section 4.1 on page 17 of RFC822, the "id" clause of the
  29. Received header is defined (second line from the bottom of the
  30. page) as:
  31.     [ "id" msg-id]
  32. While you correctly point out that it is not required that the
  33. msg-id in the "id" clause of the Received header be the same as
  34. the msg-id in the Message-ID header (which may well have been
  35. generated at another site), the *format* of the msg-id is the
  36. same, as described on page 18 of RFC822. The exact specification
  37. is:
  38.     msg-id = "<" addr-spec ">"
  39. where the addr-spec is defined in section 6.1 on page 27 as:
  40.     addr-spec = local-part "@" domain
  41. (which I had expanded in the text of my original posting for
  42. clarity, specifically regarding the '@' character)
  43.  
  44. The main point here, is that the "<" and ">" which are
  45. explicitly required by RFC822 are expressly prohibited by
  46. RFC821 as amended by RFC1123.
  47.  
  48. >>                                                              If the "by"
  49. >>clause is always provided, mail loops can be more quickly and more reliably
  50. >>detected by processing the information in the headers, but it is not
  51. >>acceptable for the machine to place any interpretation on comments.
  52. >
  53. >If you really want to process the contents of "Received:" headers for
  54. >finding mail loops, what you need is the requirement that such headers
  55. >not be modified.  
  56.  
  57. As in RFC1123 section 5.2.8, bottom of page 53 (note that it
  58. says ``An Internet mail program...'' not just a receiver-SMTP).
  59.  
  60. >Then if there is a previous header from your own host,
  61. >there is a loop.  The exact syntax of headers generated by hosts other
  62. >than yours would seem to be of no importance.  I presume that your
  63. >sofware can be designed to recognize the "Received:" headers it has
  64. >generated.
  65.  
  66. Yes, modulo a few details.  It is possible that the exact format
  67. of the "by" clause may change from one instantiation to another,
  68. expecially for multi-homed hosts. In any case, however, the
  69. domain in the "by" clause should be one of the domains that the
  70. host is known by (e.g. host foo.bar.com. might use "foo.bar.com"
  71. or "bar.com" if it is a mail gateway machine that services all of
  72. bar.com. The domain inserted might change depending on changes
  73. to a sendmail.cf 'H' line, for example[*]).  Also, it is possible
  74. that a forwarded message, forwarded using the Resent-xxx headers
  75. suggested in RFC822, rather than by encapsulation, could contain
  76. a Received header which has been locally generated even though
  77. the message is not a(n unintentional) mail loop. A (careful!)
  78. count of the Resent- headers could be compared to the count of
  79. Received headers which have a locally-applicable "by" domain to
  80. determine if there is a loop.
  81.  
  82. There are two principal reasons why I am exploring this method
  83. of loop detection:
  84. 1)    to be able to detect real loops more promptly than
  85.     waiting for the number of hops to pile up to some pre-
  86.     set limit
  87. 2)    to avoid incorrectly treating a message which has (for
  88.     example) passed through a large number of gateway and/or
  89.     firewall machines as a looping message. It is possible
  90.     that such a message may be incorrectly treated as a
  91.     looping message when it is only a small number of hops
  92.     from its destination.
  93.  
  94. *    or a change of MTA, or a change of domain from foo.nato
  95. to foo.int or from bar.su to bar.xx where xx represents a
  96. growing list of alternatives to "su"...
  97.  
  98. -- 
  99.     Bruce Lilly, Product Manager,      | 
  100.     Routers, Peripherals & Still Store,| uupsi!monymsys!sonyd1!bruce
  101.     Sony, 3 Paragon Drive, Montvale,   | lilb@sony.compuserve.com
  102.     NJ 07645-1735  |  Telephone: +1 201 358 4161  |  FAX: +1 201 358 4274
  103.