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>".
|
