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)