home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.mail.headers
- Path: sparky!uunet!psinntp!monymsys!sonyd1.broadcast.sony.com!bruce
- From: bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly)
- Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
- References: <1993Jan10.162048.22777@blilly.uucp> <1993Jan11.175033.25548@mp.cs.niu.edu>
- Organization: Bruce Lilly
- Date: Tue, 12 Jan 93 14:48:30 GMT
- Message-ID: <1993Jan12.144830.7116@sonyd1.Broadcast.Sony.COM>
- Reply-To: lilb@sony.compuserve.com
- Lines: 91
-
- In article <1993Jan11.175033.25548@mp.cs.niu.edu>,
- posted to comp.mail.headers,
- rickert@mp.cs.niu.edu (Neil Rickert) wrote:
- >In article <1993Jan10.162048.22777@blilly.uucp> bruce@blilly.uucp (Bruce Lilly) writes:
- >>2) RFC821 prohibits unquoted special characters (including '<', '>',
- >> and '@') in the optional "id" clause, while RFC822 requires that the
- >> format of the msg-id used in that clause, if present, is
- >> "<" local-part "@" domain ">".
- >
- >The "id" clause is not the same as the msg-id. That is, the msg-id, or
- >more fully, the "Message-ID:" header is a unique identifier of the
- >message. The "id" clause in the "Received:" header could be just a
- >transaction ID with purely local meaning. It might, for example, be an
- >identifier which can be used to locate log records retained on this
- >host.
-
- In section 4.1 on page 17 of RFC822, the "id" clause of the
- Received header is defined (second line from the bottom of the
- page) as:
- [ "id" msg-id]
- While you correctly point out that it is not required that the
- msg-id in the "id" clause of the Received header be the same as
- the msg-id in the Message-ID header (which may well have been
- generated at another site), the *format* of the msg-id is the
- same, as described on page 18 of RFC822. The exact specification
- is:
- msg-id = "<" addr-spec ">"
- where the addr-spec is defined in section 6.1 on page 27 as:
- addr-spec = local-part "@" domain
- (which I had expanded in the text of my original posting for
- clarity, specifically regarding the '@' character)
-
- The main point here, is that the "<" and ">" which are
- explicitly required by RFC822 are expressly prohibited by
- RFC821 as amended by RFC1123.
-
- >> If the "by"
- >>clause is always provided, mail loops can be more quickly and more reliably
- >>detected by processing the information in the headers, but it is not
- >>acceptable for the machine to place any interpretation on comments.
- >
- >If you really want to process the contents of "Received:" headers for
- >finding mail loops, what you need is the requirement that such headers
- >not be modified.
-
- As in RFC1123 section 5.2.8, bottom of page 53 (note that it
- says ``An Internet mail program...'' not just a receiver-SMTP).
-
- >Then if there is a previous header from your own host,
- >there is a loop. The exact syntax of headers generated by hosts other
- >than yours would seem to be of no importance. I presume that your
- >sofware can be designed to recognize the "Received:" headers it has
- >generated.
-
- Yes, modulo a few details. It is possible that the exact format
- of the "by" clause may change from one instantiation to another,
- expecially for multi-homed hosts. In any case, however, the
- domain in the "by" clause should be one of the domains that the
- host is known by (e.g. host foo.bar.com. might use "foo.bar.com"
- or "bar.com" if it is a mail gateway machine that services all of
- bar.com. The domain inserted might change depending on changes
- to a sendmail.cf 'H' line, for example[*]). Also, it is possible
- that a forwarded message, forwarded using the Resent-xxx headers
- suggested in RFC822, rather than by encapsulation, could contain
- a Received header which has been locally generated even though
- the message is not a(n unintentional) mail loop. A (careful!)
- count of the Resent- headers could be compared to the count of
- Received headers which have a locally-applicable "by" domain to
- determine if there is a loop.
-
- There are two principal reasons why I am exploring this method
- of loop detection:
- 1) to be able to detect real loops more promptly than
- waiting for the number of hops to pile up to some pre-
- set limit
- 2) to avoid incorrectly treating a message which has (for
- example) passed through a large number of gateway and/or
- firewall machines as a looping message. It is possible
- that such a message may be incorrectly treated as a
- looping message when it is only a small number of hops
- from its destination.
-
- * or a change of MTA, or a change of domain from foo.nato
- to foo.int or from bar.su to bar.xx where xx represents a
- growing list of alternatives to "su"...
-
- --
- Bruce Lilly, Product Manager, |
- Routers, Peripherals & Still Store,| uupsi!monymsys!sonyd1!bruce
- Sony, 3 Paragon Drive, Montvale, | lilb@sony.compuserve.com
- NJ 07645-1735 | Telephone: +1 201 358 4161 | FAX: +1 201 358 4274
-