This week a big loop occurs between sunir.reunir.fr RFC987 gateway and the cyber-l somewhere in bitnet area. We (Jean Paul Leguigner and Serge Aumont) received many impolite, insulting or childish mails as postmaster of this gateway... It was a real brawl, but no one on this "CYBER_L" distribution list caring to check what was the real problem. Anyway I suppose most of you are customer of this kind of delirium in distribution list. Well lets be constructive and explain the story. ================================================ Lets explain first how things happened: ===================================== The situation: -------------- CYBER_L / \ | | RFC-822 | V /| France | ----------- ---------- / \ (FNET) / / \ | |/ --------------- | EARN |<--->| Gateway | \ / | G/CICB |\ -------------- ------------ ---------- \ / \ FRCICB62 | X400 | + sunir.reunir.fr | | \ / -------------- C=fr;admd=atlas;prmd=cdcfrance;S=foo CYBER_L explodes mails and sends it to all recipients in the list. One of them is and X400 receipient : foo Here is what he receives: (We have checked it!) Return-Path: <CYBER-L@HEARN> Received: .... Received: .... Date: .... Reply-To: CYBER List <CYBER-L@HEARN> Sender: CYBER List <CYBER-L@HEARN> From: X <X@....> Subject: kkkkkkkk Comments: ..... and the data..... So the gateway receives a mail and one line of the BSMTP looks like "MAIL FROM: <CYBER_L@HEARN>" Our RFC987 gateway considers this as the "expeditor" of the mail, I man not saying the "Originator". It converts this to the X400/P1 "Expeditor" field with the value: <CYBER_L@HEARN>. And the it the X400 part of our gateway tries to deliver the mail. Here begins the painful story, 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). RFC-821, RFC-822 and RFC-1123 are very clearabout this. So the X400 Mailer sent an error message back to CYBER_L!!!!! which in turn tries to send it to all the recipients of the list. I let you imagine what can occur in such a situation (about 200 Mega Bytes of unussefull traffic generated !). Who is FAULTY? -------------- We say listserv because: 1) A distribution list should never put its own address in MAIL FROM like: MAIL FROM: <CYBER_L@HEARN> 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. It's important to note that we never came across this problem with any of the mailing lists of internet and bitnet that are using our gateway each day. So, I tried to reproduce this loop with a "test" list in FRMOP11 (using listearn ) and with a another one in FRULM11 (using listserv), and I was not able to reproduce it. What i didn't test is a loop in a list using both listearn and listserv but anyway it's not my job. Note, that we only say : "listserv (and listearn) are not conformant to RFC, please try to fix it as soon as possible." We are not saying as some did : "Stop this nonsence immediatly!". Yours ever Serge Aumont, Jean Paul Le Guigner ===================== SOME EXTRACTS OF RFCS ============================== RFC-822/1295 ============= 4.3.1. RETURN-PATH This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator. Note: The "Reply-To" field is added by the originator and serves to direct replies, whereas the "Return-Path" field is used to identify a path back to the origina- tor. While the syntax indicates that a route specification is optional, every attempt should be made to provide that infor- mation in this field. RFC-822/1424 ============ Note: The "Return-Path" field is added by the mail transport service, at the time of final deliver. It is intended to identify a path back to the orginator of the mes- sage. The "Reply-To" field is added by the message originator and is intended to direct replies. RFC-822/1868 ============= the body of the message. The "Return-Path" field can aid recipients in recovering from these errors. 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. RFC-1123/3671 ============= 5.3.3 Reliable Mail Receipt When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously, i.e., it MUST NOT lose the message for frivolous reasons, e.g., because the host later crashes or because of a predictable resource shortage. If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope; see Section 3.6 of RFC-821. The recipient of this notification SHOULD be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. If the address is an explicit source route, it SHOULD be stripped down to its final hop. DISCUSSION: For example, suppose that an error notification must be sent for a message that arrived with: "MAIL FROM:<@a,@b:user@d>". The notification message should be sent to: "RCPT TO:<user@d>".