Re: rfc 1123 issue

Robert Elz <kre@munnari.oz.au> Sat, 05 March 1994 09:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00728; 5 Mar 94 4:12 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00724; 5 Mar 94 4:12 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02027; 5 Mar 94 4:12 EST
Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.61+local-14) id <AA11109>; Sat, 5 Mar 1994 01:06:02 -0800
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20919; Sat, 5 Mar 1994 17:29:51 +1100 (from kre@munnari.OZ.AU)
To: mn@nittmannmi.lax.trane.com
Cc: ietf-hosts@isi.edu
Subject: Re: rfc 1123 issue
In-Reply-To: Your message of "Fri, 04 Mar 1994 09:18:41 -0800." <199403041718.AA00725@zephyr.isi.edu>
Date: Sat, 05 Mar 1994 17:29:50 +1100
Message-Id: <7999.762848990@munnari.OZ.AU>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Elz <kre@munnari.oz.au>

    >Subject: RFC 1123, 5.2.9, SMTP FROM:<>
    >
    >Why is this empty return path support really necessary?

Like lots of things its not "really necessary", however it
is convenient.

    >I believe it is a reclic
    >of features to help interactively debug mailers.

No, not at all, its part of the protocol spec.  I can't at the
minute think of any way it would help debugging anything at all,
unless you mean that if someone wanted to test things by typing
at a remote SMTP server they would have a few less characters to
type, which is hardly a big benefit, and certainly not worth
mutilating the spec for.

But that's not what its about at all.

    >Some of those features have caused major headaches in the
    >past (run commands under sendmail's privileges,

Yes, but all that was debug type extensions, and/or user
convenience additions (the ability to send mail to processes,
etc), none of it is from the SMTP spec itself.

    >Especially for error returns, it is very important to know which one on the
    >-- eventually transiting intermediate -- systems or gateways inserted it.

The whole point of MAIL FROM:<> is that no error returns are
wanted.   If no error return is desired, giving an address to
which to send error responses (which is the sole purpose of the
address in the MAIL FROM) seems a little pointless.  Further
using the absense of the address allows a simple way to say
"no error response desired", without needing to add another
command just for that purpose.

    >And I see especially no need to send around anonymous letters on the network.

No, and there is no way to do so, all mail is required to contain
a From: header, which is required to contain an address.  That
address is (in the absense of a Sender: header) the address of
the author, if a message contains no From: header it should
simply be rejected.

    >Can we find a consensus to update 1123 to eliminate an
    >empty return path?

I very much doubt it, certainly I am opposed to any change
like that.

    >IT would hinder remailing hackers and close a potential
    >security and abuse hole.

It would do absolutely nothing of the kind.  How is it more
secure if I send mail to you with

	MAIL FROM:<mn@NittmannMi.lax.trane.com>
rather than
	MAIL FROM:<>

In both cases I won't see any bounce mesages, which is my
aim in sending the second - if you were to outlaw that I would
simply set my mailer to send the former of those two instead.

Note that you absolutely cannot do any kind of validation
(other than for a legal domain name if you feel inclined) on
the address in the MAIL FROM - that address is where bounce
messages should be sent, and doesn't necessarily have any
relationship whatever with the relay host that is forwarding
the mail to you.

kre