Re: rfc 1123 issue

Erik Naggum <erik@naggum.no> Sat, 05 March 1994 06:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27585; 5 Mar 94 1:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27581; 5 Mar 94 1:44 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14638; 5 Mar 94 1:44 EST
Received: from naggum.no by venera.isi.edu (5.65c/5.61+local-14) id <AA08491>; Fri, 4 Mar 1994 22:37:56 -0800
Received: by naggum.no id <AA02017> for ietf-hosts@ISI.EDU; Sat, 5 Mar 1994 07:36:23 +0100
Date: Sat, 05 Mar 1994 07:36:22 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Erik Naggum <erik@naggum.no>
Organization: Naggum Software; +47 2295 0313
Message-Id: <19940305.1082.erik@naggum.no>
To: Michael Nittmann <mn@nittmannmi.lax.trane.com>, nittmann@uwlax.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: ietf-hosts@isi.edu
In-Reply-To: <199403041718.AA00725@zephyr.isi.edu>
Subject: Re: rfc 1123 issue

Michael,

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 <erik@naggum.no> <SGML@ifi.uio.no>  |  Memento, terrigena.
ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS  |  Memento, vita brevis.