On Fri, 19 Oct 1990 11:16:10 +0100 Serge Aumont said: > This week a big loop occurs between sunir.reunir.fr RFC987 gateway and >the cyber-l somewhere in bitnet area. > >Who is FAULTY? >-------------- > We say listserv because: > 1) A distribution list should never put its own address in MAIL FROM > ... There are enough reasons in RFC-821, RFC-822 and RFC-1123 to > prove This. > 2) A liste such a CYBER_L, should not tolerate having > mailer-daemon or Postmaster or ... talking in the list. > ....... >RFC-1123/3160 >============= > > The MAIL FROM: information may be passed as a parameter or > in a Return-Path: line inserted at the beginning of the > message. > Well, here we go again. I was rather curious after reading the opening lines 'cause I expected to see the applicable parts of the various RFCs. To my disappointment - and, of course, in my opinion - they prove next to nothing. All it proves is that RETURN-PATH is the correct address for returning error replies. If you interpret the above RFC-1123/3160 as extension to RFC821/RFC822 then you have one of the following: a) MAIL FROM: has to be a "valid" Return-Path (RFC821) b) MAIL FROM: is taken from Sender: (RFC821) Sender: has to be a valid Return-Path (RFC822) And note the *MAY* in the above quote ... As for RFC822/1424 the quote says ".... at the time of the final deliver.". LISTSERV/LISTEARN (and some other facilities as well) are RFC822 based, nothing else. There is this big flaw in RFC822 (and also RFC821 for that matter) and unless you enforce a new standard you have to live with the possibilty of other interpretations. As I said this is my personal opinion, I haven't read the RFCs recently and I also don't take part in their development. As user and postmaster I can only say that you just can't say: though it is not stated in RFC822 from now on the Sender: field must not point to a list because RFCnnnn maps this field to Return-Path. > 2) A liste such a CYBER_L, should not tolerate having > mailer-daemon or Postmaster or ... talking in the list. Well indeed, knowing the mentioned weakness of RFC822 Eric added various checks. Now if only one could point to some official standard which would help to indentify all the flavours of names and addresses these daemons, gateways and so on have. All this seems to be a never ending discussion. Probably the most interesting solution would be: discard the Sender: field entirely and let the BSMTP MAIL FROM: point to the "human who wrote the message (hwwtm)". Why? 1) It avoids loops since there is no reference to the list (well, you can put it in a Comment: or X-:) 2) Strictly seen such delivery errors are only of interest to the "hwwtm" that the mail wasn't delivered to it final destination. The only exceptions are a) the server's code creates invalid addresses, then it should be directed to the servers maintainer/postmaster b) the MTA erred - similar to a) c) the Owner added an invalid address, it should be sent to the Owner Since even the smartest gateways, daemons, etc. are unable to make this distinction and only a small fraction of mail is returned for the reasons above it'd be the best to return the item to the "hwwtm", since it's the person who should be notfied that the intended audience couldn't be conatcted. 3) Any software relying on RSCS TAGs, RFC822 fields or NJE filenames to determine other attributes than "hwwtm", Subject, date and various flavours of organizational names, software levels of daemons or the number of pins of the transmission cables does so without any explicit RFC specification and therefore on it's own risk. 4) RFC822 mail is an anachronism and should make room for better standards. Anyway it's not a real problem since OSI, TCP/IP and similar things will make gateways obsolete and everything will be a direct communication. And I'm very eager to spend my day discarding the various delivery and non-delivery reports. Christian