Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!smoke!Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Newsgroups: net.mail.headers
Subject: Re:     A protocol for distribution lists and their managements
Message-ID: <2181@brl-smoke.ARPA>
Date: Sun, 13-Jul-86 20:02:32 EDT
Article-I.D.: brl-smok.2181
Posted: Sun Jul 13 20:02:32 1986
Date-Received: Mon, 14-Jul-86 07:25:26 EDT
Sender: news@brl-smoke.ARPA
Lines: 29

(a) Can you explain more fully what is wrong with using Message-ID-s
for loop control?

I can see one problem. And that is which message-ID to use for
multi-body messages, and also finding the innermost message-ID
when X.400 messages have been converted into RFC-style messages
according to RFC987, where the inner message has become part
of the text body of the RFC822 message. But those problems, I
believe, are solvable.

Another problem is that some people or message systems may be
misusing Message-ID-s, for example by changing a message (e.g.
by adding text) without changing the ID. But that happens so
rarely that I do not see it as a problem.

(b) If we want conformance with X.400, we cannot put anything
into the IPMessageHeaders than is allowed by X.400. It would
be possible to add extra header fields by putting them into the
text of the message, but I intentionally tried to avoid adding
extra header fields when a field occuring in both X.400 headers
and RFC822 headers could be used reasonably well.

(c) I agree with you that "RESENT-" may not be good to use, primarily
because RFC987 does not recommend it in X.400 gateways. Instead,
RFC987 recommends putting inner bodies as text, so I guess that
is what one should do instead. This may cause some trouble for
a DL handler to distinguish between text which are headers of
forwardes messages, and text which is really text, but that problem
is probably solvable.