Non-deliverable messages
Robert Elton Maas
(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.
st...@lhasa.uucp
\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...@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!st...@harvard.arpa
{allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP
Harvard Chemical Labs, 12 Oxford St., Cambridge, MA 02138 @ U.S. Mail
Frank J. Wancho
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
st...@lhasa.uucp
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!st...@harvard.arpa
{allegra!ima,ihnp4,decvax!genrad!wjh12}!harvard!lhasa!stew@UUCP
Harvard Chemical Labs, 12 Oxford St, Cambridge, MA @ U.S. Mail
Ron Natalie
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 Natalie
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