MRC@SU-SCORE.ARPA (Mark Crispin) (04/30/84)
As the developer of one of the major Internet mailsystems which
has redistribution-style mailing lists, I would like to comment on
the recent exchange of messages regarding error reports and how they
should be sent.
I definitely sympathize with the people who have to pay for
electronic mail messages. I would certainly agree that they have
every reason to feel badly treated by being made to pay for zillions
of mail failure notifications from some large mailing list.
On the other hand, there is another side. Some of the mailsystems
involved, mine included, behave the way they do for historical reasons.
In particular, much of the code was written long before Return-Path and
conventions such as "-REQUEST" existed. There are two issues involved.
First is the support of null Return-Path. The TOPS-20 mailsystem
literally cannot tell the difference between a null Return-Path and a
non-existant Return-Path. The distinction is important; the former
case means "errors should be discarded" and the latter means "errors
should be send to the 'sender', an abstract entity which may ultimately
be determined by parsing the message header." The result is the silly
behavior of sending an error to a Mailer Daemon or other entity that
specified it didn't want errors returns to it. This could be fixed,
but it is non-trivial to do.
Second is the official status of conventions such as "-REQUEST".
Unfortunately, there are no printed standards which specify this sort
of convention, merely folklore. It is very difficult for software
developers to develop a portable product for a wide range of environments
to deal in folklore for a single environment. More importantly, it is
not at all clear to me how global "-REQUEST" is, or what the rules to
determine its appropriateness. This is at least partially due to the
many kinds of mailing lists which can exist and the hazy distinction
between a "mailing list" and a "forwarding" which several mailsystems,
TOPS-20 included, have.
-------jsol@Bbn-Unix.ARPA (Jon Solomon) (04/30/84)
I don't believe that the mailsystem is responsible for inserting an appropriate return path or sender to force mail system errors to be returned to a specific mailbox. Using the digested lists as an example doesn't address the problems of immediate distribution lists returning errors to the sender of each message. Digested list maintainers can (and in most cases do) insert the return path for their lists because all the incoming mail goes out as the body of a message. The only part of a digest that a mail system cares about is the header. I distribute TELECOM, and all the errors from that list go to TELECOM-REQUEST (which is basically back to me). In the case of immediately distributed lists, some sort of filter mechanism must be inserted into the process of delivery to specify the correct return path/reply-to address. A mail system can support this sort of behavior by allowing the user to write the filter, and then run it over all mail going to a specific address. I believe this sort of filter mechanism is sufficiently useful that modifying the mailsystem to support it is possible without jeapordizing portability. I have spoken, --Jon
MRC@SU-SCORE.ARPA (Mark Crispin) (04/30/84)
I might also add that an attitude which can be taken is that large
redistribution lists are a luxury, that they have at best an indirect
relationship to the purpose for which the US taxpayers pay for Internet,
and that therefore the annoyance and inconvenience of the occasional
failed mail message is the necessary price to pay for this luxury. For
those on networks who pay charges for mail, their charges are small
compared to what the US taxpayers pay for Internet, and that therefore
it once again is the necessary price for electronic mail interaction with
the Internet.
I do not necessary agree with this attitude. Neither, however, do I
necessarily disagree with it.
I do, however, strongly disagree with the approach advocated by
certain members of this list which states that the appropriate solution
to the problem -- if it is a problem to be solved -- is technological.
Many of the notorious examples of bad software design originates in the
attitude that any problem should be fixed by adding a special-case
heuristic. I personally favor a operational/comprehensive design approach
and advocate adding heuristics only to match the design improvements.
-------werner@ut-ngp.UUCP (05/01/84)
< THE BUG IS DEAD !!! (rumour from a net-famous person) Reincarnating...> a) any delivery problems should go to the maintainer of the 'most recent' redistribution list and NOT TO THE SENDER. b) the delivery system which redistributes a 'broad-casted' article should NOT BE RESPONSIBLE to provide a return-path to the author. With the current incompatibility mess it is asking too much from the mailers to provide a path across 3 different nets and 5 different 'redistribution lists'. c) the author of an article should 'sign' his article, including some useful paths to his mail-box. d) NO ANONYMOUS messages. Either have another person post for you who vouches for the source, or post it as if you, yourself had another person asking you to post. That goes for kremlvax and moskvax, too. (which was a good joke, I'd like to hear more. Got 4.2 up yet??) The not-very-flexible-opinion of werner @ ut-ngp We do the thinking at tax-payers' expense at BIG-STATE-U the prototype under contract to EYE-BE-AM the first production model at BIG-$$$ salary for TI-EYE We become a partner to market an "improved version" for micros Then we find some venture capital and develop the definitive version, (luckily we NEVER signed any non-disclosure forms - we are too famous to be pushed into that) We either make it big, but get pushed out of the company because we have less than 50% of the shares, or we go broke .... both lead us to become a CONSULTANT to tell others how we wished we had done it ..... NEXT TIME, WE ARE GOING TO DO IT RIGHT ... FER SURE (famous last words) Gad, it feels like Monday ...
Jacob_Palme_QZ@QZCOM.MAILNET (05/06/84)
@MIT-MULTICS.ARPA,@BRL-MIS:msggroup-request@BRL-MIS.ARPA
@QZCOM:conference_153@ODEN.MAILNET
Date: Sun 29 Apr 84 17:07:30-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Second is the official status of conventions such as "-REQUEST".
Unfortunately, there are no printed standards which specify this sort
of convention, merely folklore. It is very difficult for software
developers to develop a portable product for a wide range of environments
to deal in folklore for a single environment...
This shows that a good message exchange standard should certainly
include concepts corresponding to the "-REQUEST" convention, that
is they should include network mail operations to:
- Automatically add yourself to a distribution list (the list manager
or managing program can of course control who are allowed to make
this operation on the list)
- Automatically remove yourself from the list
- Automatically add and remove other people remotely from the list
(remote control of a distribution list via the network) this is
useful when the controller of a main list wants to add or remove
members from a sublist
- Communicate in general with the list manager
All the above operations, and many more, are covered by the GILT
standard developed by a cooperation of institutes in nine European
countries.ROODE@SRI-NIC.ARPA (David Roode) (05/08/84)
If a mailsystem existed which treated mail to mailing lists (exploders) this way If mail is to mailing list then check for definition of delivery error mailbox corresponding to that mailing list and if found use it in the return path else use normal return path then a site could choose the type of treatment it desired for a particular mailing list by selecting whether or not to define the delivery error mailbox corresponding to that mailing list. For example, if the mail is sent to INFO-PASCAL, the site handling the exploding of INFO-PASCAL could control how the mailsystem prepared Return Paths for INFO-PASCAL by defining or not defining INFO-PASCAL-ERRORS appropriately. In no way need such a feature in a mailsystem FORCE a user of that mailsystem to divert delivery errors to a handler at that site rather than returning them to the submittor of the message. -------
laura@utzoo.UUCP (Laura Creighton) (05/21/84)
As long as people are thinking about *whom* to mail *what* to: Every so often I post something to unix-wizards. Every so often things do not go well. The last time I posted to unix-wizards, some site (I think it was BRL, but I could be wrong) which appears to be a critical path for many people was down. Very down. I received more than 300 messages saying that the mail was undeliverable. There would have been many fewer messages if it wasn't deemed fit to tell me that``Messaged failed after x days, trying for y more days '' or some such. It conceivably would have been useful to tell me ``problem suspected at BRL (if indeed that was the site)'', ONCE, but sending me the text of my message did not help much. I shudder to think of what would have happened if I had posted 4 or 5 articles to unix-wizards that week. I was the wrong person to send this stuff to. There wasn't a thing I could do, so I threw it all away. I also throw away messages that I receive which inform me that somebody who used to be on the mailing list no longer has an account. Something tells me somebody else would be a better person to inform. Laura Creighton decvax!utzoo!laura@berkeley -- Laura Creighton utzoo!laura "Not to perpetrate cowardice against one's own acts! Not to leave them in the lurch afterward! The bite of conscience is indecent" -- Nietzsche The Twilight of the Idols (maxim 10)
ESTEFFERUD@Usc-Ecl.ARPA (05/24/84)
The problem you cite is a very well know one, but knowing about the problem and eliminating it everywhere in the combined Internet are two very different things. We are now at the point where general discussions about the general case, without attaching specific details such as one of the returned messages, can only frustrate the lot of us who have been receiving these complaint messages for a very long time now. I think it must be about 3 years ago that we modified the BRL distribution system to insert a new Return-Path (which you should see in this message) to direct failure notices back to a BRL-list-maintainer. So, it seems to me that either you are citing a very old case, or you have a new case of some different kind of failure. It would be nice if you would send the relevant detailed information on your cataclismic case to postmaster@BRL so they might determine what you are so vaguely refering to. Thanks for trying to help! Stef
mike@BRL-TGR.ARPA (Mike Muuss) (05/25/84)
BRL specificly adjusts the SMTP MAIL FROM field so that failure notifications from the Unix-Wizards list go to Unix-Wizards-Request. However, there are some sites (most notably the PDP-20 systems) which are "very clever", and discard the MAIL FROM field, and re-parse the header. If such a site has a "mail exploder" which further redistributes the Unix-Wizards mail, and there is a problem, they will return the messages back to the sender, rather than Unix-Wizards-Request. The 4.1 BSD (BBN) UNIX systems also exhibit this problem; 4.2's SENDMAIL seems to do it right. I doubt that we will ever get all the systems on the net to ever implement the specification correctly. -Mike
ESTEFFERUD@Usc-Ecl.ARPA (05/25/84)
Hi Bill --- You asked "What exactly does the BRL Mailer do?" Well, in a logical sense, it is not the Mailer at BRL that does it. It is a Distributor which is invoked when a mail item arrives for Distribution to a list that is stored at BRL by a list maintainer. The Distributor, acting as though it were a User Agent, with authority to modify the message in any way it sees fit, simply causes the Distributed copies to be given a specified Return-Path: field content. In the case of MsgGroup, this is: Return-path: <msggroup-request@brl-mis> It might be argued that this Distributor is in fact implemented as though it were a module of the Mailer, but logically speaking, it must be operating outside the authority of the mailer, else it should not be messing with the return path in this way. So, it is logical, as I see things, to consider it to be acting with the rights and privileges of User Agent, which acts on behalf of subscribers, to remail items received from contributors, who are assumed to understand that they are contributing to a quasi publishing operation which will broadcast their contribution to a list, and hopefully will buffer the contributors from failed mail notices resulting from failures beyond the Distribution point. It will be nice when all public distribution lists in the Internet operate in this manner. I understand that BRL uses this arrangement for all lists that the maintainer wishes to operate this way. It is a matter of individual maintainer's prerogatives to do so. Enough? Stef
EE.GDS%MIT-OZ@MIT-MC.ARPA (Greg Skinner) (05/27/84)
I often get upset when I send a message to a list such as human-nets, which occasionally has out-of-date addresses whose host machines may have crashed. I too, get messages such as ... foo at AMES-TSS: Message undeliverable for x days, will try for another y days In USENET, the user is able to "cancel" an article he posts. The cancellation is first done locally at his own site (the article is deleted from his local filesystem), then a control message is sent to all other machines to whom the poster's site talks to, instructing them to delete their received copy from their filesystems. And so on and so forth ... It would be a useful feature if at the redistribution point, a facility was enabled so that users could send a cancellation message instructing the host to dequeue the currently undeliverable messages. Greg Skinner ARPA: gds%mit-eddie@XX UUCP: ...decvax!genrad!mit-eddie!gds -------
MRC@SU-SCORE.ARPA (Mark Crispin) (05/30/84)
Mike -
You're wrong. The DEC-20's (the machine is a PDP-10; there is no
such thing as a PDP-20) don't discard the MAIL FROM field. They use it
as is.
The bug is that they can't tell the difference between "null MAIL
FROM" and "MAIL FROM unspecified". In the former you should discard
the message on failure; in the latter you should parse the header to
get a sender. We only do the latter action. The problem is that we
support non-Internet networks which don't negotiate something like
"MAIL FROM".
-- Mark --
-------