rfc 1123 issue
Bob Braden
----- Begin Included Message -----
From m...@NittmannMi.lax.trane.com Fri Mar 4 09:00:32 1994
Date: Fri, 04 Mar 1994 10:59:34 CST
From: m...@NittmannMi.lax.trane.com (Michael Nittmann)
Reply-To: nitt...@uwlax.edu
To: bra...@ISI.EDU, hoo...@ans.net
Cc: c...@kei.com, nitt...@uwlax.edu
Subject: rfc 1123 issue
Content-Length: 1427
X-Lines: 34
Hi,
this tcp-ip list does not seem to work, so I send it by hand to some
individuals:
>From m...@NittmannMi.lax.trane.com Fri, 04 Mar 1994 10:40:26 CST
>From: m...@NittmannMi.lax.trane.com
>To: tcp...@nic.ddn.mil
>Date: Fri, 04 Mar 1994 10:40:26 CST
>Cc: hoo...@ans.net, c...@kei.com, nitt...@uwlax.edu
>Subject: RFC 1123, 5.2.9, SMTP FROM:<>
>
>Why is this empty return path support really necessary? I believe it is a reclic
>of features to help interactively debug mailers. Some of those features have
>caused major headaches in the past (run commands under sendmail's privileges,
>see Mr. Morrison's 'worm').
>Especially for error returns, it is very important to know which one on the
>-- eventually transiting intermediate -- systems or gateways inserted it.
>And I see especially no need to send around anonymous letters on the network.
>
>Can we find a consensus to update 1123 to eliminate an empty return path? IT
>would hinder remailing hackers and close a potential security and abuse hole.
>
>Mike
>
>============================================================================
>Michael Nittmann 608 787 3792
>Principal Communications Analyst 608 787 2552 FAX
>The Trane Company
>3600 Pammel Creek Road, La Crosse, WI 54601 nitt...@uwlax.edu
>----------------------------------------------------------------------------
>
>
----- End Included Message -----
Robert Elz
>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:<m...@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
Erik Naggum
The empty return path is used to prevent loops in the mail system.
Consider mail sent between systems that both fail. You wouldn't want
messages that were increasing in size with each loop eat up all the network
and possibly disk resources while looping. You don't want error reports
from failed error reports to take up your local system administator's time,
either. However, a failure to deliver a message with an empty return path
should not be ignored, but delivered to the local postmaster.
The issue you address is taken care of by the Received header, which should
contain the domain name (from the SMTP HELO argument) and IP address of the
sending host ("from" field), the mailbox to which it was addressed ("for"
field), and any other information you need to track the message down. The
SMTP envelope can be forged much more easily than the Received header,
which is added locally, and over which the sender (forger) has no control.
The solution to the problems you outline lie at the local site, and no
standard or official recommendation can solve them. You will just have to
get or build a better SMTP server.
I don't understand the "remailing hackers" or the "potential security and
abuse hole". In what way is the value of the SMTP FROM argument causing
these, if it is not your own malfunctioning software that does not
understand them or recover from bad values?
Best regards,
</Erik>
--
Erik Naggum <er...@naggum.no> <SG...@ifi.uio.no> | Memento, terrigena.
ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS | Memento, vita brevis.