Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!ucbarpa.Berkeley.EDU!jordan
From: jordan@ucbarpa.Berkeley.EDU.UUCP
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: return paths
Message-ID: <17432@ucbvax.BERKELEY.EDU>
Date: Wed, 18-Feb-87 15:14:31 EST
Article-I.D.: ucbvax.17432
Posted: Wed Feb 18 15:14:31 1987
Date-Received: Thu, 19-Feb-87 21:31:57 EST
References: <17386@ucbvax.BERKELEY.EDU> <1448@umd5>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes)
Organization: Experimental Computing Facility (XCF), UC Berkeley
Lines: 28
Xref: watmath comp.mail.headers:145 comp.mail.misc:84

Ben Cranston <zben@umd5.umd.edu> writes:

	But you are missing the point.  Internet advisories go back via
	the reverse-path and not via the Sender: or From: fields.  A
	returning advisory will cause the sending mailer to
	continuously try to access a nonexistant SMTP server on the
	joes_pc node...

Um, which "reverse-path" are you talking about?  Perhaps the one that I've
marked below?

	>> HELO joes_pc.umd.edu
-->	>> MAIL FROM:<dzoey@maildrop.umd.edu>
	>> ...
	>> From: Joe Herman <dzoey@maildrop.umd.edu>

The SMTP (note: *not* the headers in the message) command "MAIL FROM:"
is what gets used for a return in case of a problem.  This in fact
points to a usable mailbox in my scenario.  Also, in the part of the
body of the message (that which follows the SMTP command "DATA") has a
From: line that points to the same place so that UAs (User Agents) can
use it if they like.

The only place that I have mentioned joes_pc was in the SMTP command
HELO, which a few recieving SMTP's are now policing.  This has NOTHING
to do with where to send an advisory.

/jordan