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
- rfc 1123 issue Bob Braden
- Re: rfc 1123 issue Erik Naggum
- Re: rfc 1123 issue Robert Elz