Mishkin@YALE.ARPA (Nathaniel Mishkin) (02/06/84)
Flame on:
I just saw a message that had the following 2 header lines in it:
Return-Path: <ER90@CMU-CS-A>
From: Elaine.Newborn@CMU-CS-A.ARPA
The "Return-Path" is being generated from data passed in the envelope
(SMTP "MAIL FROM"). It seems to me that it's not unreasonable for
the "Return-Path" to bear some resemblance to the "From", no? It's
bad enough that the two addresses are sometimes trivially different:
I've seen mail from many sites in which the case differs (I'm not
advocating case sensitivity in user IDs, but some sites DO rely on
it). But the case above seems pretty extreme. Which address am I
supposed to reply to? If the answer is "either works", why can't
the software arrange to give the more sensible one (I'll give you
a hint about which I think is the more sensible one: it doesn't have
numbers in it; bonus points: why is it ER90 instead of EN90?).
-- NatMRC@SU-SCORE.ARPA (Mark Crispin) (02/07/84)
I have seen the question of replying to the Return-Path come up
zillions of times. Why won't people read RFC 821 and 822 instead of
asking this question (or complaining about software which does not
reply to the Return-Path)?
You *never* reply to the Return-Path. The Return-Path is merely
the "return address" for a message if it is undeliverable. It may be
the sender of the message. It may be the author of the message. It
may be the reply address of the message. It may be the mailer process
at the sending site. It may be null. It may be none of these. There
is NO relationship between the Return-Path and any reply address. The
fact that actual usage patterns very often establish such a relationship
is irrelevant.
-- Mark --
-------Mishkin@YALE.ARPA (02/07/84)
I have seen the question of replying to the Return-Path come up
zillions of times. Why won't people read RFC 821 and 822 instead
of asking this question (or complaining about software which does
not reply to the Return-Path)?
I am perfectly well aware of the fact that the Return-Path CAN be
different from the From and that there are good reasons why it sometimes
is. And I'm not talking about what address should be used for replies.
What I want to know is WHY in the obvious cases (like the one I showed)
IS it different. Given that the sender of a message generally does
not (manually) specify the contents of either the Return-Path or From,
why do the two fields end up being different in the way they are in
the example I gave? I am hardpressed to believe that it is a desirable,
intentional, or rational feature that the 2 should be different in
the trivial case. I find it hard to believe that whoever wrote the
software that caused the behavior I saw considers the difference
anything less than a misfeature, if not an outright bug.
What I'm really talking about here is the confusion factor: seeing
a Return-Path and From that do not agree might lead one to believe
that there is some significance in the difference -- otherwise, why
would they be presented differently?Rudy.Nedved@CMU-CS-A.ARPA (02/07/84)
Nat, The return path is the route the mail message took including getting bounced off mars, jupiter and venus. It is not what a mail composer uses to for a return path....it is also quite possible that the reverse path is slower. The return path is only for mail delivery errors. The mail composers should "reply" or "answer" based on the From, Sender and Reply-To fields as specified in RFC822. Admittedly, it is bizzarre that the return-path mailbox specifier is different from the from mailbox specifier but there isn't a quick fix that will 1) get what you want and 2) generate a valid return path. I have plans to fix it but I don't expect it fixed for at least a couple of months. At that point, CMU should have a global distributed name datanase so that anyone on any of our hosts can just say "mail rudy nedved" and it will get to the right mail box. It is all a matter of priorities. -Rudy
cak@Purdue.ARPA (02/07/84)
Would someone please grab Eric Allman, give him a swift kick, and point him at this dialogue? His sendmail program insists on using the string supplied in the SMTP MAIL FROM:<> command as the "Unix-style" from line, which most Unix mail readers pay attention to in preference to the RFC822 From: line when generating a reply address. It is a completely different bogosity that the situation with Unix mail readers comes up at all, but that is a historical dreg and not Eric's fault. But the fact that he ignores it is incomprehensible. Cheers, chris ----------
ron@brl-vgr.ARPA (02/07/84)
The confusion factor is minimized by not looking at RETURN-PATH.
If you must, configure your mail reader such that the RETURN-PATH
lines are deleted. The reason in you case (although I am not certain)
is probably one of human engineering. At BRL, for the sake of user
friendliness, a user is allowed to specify any return address in his
FROM or SENDER line that will legally get the letter back to him
(the validation on this is interesting but too lengthy to discuss here).
However, the return path is always set to the address that the system
determines is the mail invoker really is associated with. This also
allows getting around the multiple FROM list problem. For example:
I can send a letter with "FROM: Ronald.Natalie@BRL" but the mail system
recognizes me as the "ron" user on the BRL-VGR host and my return path
gets marked as "ron@Brl-Vgr".
RETURN-PATH should probably not be in the header at all, except that
mail does get out of the SMTP environment and it's nice to propagate
the information along to the non-SMTP environments.
The other major use (other than setting return path to null to avoid
error messages entirely) is with large mailing lists. If you look
carefully at the large lists maintained at BRL (INFO-{MICRO,UNIX,CPM,APPLE},
UNIX-WIZARDS, MSGGROUP). You will find that although these appear to
be simple mail exploders (an incoming letter immediately gets turned around
and sent out to the list), a transformation occurs. The RETURN-PATH
is changed from what it was to the appropriate -REQUEST list. This keeps
the list submitters from seeing errors that are beyond their control
to fix and forwards them to the people who might be able to fix them who
would ordinarily have seen them.
-RonCraig.Everhart@CMU-CS-A.ARPA (02/07/84)
It just doesn't matter, period, that the two are different. I don't care what you think of the aesthetics of each individual field--whether it was a design choice that those two fields look as they do, or (as is the case) that their current appearance is an accident of history. That's none of your business! Obviously, your mailer should NEVER use the Return-Path: field in composing replies (except for error notification). Both addresses work. I could even argue that using a Return-Path identifier that doesn't look like a name is a good idea, precisely to discourage people from using it for ordinary replies. A local (CMU-CS-A) mail system user might have some cause to complain about the aesthetics of the outgoing fields. However, you aren't such, and have no business making that complaint. Craig Everhart
johnc@dartvax.UUCP (John Cabell) (02/08/84)
How is it that one can get rid of all the 'Recieved from...'s when listing mail? I am constantly anoyed at having to read them all the time when they don't help me for anything. --johnc
MOOERS@BBNA.ARPA (02/08/84)
From: Mark Crispin <MRC@SU-SCORE.ARPA> ...
It isn't totally unreasonable for the From or Reply fields to be a
"meaningful" address, such as "Mark.Crispin@Stanford" (which we fully
intend to support in the near future) ...
--------------------
How soon do you expect to support such an address? Is this
"institutional" host-alias name, "Stanford", likely to become a
sub-domain in a reasonable length of time? How many other
institutions have, or are planning, the same kind of
host-aliases? (We have two at BBN -- BBN, for the TENEX/TOPS-20
hosts and BBN-UNIX. There is also "OFFICE" at TYMSHARE.)
---CharlotteMishkin@YALE.ARPA (Nathaniel Mishkin) (02/09/84)
It isn't totally unreasonable for the From or Reply fields to
be a "meaningful" address, such as "Mark.Crispin@Stanford" (which
we fully intend to support in the near future) while the
"Return-Path" would be a "machine" address incorporating a login
name and physical machine, such as "MRC@SU-SCORE".
I completely agree with the goal of using "logical" names. However,
this doesn't make a virtue out of the strangeness of the "Return-Path".
If you want the functionality you say (i.e. that the recipient can
see both the user ID and the logical name of the sender), it seems
like you should use a "Sender" line and not rely on the behavior of
the "Return-Path" (whose contents are presumably not under the control
of the person/mailsystem that decides that presenting both the user
ID and the logical name is a good idea).MRC@SU-SCORE.ARPA (Mark Crispin) (02/09/84)
Your message implies that for some reason you actually care what
is in the Return-Path header line. You shouldn't. I can put whatever
I damn well please in there. If it pleases me to put in the physical
login-id/host-name in there, that's my business not yours. Any
presumption on your part that there is any relation between the
Return-Path and any other header line (including Sender!) is faulty.
It can also be argued that your mail reader is faulty for even
presenting the Return-Path information to the user. Return-Path is
in the header only to assist mail transports which don't have the
concept of out-of-band envelopes. Since you're on ARPANET, it's
irrelevant.
-------Ellis@YALE.ARPA (John R Ellis) (02/09/84)
It can also be argued that your mail reader is faulty for even
presenting the Return-Path information to the user. Return-Path is
in the header only to assist mail transports which don't have the
concept of out-of-band envelopes. Since you're on ARPANET, it's
irrelevant.
If only it were irrelevant. Unfortunately, we get a fair amount of mail
forwarded from other APRANET hosts (maybe a few messages a week) in which
the From address is unrepliable but for which the Return-Path is correct
(or at least useable). E.g.
Return-Path: <joe%NON-ARPA-HOST@HOST.ARPA>
From: joe blow <joe@NON-ARPA-HOST>
Sometimes we get mail with no From/Sender/Reply-To at all.
As long as we continue to receive mail in which the 822 text doesn't
contain a correct reply address, it is necessary for users to see the
STMP Return-Path so that they can attempt replies to such mail.
-------MRC@SU-SCORE.ARPA (Mark Crispin) (02/09/84)
John -
Good point. However, it does not mean that it is correct for a
mailsystem's Reply command to use the Return-Path. The correct behavior
is to give an error message, and let the human user figure out that
maybe the information in the Return-Path is useful. I am sick and tired
of people claiming it should be done automatically - all that would
accomplish is an ad hoc modification to the standard. That'll make the
standard even more worthless than it already is.
-- Mark --
-------Ellis@YALE.ARPA (John R Ellis) (02/10/84)
However, it does not mean that it is correct for a mailsystem's Reply
command to use the Return-Path.
In this discussion, no one, including Mishkin, has argued for this.
-------eric%ucbarpa@Berkeley.ARPA (Eric Allman) (02/17/84)
Gosh Chris, I'm awfully sorry that I have tried to do the right thing instead of perpetuating the insanity that has characterized (and sadly, continues to characterize) the UNIX mail system. Sendmail passes the information it gets from the received envelope into the transmitted envelope. If the mailer is a program rather than an SMTP channel, the "envelope" consists of the command line arguments. The version of Mail that comes with sendmail works, as does MH. This seems to cover 90% of the 4.2 users. eric
cak@Purdue.ARPA (Christopher A Kent) (02/23/84)
Eric, I stand only mildly rebuked. I agree that it is a bad thing to perpetuate the insanity that is Unix mail. (Unix vendors could note that they would do well to concentrate on developing a totally new mail system -- grad student hacking doesn't seem to be enough.) Unfortunately, the envelope information that you pass around is misleading to the many other programs that parse Unix mailboxes. It would have been simple to just use the true From address, rather than the SMTP sender information, which is of little use to 90% of the users. Programs which filter incoming mail (like msgs) present confusing return/from addresses. It seems like the whole thing could have been solved/avoided by fixing sendmail rather than having to hack on each of the programs that gets confused. chris ----------