Jacob_Palme_QZ@QZCOM.MAILNET (04/25/84)
We who participate in ARPANET mailing lists via MAILNET have to pay the charge not only of sending messages to the list, but also of sending all messages from ARPANET to our site. It is then rather a nuisance when we receive error-messages that an entry which someone at our site made in an ARPANET mailing list could not be delivered to one member of that mailing list - information which is of very little value to us. Could not this be solved in the following way: (a) Such error-messages are sent to the SMTP-sender, not to the author. (b) ARPANET mailing lists, when redistributing messages, indicate the postmaster at the site handling the mailing list, and not the original author, as the SMTP sender when redistributing the message.
Jacob_Palme_QZ@QZCOM.MAILNET (04/25/84)
Here is an example of the kind of messages we get, and have to pay for. If the postmaster at the mailing list site had been the SMTP-sender when re-transmitting from the mailing list, this problem would not have occurred: Liaison@MIT-MULTICS.ARPA @QZCOM:POSTMASTER_at_QZ@ODEN.MAILNET Return-Path: <Liaison@MIT-MULTICS.ARPA> Received: from MIT-MULTICS.ARPA by QZCOM.MAILNET; 25 Apr 84 10:38 +0100 From: Network_Server.Daemon at MIT-MULTICS.ARPA Subject: Unable to deliver mail from POSTMASTER_at_QZ@QZCOM.MAILNET Message will be returned under separate cover. To: LATZKO@RU-BLUE.ARPA at COLUMBIA-20.ARPA: Network mail authorization failure Mail from POSTMASTER_at_QZ@QZCOM.MAILNET to LATZKO@RU-BLUE.ARPA is not authorize d
KPJ_Jaakkola_QZ_@QZCOM.MAILNET (04/26/84)
Should not messages indicating problems of sending to a mailing list item to a participant be sent to the mailing list request handler? That is, for FOO-REQUESTS for mailing list FOO.
Jacob_Palme_QZ@QZCOM.MAILNET (04/28/84)
Yes, that sounds like a good idea. That would mean that when the mailing list FOO sends out entries in the mailing list to its subscribers, it should indicate "FOO-REQUEST" as the SMTP sender (and not the original author of the message!)
REM@Mit-Mc.ARPA (Robert Elton Maas) (04/30/84)
(b) ARPANET mailing lists, when redistributing messages, indicate
the postmaster at the site handling the mailing list, and not
the original author, as the SMTP sender when redistributing
the message.
It's not usually the job of the system postmaster to maintain random
mailing lists that are stationned at that host, rather each mailing
list has its own maintainer. A convention that has been established
recently is to have a ...-REQUEST pseudo-mailbox for each major
mailing list which vectors to the appropriate maintainer. For example:
INFO-PCNET (INFO-PCNET-REQUEST vectors to myself, REM)
HUMAN-NETS (HUMAN-NETS-REQUEST vectors to Mel Pleasant or somesuch)
SPACE-ENTHUSIASTS, aka SPACE (SPACE-REQUEST vectors to OTA or somesuch)
Ideally the mailer at the mailing-list-maintaining host should know
the appropriate ...-REQUEST pseudo-mailbox for each major mailing
list, sending barfbacks there instead of to Postmaster, using
Postmaster only when the -REQUEST doesn't exist or isn't known to the
software.stew@lhasa.UUCP (04/30/84)
Sending all the messages failing on a distributed mailing list should
\not/, in my opinion, go back to either the real sender or the mailing
list coordinator, unless there is no alternative.
Coordinators of large mailing lists often have other things to do with
their time. Making them worry about why some random mailbox two gateways
and three redistributions down the line is not accepting mail at the moment
is not really reasonable. I propose that the message be returned to the
handling agent closest to the failing mailbox. This may be the postmaster
at the destination site, or at a redistributing site, or it may well be
the -REQUEST mailbox. The motivation is obviously that the closer to the
failure we can hit, the more likely we are to find the responsible party.
This scheme requires that every redistribution point put a Resent-From:
or Redistributed-From: header line into the message. These would then
be checked first for return addresses. The drawback here, of course,
is that the delivery software would have to be changed to do this if
it doesn't already. An alternative would be to have each redistributer
make itself the Sender. This is, in fact, how I read RFC822, section
4.4.4: "The 'Sender' field mailbox should be sent notices of any problems
in transport or delivery of the original messages. If there is no 'Sender'
field, then the 'From' field mailbox should be used." There is also
provision for a 'Resent-Sender' field. However, the standard does not
dictate when a 'Resent-' address should be given precedence, only that
it be 'more recent'.
Ideally then, the field to use is 'Resent-Sender', which should be
interpreted as the agent which most recently handled the message,
and which, presumably, is related to the mechanism for storing the
address which failed.
So how do we implement this? In my case, as an example, MSGGROUP sends
to MSGGROUP-INCOMING@HARVARD.ARPA which is an alias that includes, among
other addresses, lhasa!msggroup-incoming. This sends mail via (pseudo-)
uucp mail to my machine, lhasa, which has another alias. So when mail to
my mailbox fails, the message should be returned to lhasa!postmaster.
Since I \am/ lhasa!postmaster this will probably also fail, though!
So it ought to go to the next most recent agent, harvard!postmaster.
If anyone can show me how to mung sendmail config files to make this
happen, I will see that you are canonized :-)
Stew Rubenstein
lhasa!stew@harvard.arpa
{allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP
Harvard Chemical Labs, 12 Oxford St., Cambridge, MA 02138 @ U.S. MailWANCHO@Simtel20.ARPA ("Frank J. Wancho") (04/30/84)
Stew, As a maintainer of several mailing lists, and the former maintainer of one very large list, I tend to agree with your approach, but only for two annoying classes of returned mail: Quota exceeded and the gratuitous Failed after n days, will try another m days (or equivalent). ALL other failed mail should be returned to the list maintainer at the -REQUEST address (and NOT to the maintainer of record). (All of the lists which originate on this host have a -REQUEST entry, which is, in turn, a two-entry mailing list: one entry for the maintainer and one to a special mail file set up to receive copies of such mail for subsequent processing. The first entry simply serves to notify the maintainer that there is a problem. Unfortunately, we do not yet have the facility that automatically inserts/replaces the Return-Path header item with the -REQUEST addresses for mail sent to these lists. I, for one, would welcome such a feature to lift it out of the "folklore" arena and made a standard... and it doesn't *have* to be set up as -REQUEST; it could be a single, specially prefixed extry in the list itself.) However, even with Return-Path, there are certain sites which ignore that entry and insist on returning mail to the originator of the message... --Frank
stew@lhasa.UUCP (04/30/84)
RFC822 says that Return-Path is supposed to point back to the "originator",
not to transport or redistribution agents... But I guess standards are
there to be interpreted; certainly in this case we can "interpret" originator
as the agent which caused this piece of mail to be sent to this address if
that is the most useful.
The problem is that RFC822 simply does not adequately address the
concept of centrally-maintained mailing lists. This is certainly
a topic for which a new RFC would be appropriate. Anyone want to
get famous?
Stew Rubenstein
lhasa!stew@harvard.arpa
{allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP
Harvard Chemical Labs, 12 Oxford St, Cambridge, MA @ U.S. Mailron@Brl-Tgr.ARPA (Ron Natalie) (04/30/84)
All the BRL based mailing lists (at least) already do this. We change the return path to the -REQUEST address for the list. Unfortunately there are other lists who don't do that. More regretfully, there are a few arpanet sites out there (line MIT) that throw away the return path and send back to the original sender. -Ron
ron@Brl-Tgr.ARPA (Ron Natalie) (04/30/84)
The RETURN PATH in SMTP is the argument to the MAIL FROM command. This should be set to FOO-REQUEST. The "RETURN-PATH" header line should not be inserted by the list people but by the person who removes the letter from the SMTP realm. The RETURN PATH (from MAIL FROM) should be changed into something answerable by the realm it is being forwarded into at that time. -Ron
POSTEL@Usc-Isif.ARPA (04/30/84)
The sending of a message to a mailing list like msggroup can be seen as a two step process. The first step is the sending of a single message from the author to a mailing-list service. The second step is the sending of many messages by the mailing-list service to the many subscribers to the mailing-list. Any error in the first step should be reported to the author. Any error in the second step should be reported to the manager of the mailing-list service. --jon. -------
DMS%MIT-OZ@MIT-MC.ARPA (David Siegel) (04/30/84)
It would seem to me that this problem could be solved as follows: Have one internet host be a central mailing-list wide distribution center. All internet wide mailing-lists will have an address at that cite. (This also solves another common problem of not know where Info-So-and-so is located) The mail forwarding software at that cite can then be hacked to send all failed messages to info-so-and-so-request. If the load this would put on a particular host is too large, the central cite could forward the messages to other machines for redistribution. In addition, this central cite could have some kind of on-line package (like the NIC query system) to allow users to add and delete there names from any of this lists. This could all be done automatically, taking some of the load off the mailing list maintainer.
DonWinter.pasa@XEROX.ARPA (05/01/84)
AMEN hou3c!ka]