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
|
