Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!adm!SRA@xx.lcs.mit.EDU
From: SRA@xx.lcs.mit.EDU (Rob Austein)
Newsgroups: comp.mail.headers
Subject: A plea for sanity
Message-ID: <11789@brl-adm.ARPA>
Date: 12 Feb 88 19:02:29 GMT
Sender: news@brl-adm.ARPA
Lines: 56


    Date: Thursday, 11 February 1988  20:13-EST
    From: mcc@etn-wlv.eaton.com (Merton Campbell Crockett)

    [...]
    Perhaps its a problem with my view of electronic mail,
    particularly mail that is for forwarded to "tcp-ip@sri-nic.arpa";
    it is irrelevant to me whether a subscriber to this service from
    "bangland" failed to leave his PC powered-up to receive my comment
    or retort of questionable significance.  Why should I be inundated
    with "unable to deliver to xxx" messages?  Its "tcp-ip" that needs
    the knowledge as it may signify some network problem!

    It does raise some questions about SMTP and its interpretation of "From:"
    and "Forwarded by:".  The reporting of delivery errors should always be
    delivered to the "Forwarded by:" individual not the "From:" individual who
    may not have authorized the dissemination of the message.

Merton,

First off, TCP-IP is not really the place for this discussion (I know,
you didn't start it either).  If people want to continue it, please do
so in private or on Header-People@MC.LCS.MIT.EDU, the list for
discussion of mail protocols and lossage in the implementation of
those protocols.

Second, you should know that the SRI-NIC.ARPA mailer does everything
in its power to keep you from ever seeing those bounce messages:
specificly, it bashes the SMTP return-path of outgoing TCP-IP messages
to "TCP-IP-RELAY@SRI-NIC.ARPA".  Thus, anybody playing the game
correctly will send any and all automatic delivery flames to the list
maintainers at SRI-NIC, not to you (see RFC821 if this isn't clear).

The problem is that there are an awful lot of broken mailers out
there.  Chief offender in recent months has been one or more BITNET
mailers that discard the envelope ((B)SMTP) information and rewrite
the RFC822 message headers (which they then use for mail routing) in
completely bizzare ways.  This is worse than just throwing all the
mail on the floor, these mailers are very "smart" at figuring out who
the original sender of a message was so that they can torment her with
useless bug reports.  It has gotten to the point where posting a dozen
messages to one of the mailing lists I maintain produces over a
megabyte of mis-addressed garbage; I've started getting complaints
from subscribers because their (de)subscription requests are getting
lost under all this junk and thus being accidently ignored.

So, in closing (and as I've said on Header-People before), the problem
is not deficiencies in the existing mail protocols.  The problem is
mailers that don't implement the existing protocols and system
administrators who are unwilling/unable to install versions of the
mailers that DO implement the protocols correctly.  The main reason I
keep bringing this up in various forums is a hope that part of the
problem is ignorance on the part of the maintainers of the machines
running the broken mailers.

--Rob