Dear Header-People,
 
The BITNET list LSTSRV-L has recently been discussing the creation
of some new optional tags as a potential solution to looping
problems in the LISTSERV system.  Initially it was proposed that
these be added as registered new optional tags as per RFC822 already
allows for.  It strikes me, however, that as long as conforming
mailers are only required not to barf upon seeing these new headers,
rather than being required to process then as defined, leaves us
with a rather large hole that can not be truly plugged unless RFC
822 itself is modified (or supplanted by another RFC -- I don't
really understand the procedures for this sort of thing).
 
As concisely as I can state the problem RFC822 just doesn't allow
for the degree of automation that BITNET people want to build into
their systems.  While 822 clearly states that the Sender: header
should be used to route notification of any routing problems, it
provides no alternative place to identify the sending agent when
that agent is someone different that the party (human or automated)
who should be notified about problems.  Clearly the single Sender:
header ought to be split into two separate headers.
 
Now for the hard part, is there any reasonably friendly way to
effect such a transition?  Examined linguistically it would appear
much better to redefine Sender: as only being the sending agent
while inventing a new tag (several such as Errors-to:  or
Rejections-to:  have been suggested) for the notification function.
Unfortunately, there is already a lot of software out there designed
to treat Sender:  as we would like the new tag to be treated.  Is it
at all likely that (1) we will ever get agreement on such a change
in view of the programming effort it would engender, (2) if
agreement is reached (however that is determined) are we really
likely to see most affected software corrected and (3) if so, what
sort of mess are we likely to have during transition?
 
My own feeling is that although I would like to see Sender: retained
with a new meaning, any transition allowing it would be very messy.
If two new headers (Sending-Agent: and Errors-to: perhaps?) then
people wishing to follow the new rules could look for the new tags
and if missing fall back on the old rules on the assumption that it
was dealing with a transmission from a non-upgraded mailing agent.
Other people seem to feel that a revised receiver need only look for
the presence of the new (Errors-to:) header to decide if it should
use the revised rules. I fear that still leaves too much room for
ambiguity.
 
Has this issue been discussed previously on this list?  If so,
can someone succinctly summarize the discussion do far? (BTW,
please copy me directly on this right now as I've only just
sent in my request to be added to HEADER-PEOPLE.)
 
/June
 
To:  [log in to unmask]
cc:  LSTSRV-L(LSTSRV-L@POLYGRAF)