🚀 go-pugleaf

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