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.
-------roy@phri.UUCP (Roy Smith) (02/14/88)
Stuart Levy writes: > Sendmail seems to support "Errors-To"; how many other mailers do? A couple of years ago I was running a small mailing list and decided to add "Errors-To:" headers to outgoing messages. Much to my surprise I got some rather angry mail from a system administrator somewhere in Europe who said that his mailer didn't grok the "Errors-To:" lines. Not only didn't his mailer grok the lines, but it couldn't digest them or even consume them and pass them through unchanged. It seems that when his mailer saw the "Errors-To:" line it died, wreaking all sorts of havok and mayhem on his machine. He urgently requested that I either stop adding the non-standard headers or stop sending mail to his machine! Personally I thought he (and/or his mailer) was over-reacting, but I decided to drop the "Errors-To:" anyway. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (02/15/88)
I don't have 822 handy, but aren't you supposed to pass through lines that you don't grok? I've seen mail headers that include "Fruit-of-the-day:" and other such stuff (not to mention "Organization:", "Distribution:", "Newsgroup:", and "X-Comment:"). Why should "Errors-To:" be a problem, unless there was a bug in his mailer in handling this specific string? How long ago was this, anyway? -Philip