GA.JRG%STANFORD.BITNET@mitvma.mit.EDU (June Genis) (02/08/88)
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: HEADER-PEOPLE@MC.LCS.MIT.EDU cc: LSTSRV-L(LSTSRV-L@POLYGRAF)
WANCHO@simtel20.arpa (Frank J. Wancho) (02/08/88)
June, The real problem on BITNET is that RFC 821 is not fully implemented. Specifically, it does not retain the envelope information such as the MAIL FROM info, which was designed exactly for this application. If that information was retained and properly used, there would be no need for any special-purpose header types and no requirement for any mail agents to be taught to parse headers. Please obtain a copy of RFC 821 and read it before replying. --Frank
SRA@XX.LCS.MIT.EDU (Rob Austein) (02/08/88)
This is a follow-up on Frank Wancho's reply. RFC821 is the description of SMTP, a second-generation mail protocol; SMTP was designed with the shortcomings of a previous generation of mail protocols in mind. RFC822 (sic) traces its ancestory back to the earliest days of ARPANET electronic mail standards, via a series of revisions (RFCs 822, 733, 724, 680, and 561, for the curious). RFC822, by itself, is still a first-generation protocol, albeit one with provisions for encapsulation in a second-generation protocol (SMTP). Many BITNET sites have been using a modified version of SMTP called BSMTP (Batch Simple Mail Transfer Protocol) for several years with great success. The big stumbling block has been that not everybody on the BITNET implements BSMTP. Sometime in the last year or so, BSMTP was formally adopted as the official BITNET mail protocol. Unfortunately, the BITNET being the loose confederation that it is, there are STILL sites that don't use BSMTP, whether from ignorance, intransigence, or inability due to lack of vendor support. So the reason you are seeing these problems is that the BITNET community has not completely implemented the protocols that have already been designed and mandated to handle the problems. With no slight intended, the last thing the BITNET needs at this point is a change to the mail protocols, particularly if the experience with BSMTP is any guide to how such changes will be implemented. If you have some energy to invest in making BITNET mail work better, you would be better off using it to track down non-BSMTP sites and do what you can to help them to support BSMTP. I don't know how to post to LSTSRV-L, but if somebody wants to repost this message there it's ok with me. Please, no flames from people who haven't read both RFC821 and RFC822. Corrections to factual errors solicited. --Rob