SRA@xx.lcs.mit.EDU (Rob Austein) (02/13/88)
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.
--Robslevy@uc.msc.umn.edu (Stuart Levy) (02/14/88)
(In reply to Rob Austein's message <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>) I don't think it's fair to call a mailer "broken" because it retains the address of the original sender for reply purposes. If mailing-list redistributions eradicated the original From: line, replacing the original sender's address with that of the redistributor, their mailing lists would be far less useful. Ditto if our mailers replied according to the SMTP envelope rather than the body of the message. Note that the envelope's format is not specified by RFC 822, only the message header is -- and messages can be delivered by other means besides SMTP. Though RFC 822 doesn't define it, I've seen some mailing lists distribute messages with an Errors-To: line. This seems to be just what's needed to separate message replies from delivery error replies. Sendmail seems to support "Errors-To"; how many other mailers do? Stuart Levy, Minn. Supercomputer Center
MRC@PANDA.PANDA.COM (Mark Crispin) (02/14/88)
Stuart -
You completely misunderstand the issue. SMTP (RFC 821) defines an
address that mailer error reports (as distinguished from replies) are
sent to. The BITNET mailers in question are using the reply address,
ignoring the errors address, to send errors reports to.
The BITNET mailers which do this are broken.
Errors-To: is completely unnecessary if SMTP is correctly implemented.
If you are using a non-SMTP transport, it should possess this functionality
OR it should do whatever equivalent exists in that transport to pass on that
address.
-- Mark --
PS: I am the implementor of one of the major electronic mail packages in
use on the Internet, and have been for 9 years. I know what I'm
talking about.
-------TVR%CCRMA-F4@SAIL.Stanford.EDU (Tovar) (02/14/88)
Errors-To: is completely unnecessary if SMTP is correctly implemented.
I will disagree strongly on this point. Having seen any number of complaints
about mail not going through from some individuals, i can definitely see the
utility of such a field and have been tempted on at least one occasion to
put a hack into our mailer to insert this sort of thing under certain
circumstances. (I bet MRC might even know what/who i'm talking about). At
least some naive users might be better off having errors go to someone who
knows about such things (rather than just being deleted, which is what happens
all too often).
Where Errors-To: would be most useful is where a message leaves the SMTP world.
... 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.
I think SRA is right. There is a problem here and the wider netmail goes,
the worse it's going to get until this get addresses. (Now, as i send this,
i fully expect to get numerous pages of useless crud dumped into my already
grossly overbloated mail file!)
-- Tovarblarson@skat.usc.edu (Bob Larson) (02/15/88)
In article <11806@brl-adm.ARPA> TVR%CCRMA-F4@SAIL.Stanford.EDU (Tovar) writes: [Quote from previous article:] > Errors-To: is completely unnecessary if SMTP is correctly implemented. >I will disagree strongly on this point. There are many incorrect implementations out there. I fail to see the need a need for an aditional errors-to field when existing imlementations fail to use the one that is present already. Yes, it is an envalope field, which means the envalope cannot be disposed of before successful delivery. If there are gateways that can't pass envalope data in an envalope, they should be the ones responsible for puting the information elsewhere. Since they don't follow the internet standards, why change the internet standards? Adding another field does not help, since the problem mailers that can't follow the current rules are the ones least likly to update to a new standard. Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
jc@minya.UUCP (John Chambers) (02/16/88)
In article <6959@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > In article <11806@brl-adm.ARPA> TVR%CCRMA-F4@SAIL.Stanford.EDU (Tovar) writes: > [Quote from previous article:] > > Errors-To: is completely unnecessary if SMTP is correctly implemented. > > >I will disagree strongly on this point. > Hey, I'd agree. But I'd also point out that it is a total irrelevancy in today's networking environmant. Sensible programmers don't write code (or at least try to sell it :-) which assumes that other software is correct. I learned that lesson the first time I tried calling a library subroutine. Email has lots & lots of opportunities to re-learn the lesson. For another metaphor, I'd like to point out that seat belts would be unnecessary if everyone drove correctly. True, but irrelevant. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
gerry@syntron.UUCP (G. Roderick Singleton) (02/18/88)
In article <11800@brl-adm.ARPA> slevy@uc.msc.umn.edu (Stuart Levy) writes: >(In reply to Rob Austein's message <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>) > >I don't think it's fair to call a mailer "broken" because it retains the >address of the original sender for reply purposes. If mailing-list > [ stuff deleted ] >Sendmail seems to support "Errors-To"; how many other mailers do? > > Stuart Levy, Minn. Supercomputer Center May I interject something here. I wonder if the complaint is more about mailers that DO NOT preserve the original From: line than those that do? I bring this up because I've noticed that my From: line has been changed when passing through various gateways, whenever I have been fortunate enough to establish return communications. This alteration of the From: line in the gateway has definately caused problems because the changes no longer reflect an accurate Return path. Now if my observations are correct, what mechnism can be used to ensure accurate return paths while permitting the various gateways to munge things before completing message transmission? I have been unable to establish the existence of any such mechanism and am forced to include a full return path in the body of the message to ensure return mail. I conclude, therfore, that mailers making this type of arbitrary change can be classed as broken. -- G. Roderick Singleton | "ALL animals are created equal, <gerry@syntron.uucp>, | BUT some animals are MORE equal or <gerry@geac.uucp>, | than others." a warning from or <gerry@eclectic.uucp> | "Animal Farm" by George Orwell