>This week a  big loop occurs between sunir.reunir.fr  RFC987 gateway and
>the cyber-l somewhere in bitnet area.
 
Note the spelling with a dash.
 
>no one on this "CYBER_L" distribution list caring to check
 
Now with an underscore.
 
>                Return-Path: <CYBER-L@HEARN>
 
Dash again.
 
>                 "MAIL FROM: <CYBER_L@HEARN>"
 
Underscore. It  is very  difficult for  me to analyze  this problem  if I
cannot be  sure whether we  have an underscore  or a dash  here. LISTSERV
lets the list  owner put whatever he wants in  the "Sender:" field (which
the MTA uses  to generate the MAIL  FROM: field), and I  can well imagine
why a list  owner would want to  have something that looks  like the list
name but  is still  different, for instance  CYBER_L instead  of CYBER-L.
Checking the  list headers now would  prove nothing, the list  might well
have been changed since then.
 
>         this X400 receipient was unreacheble  and the gateway send back
>         a notification  (call it an error-notification)  to the address
>         specified in  the P1-"Expeditor"  field, which  is the  same as
>         "MAIL FROM...".
>
>         And our  X400 was right  in doing this,  YES IT was  (and still
>         is).
 
Yes, it is, but what does your delivery error look like? Some send what I
call "burps",  ie a message  saying just  "There was an  error processing
your  mail." with  a subject  of "Warning:  problem with  DECNET host(s)"
(LISTSERV does  trap these messages because  it will never post  the same
message to the list twice, but  even to an experienced human reader there
is no way to  know which of the N messages that  were sent was rejected).
Note that I'm not saying your gateway generates "burps", I am just trying
to show that there is a whole gamut of delivery error types and that, for
this  reason,  including  a  copy  of the  delivery  error  in  ANY  loop
description is very important.
 
>         2)  A  liste  such  a   CYBER_L,  should  not  tolerate  having
>             mailer-daemon or Postmaster or ... talking in the list.
 
And what did your delivery error have in the 'From:' field? See above.
 
Your RFC excerpts show clearly that:
 
1. The system performing the final delivery should generate a Return-Path
   field with the contents of the MAIL FROM: field.
 
2. The MAIL FROM: field is where you should send any nastygram.
 
Consequently it  is correct for  your gateway  to send nastygrams  to the
Return-Path address,  assuming of course  that it is  generated properly.
What  I fail  to understand  is how  this is  supposed to  establish that
LISTSERV is "broken".
 
Finally, I  would like to add  that this problem occured  with a LISTEARN
server. Unless  the problem can be  reproduced with LISTSERV or  I can be
convinced that it would occur with LISTSERV,  I do not want to spend time
discussing it. I am not saying that in  order to get rid of a hot potato,
but because  a lot of mailing-loop  preventive code has been  added since
the LISTSERV-LISTEARN split.
 
  Eric