Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 OCT 86  19:21:59 EDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU  1 Oct 86 19:20:32 EDT
Date: Wed, 1 Oct 1986  16:00 EDT
Message-ID: <SRA.12243391985.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   The lost Bostonian <gds@SPAM.ISTC.SRI.COM>
Cc:   header-people@MC.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA
Subject: SMTP, 2600, and the security of mail
In-reply-to: Msg of 30 Sep 1986  13:29-EDT from The lost Bostonian <gds@spam.istc.sri.com>

    Date: Tuesday, 30 September 1986  13:29-EDT
    From: The lost Bostonian <gds@spam.istc.sri.com>
    To:   header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa

    If it is true that all IP implementations enable a server program to
    determine the IP address of its peer, then the HELO command, and its
    response could be eliminated, which would save us a few bytes.

You are assuming that it is always possible to translate addresses to
names and vice versa.  Unfortunately, there are some people out in the
world running domain nameservers who are totally clueless about what
they are doing, and there are others who have the misfortune to be
stuck behind a losing gateway or otherwise be unreachable much of the
time.  Do you really want to make it impossible to receive mail from
some host because a third party is broken?  Or have to put numeric
addresses into the Recieved headers?

The answer is to fix the silly net, not throw away features to save
two IP packets.

--Rob

Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 14 Oct 86 05:59:42 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707120512047934@MIT-MULTICS.ARPA>; 14 Oct 1986 05:55:12 edt
Date:        05 Oct 86 15:37 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
Cc:          HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     CONFIRM-DELIVERY
Message-ID:  <206907@QZCOM>
In-Reply-To: <860924130255.410923@MIT-MULTICS.ARPA>

(a) In the case of receipt confirmation, X.420 says (sectin
4.2.2.3) that this can be implemented in two ways:
- Either automatically produce a receipt confirmation when the
recipient reads the message, or
- ask the recipient, when he has read the message, whether the
requested reciept should be sent or not.

The latter alternative seems to satisfy you objections.

(b) The main reason why I want to implement "CONFIRM-DELIVERY"
is not to make the system more X.400-compatible, but because
I feel this is an important user service. I have made some small
studies of the reliability of the academic nets in transporting
messages from ARPANET mailing lists to our computer in Sweden,
and found that the failure rate may be higher than 1 %. With
such a high failure rate in the academic nets, it seems very
important to provide senders with a facility to get a confirmation
that the message they sent has reached the mailbox of the recipient.

This could also answer your question about how to define "delivery",
which in certain local nets could be unclear. In general, it
seems better to define delivery as close to the recipient as
possible, since the error control will then reach over a larger
width of transmissions where a message can be lost. But if the
local network within a university is very very reliable, one
might envisage to send a delivery notification somewhat earlier.

The trade-off, of course, is that if you delay delivery notification
to delivery to the user work-station, and if that work-station
only occasionally connects to download mail, you will get longer
delay before the delivery-notification is sent. But is not that
still a safer bet?



Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 OCT 86  13:13:43 EDT
Received: from po3.andrew.cmu.edu by MC.LCS.MIT.EDU 15 Oct 86 13:08:49 EDT
Received: by po3.andrew.cmu.edu (4.12/3.15) id <AA00353>; Wed, 15 Oct 86 12:59:12 edt
Received: FROM apollo VIA queuemail
          ID </cmu/common/mailqs/q003/QF.apollo.1f93cac5.1>;
          Wed, 15 Oct 86 12:56:49 edt
Message-Id: <MS.V3.10.cfe.0.apollo.2051.0@andrew.cmu.edu>
Date: Wed, 15 Oct 86 12:56:29 edt
From: cfe@andrew.cmu.edu (Craig F. Everhart)
To: header-people@mc.lcs.mit.edu
Subject: Re: CONFIRM-DELIVERY


Suppose we were building a system where people could request delivery
confirmation, and we believed that we had handled the ethical questions.
Suppose we said that confirmation messages (of any of a desired set of stages
in delivery) were to be sent to a given address.  Naively, wouldn't that mean
that one would get an awful lot of mail confirming delivery?

My point is that the confirmation service should make it easy for the
original sender's mail-handling agent to match the confirmation messages to
the initial request, and that it's not (yet?) clear to me how this process
can be automated.  The most I can yet assume about confirmation messages so
far is that they are composed with an In-Reply-To: header that matches the
Message-ID: of the initial message.  But this level of service, by itself, is
inadequate, because a person replying to the message would generate a reply
message that has exactly this same property.

Did I miss some set of proposals that would explain how automatic
confirmation might work?  Or should I propose something?  If the latter,
here's a try:

A goal of automatically-generated confirmation notices should be to allow
mail-handling agents to keep track of the confirmed progress.  Thus, if I
initiate a piece of mail and ask for confirmation of a given phase of its
delivery (say, ``In-Mailbox''), I'd expect that I'd later be able to ask my
mail- handler about the status of the piece of mail--that of the N
recipients, we had received confirmation from these K, and none yet for the
remaining N-K of them.  (Yes, we can imagine elaborations of this, where if
confirmation lags for some recipients, the handler reminds me of the fact.
Subsequent proposals might allow us to ask remote delivery or user agents
whether mail was received and the confirmation message simply lost.)

Let's say that I want confirmation of In-Mailbox state.  My message might
include the headers:
	From: mumble@bar
	To: a@b, c@d, e@f
	Confirm-In-Mailbox: mumble@bar
	Message-ID: <foo@bar>
The automatically-generated confirmation from c@d might include the headers:
	From: c@d
	In-reply-to: <foo@bar>
	Confirmation-In-Mailbox: [token]
where the [token] might be ``accepted'' or ``refused'' or some such.  The
body of the message might be optional human-readable text describing the
reasons for refusal, should the refuser decide to offer any.

The automatic handler of these things then scans incoming mail for header
field names that start with ``Confirmation-'', matches the In-Reply-To:
fields against the set of messages for which not all confirmations have been
received, and matches the From: (/Sender:?) fields of the confirmation
messages against the To: list of the original message.  (This latter matching
algorithm might be quite complicated, as it's not a trivial task, but it
would reside solely in the mail-handler.)



Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 19 OCT 86  15:50:54 EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 19 Oct 86 15:49:45 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707583247563093@MIT-MULTICS.ARPA>; 19 Oct 1986 14:27:27 edt
Date:        19 Oct 86 13:43 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             header-people@MC.LCS.MIT.EDU
Subject:     Re: CONFIRM-DELIVERY
Message-ID:  <210159@QZCOM>
In-Reply-To: <MS.V3.10.cfe.0.apollo.2051.0@andrew.cmu.edu>

The problem of intelligent handling of confirmations can be split
into two parts:

(a) Formatting the text of the confirmation itself in such a
manner that it can be recognized and handled by a computer program.
You suggest an alternative for doing this in your message.

(b) Programming your local user agent to use this to provide
you with various features such as:
- Getting yourself reminded if a message has not been delivered
within a certain time interval.
- Providing you with a summary of the delivery-status of a multi-
recipient message when you ask for it, or automatically at a
certain future date.

(b) is of course a local matter, does not need standardization.
(a) does require a standardized format of confirmations. This
is already available in X.400. If we do wish to get this also
as an extension to RFC822, something like what you propose should
be used.

One problem is that more and more of messaging will be X.400,
and go via X.400<->RFC822 gateways, and the present proposal
for such gateways (RFC987) does not propose that confirmation
requests and confirmations should be passed across such gateways
(since RFC822 does not have a standard for confirmation formatting
in computer-readable form).



Received: from MIT-MULTICS.ARPA by AI.AI.MIT.EDU 20 Oct 86 19:30:21 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2707687635477331@MIT-MULTICS.ARPA>; 20 Oct 1986 19:27:15 edt
Date:        20 Oct 86 18:26 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          HEADER-PEOPLE@AI.AI.MIT.EDU, MHS_implementation@WISC-RSCH.ARPA
Cc:          AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
Bcc:         "Craig Partridge" <craig@SH.CS.NET>
Subject:     Mailing-list standard proposal
Message-ID:  <210381@QZCOM>

The AMIGO project in Europe has developed a proposal for a
standard way of handling mailing-lists. The advantage of having a
standard for mailing-list handling is that it is easier to provide
nice user services if the way mailing-lists work is standardized.
The proposal from AMIGO will also allow lists to be members of
each other circularly without looping messages.

The AMIGO proposal for mailing-lists is mainly defined in the P2
layer of X.400, but defined in such a way that it can also be used
in RFC821/822 based nets, and so that the mailing-list specific
information will be conveyed between X.400 and RFC821/822 through
gateways according to the RFC987 recommendation for gateways
between X.400 and RFC821/822.

We are fully aware that CCITT is going to standardize mailing-
lists entirely in the P1 layer of X.400, but we believe there will
be a need for P2-based mailing-lists because these can be imple-
mented (according to our proposal) without any change to the X.400
or RFC821/822 recommendations, while the CCITT recommendation,
when it is ready, will require rewriting of not only the message
systems handling mailing list expansion, but also all the systems
which carry information between two nested lists.

The AMIGO proposal contains

(a) A recommendation how the header and envelope fields (RFC821/822
information) is to be handled by a mailing-list expander.

(b) A standard for remote operations on a mailing list, such
as adding yourself or removing yourself from a remote list, getting
a list sent to you of the members of a lists, getting a list
of all mailing lists at a certain host (all of course subject
to access control). These operations are done by specially formatted
P2 or RFC822 messages, and do not require any change to the X.400
or RFC message standards.

A version of the AMIGO proposal will be available for comment
in 2-4 weeks from now, and you can request a copy by writing
to
AMIGODOC@SEARN.BITNET
or
AMIGODOC%SEARN.BITNET@WISCVM.ARPA

The proposal will be sent to you electronically unless you speci-
fically ask for a paper copy and supply your postal address.

We will in December 1986 begin pilot implementation of the AMIGO
proposal within four different message systems in France, Germany,
United Kingdom and Sweden. People outside the AMIGO project are
welcome to participate in the pilot implementation of the AMIGO
proposal for mailing-lists.




Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86  06:30:15 EST
Received: from ucbvax.berkeley.edu (TCP 1200400116) by MC.LCS.MIT.EDU 30 Oct 86 06:19:11 EST
Received: by ucbvax.berkeley.edu (5.53/1.18)
	id AA18472; Wed, 29 Oct 86 09:25:40 PST
Date: Wed, 29 Oct 86 09:25:40 PST
From: jordan@ucbvax.Berkeley.EDU (Jordan Hayes)
Message-Id: <8610291725.AA18472@ucbvax.berkeley.edu>
To: header-people@mc.lcs.mit.edu
Subject: BITNET mail

There are still a lot of people out there on the Internet trying to use
ucbvax.Berkeley.EDU as a BITNET gateway ... pretty anti-social,
if you ask me. Check your mailing lists and mailer configurations
today. Thanks.

/jordan

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 30 OCT 86  09:47:01 EST
Received: from csv.rpi.edu (TCP 30003055412) by MC.LCS.MIT.EDU 30 Oct 86 09:45:01 EST
Received: by csv.rpi.edu (5.51/1.14)
	id AA06999; Thu, 30 Oct 86 07:34:15 EST
Date: Thu, 30 Oct 86 07:34:15 EST
From: schoff@csv.rpi.edu (Martin Schoffstall)
Message-Id: <8610301234.AA06999@csv.rpi.edu>
To: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu
Subject: Re:  BITNET mail

I don't know what INTERNET people use (we use wiscvm.wisc.edu)
but I DO see BITNET people use violet.berkeley.edu when they
want to mail to the INTERNET.  Isn't this antisocial too?

Marty

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 1 NOV 86  16:45:33 EST
Received: from rsch.wisc.edu (TCP 30001201001) by MC.LCS.MIT.EDU  1 Nov 86 15:36:46 EST
Date: Sat, 1 Nov 86 14:34:22 CST
From: lhl@rsch.wisc.edu (L.H. Landweber)
Message-Id: <8611012034.AA13562@rsch.wisc.edu>
Received: by rsch.wisc.edu; Sat, 1 Nov 86 14:34:22 CST
To: schoff@csv.rpi.edu
Subject: Re:  BITNET mail
Cc: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu lhl

While it may anti-social to use bitnet/internet gateways other than wiscvm,
it certainly is rational. Each weekday we fall behind hundreds of messages
due to arpanet congestion. (We sit at one end of the most congested line
in the Arpanet.)  Most of the time these are cleared on the weekend,
but if something goes wrong at that time, large numbers of messages may
be lost (or returned to sender).  

This week i will send out an announcement that at some future date 
we will limit the number of copies of a single
message that wiscvm will relay. We will expect list
maintainers to contact someone on the other net to set up exploders.
We have offers from some to help and details will be forthcoming.
At present well over 50% of our traffic is due to mulitple copies
from lists on both sides. Hopefully, the above change will fix or at 
least ease the current problem.

Larry Landweber

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 3 NOV 86  16:39:15 EST
Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU  3 Nov 86 16:37:08 EST
Received: from jade.berkeley.edu
	by violet.berkeley.edu (5.54 (CFC 4.22.2)/1.16.3)
	id AA19875; Mon, 3 Nov 86 13:36:16 PST
Received: by jade.Berkeley.Edu (5.54 (CFC 4.22.3)/5.7.1)
	id AA17329; Mon, 3 Nov 86 13:35:56 PST
Message-Id: <8611032135.AA17329@jade.Berkeley.Edu>
Date:    Mon, 03 Nov 86 22:14 CET
To: header-people@mc.lcs.mit.edu, jordan@ucbvax.Berkeley.EDU(Jordan Hayes)
From: Peter  Sylvester +49 228 303245             <GRZ027%DBNGMD21.BITNET@violet.berkeley.edu>
Subject: Re: BITNET mail

>
> There are still a lot of people out there on the Internet trying to use
> ucbvax.Berkeley.EDU as a BITNET gateway ... pretty anti-social,
> if you ask me. Check your mailing lists and mailer configurations
> today. Thanks.
There are lots of people that use BSMTP at UCBJADE (in BITNET) as
a gateway, too. This is a relict of the fact that you sometimes
get mail via that gate and can respond only thru that gate.
If you use direct most .EDU stuff to WISCVM, you sometimes got
non delivery reports that tell you something of unknown hosts.
I do not know whether this is still true.

Where is the "official announcement" of the WISCVM gateway?

>
> /jordan
>


Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 6 NOV 86  22:53:26 EST
Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU  6 Nov 86 22:50:58 EST
Received: from jade.berkeley.edu
	by violet.berkeley.edu (5.54 (CFC 4.22.2)/1.16.3)
	id AA24525; Thu, 6 Nov 86 19:48:21 PST
Received: by jade.Berkeley.Edu (5.54 (CFC 4.22.3)/5.7.1)
	id AA22149; Thu, 6 Nov 86 19:47:46 PST
Date: Thu, 6 Nov 86 19:47:46 PST
From: netinfo%jade.Berkeley.EDU@BERKELEY.EDU (Postmaster + BITINFO)
Message-Id: <8611070347.AA22149@jade.Berkeley.Edu>
To: lhl@rsch.wisc.edu, schoff@csv.rpi.edu
Subject: Re:  BITNET mail
Cc: header-people@mc.lcs.mit.edu, jordan@ucbvax.berkeley.edu.lhl,
        usenet@ucbvax.Berkeley.EDU

One of the things that can be done to reduce the amount of list
mail going across the ARPANET/BITNET gateway to get the VM version
of USENET news completed and distributed throughout BITNET/EARN/NETNORTH
land.  This would allow list mail to be reduced to one message going
across the gateway. Only one message maximum needs to be sent
across the gateway for each news article. Numbers of messages going
across the gateway can be further reduced by using the batching feature
of USENET news.

Postmasters at sites running USENET news may want to take a look at list mail
addressed to their site.  Many ARPANET mailing lists are relayed into
the USENET news system, and users at USENET news sites should not need
to receive individual copies in addition to the USENET news copy.

We can help reduce much of this extra traffic by identifying the USENET
news group name of mailing lists in the INTEREST-GROUPS file(s) so
users will know where in USENET news to find there favorite mailing
list.

Bill Wells

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 8 NOV 86  16:31:51 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU  8 Nov 86 15:57:50 EST
Received: from UCLASSCF(MAILER) by MITVMA (Mailer X1.23) id 8294;
          Sat, 08 Nov 86 15:51:27 EST
Received: by UCLASSCF (Mailer X1.23) id 3799; Sat, 08 Nov 86 12:48:23 PST
Date: Sat, 08 Nov 86 12:47:21 PST
From: REMARCK@UCLASSCF (Marc Kriguer)
To:   header-people@mc.lcs.mit.edu
Subject: This account is scheduled to be deleted soon...

And to avoid the last-minute rush, I have to start dropping myself from
all the mailing lists I am on.  Please remove my name from the
header-people mailing list.

      Thank you very much!
          Marc Kriguer

Received: from grape.ads.ARPA (TCP 1200400070) by AI.AI.MIT.EDU 17 Nov 86 14:13:17 EST
Date: Mon, 17 Nov 86 11:07:45 pst
From: Scott J. Kramer <sjk@grape.ads.ARPA>
To: mit-erl!gildea@eddie.mit.edu
Cc: bug-gnu-emacs@prep.ai.mit.edu, header-people@ai.ai.mit.edu
Reply-To: sjk@ads.arpa
In-Reply-To: Stephen Gildea's message of Fri, 14 Nov 86 15:50:38 est <8611162119.AA16365@prep.ai.mit.edu>
Subject: rmail-reply-to-sender

Speaking of mail replies, there's an annoyance related to using a
REPLY-TO field, which I currently use because the host I'm sending
from isn't recognized on the Internet.

When the recipient responds to a message with a REPLY-TO which also
has CC addresses, the CC's are omitted in the reply; only the REPLY-TO
address is used.  RFC822 isn't specific about this; it just says "if
REPLY-TO exists, then the reply should go to the addresses indicated
in that field and not to the address(es) indicated in the FROM field."

I'm CC'ing Header-People on this since someone there may know of a way
to do what I'm trying to do (ie, have CC's get replies if I use
REPLY-TO).  From what I can tell, the only way is to have a valid FROM
field.

scott

Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 17 Nov 86 16:00:33 EST
Received: from killer-rat by nrtc-gremlin.arpa id a012430; 17 Nov 86 12:53 PST
To: sjk@ads.ARPA
cc: mit-erl!gildea@mit-eddie.ARPA, bug-gnu-emacs@prep.ai.mit.EDU, 
    header-people@ai.ai.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: rmail-reply-to-sender 
In-reply-to: Your message of Mon, 17 Nov 86 11:07:45 -0800.
Date: Mon, 17 Nov 86 12:53:50 -0800
Message-ID: <3153.532644830@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Well, only Dave Crocker knows for sure, but I think this interpretation is
correct:

New message (reply)		Old message (being replied to)
------------------		------------------------------
To:				use Reply-To: if present,
				otherwise use From: if present,
				otherwise use Sender: if present
				otherwise use Return-Path: (gag)

cc:				use To: and cc: if present
(including a cc: is at the
user's option-- some people
prefer to omit the cc:)

For an example of the rules that MH uses, look at the standard "replcomps"
file distributed with MH.  This is a "simple" formatting facility which
builds the reply draft for the user.

Note that the answer to your "have CC's get replies if I use REPLY-TO" query
depends on the recipient of the message, NOT the sender.

/mtr

Date: Mon, 17 Nov 86 16:54:34 EST
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Subject:  semantics of Reply-To:
To: sjk@ADS.ARPA
cc: HEADER-PEOPLE@AI.AI.MIT.EDU, bug-gnu-emacs@PREP.AI.MIT.EDU
In-reply-to: Msg of Mon 17 Nov 86 11:07:45 pst from Scott J. Kramer <sjk at grape.ads.arpa>
Message-ID: <[AI.AI.MIT.EDU].119419.861117.GUMBY>

    Date: Mon, 17 Nov 86 11:07:45 pst
    From: Scott J. Kramer <sjk at grape.ads.arpa>

    Speaking of mail replies, there's an annoyance related to using a
    REPLY-TO field, which I currently use because the host I'm sending
    from isn't recognized on the Internet.

    When the recipient responds to a message with a REPLY-TO which also
    has CC addresses, the CC's are omitted in the reply; only the REPLY-TO
    address is used.  RFC822 isn't specific about this; it just says "if
    REPLY-TO exists, then the reply should go to the addresses indicated
    in that field and not to the address(es) indicated in the FROM field."

    I'm CC'ing Header-People on this since someone there may know of a way
    to do what I'm trying to do (ie, have CC's get replies if I use
    REPLY-TO).  From what I can tell, the only way is to have a valid FROM
    field.

Reply-To: means send replies to this address.  If there's no Reply-to:
then your mail reader should compose a reply to the union of CC and
From.  If you're sending from a host which for some reason won't
identify itself usefully, specify a From:.  Hopefully your mailer will
set the Sender: field to be the invalid address, ut preserver the
From:.

In other words, gnu emacs is doing the right thing; you should use
From: where you now use Reply-to:.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 NOV 86  21:51:47 EST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU 17 Nov 86 21:47:23 EST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 17 Nov 86 18:41:02-PST
Date: Mon 17 Nov 86 18:25:02-PST
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: Re: rmail-reply-to-sender 
To: header-people@MC.LCS.MIT.EDU, mrose@NRTC-GREMLIN.ARPA, sjk@ADS.ARPA
cc: mit-erl!gildea@MIT-EDDIE.ARPA, bug-gnu-emacs@PREP.AI.MIT.EDU
In-Reply-To: <3153.532644830@nrtc-gremlin.arpa>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12255782689.9.MRC@PANDA>

NO!!!!!

A mail composition program must NEVER, repeat, NEVER!! generate a reply
to a Sender or a Return-Path.

A valid From field is required in all Internet messages.  The Reply-To
field overrides a From for reply purposes, but that does not eliminate
the need for a valid From field.  Nor does the presence of Sender and
Return-Path fields (neither of which have anything to do with a reply
address).

In this day and age when certain vendors are "certifying" their TCP/IP
implementations by testing them against random Unix systems, it is
vitally important that implementations which take excessive liberties
with the protocols be firmly suppressed.

-- Mark --
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 17 NOV 86  22:55:20 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 17 Nov 86 22:52:08 EST
Received: from killer-rat by nrtc-gremlin.arpa id a016065; 17 Nov 86 19:48 PST
To: Mark Crispin <MRC%PANDA@sumex-aim.ARPA>
cc: header-people@mc.lcs.mit.EDU, sjk@ads.ARPA, mit-erl!gildea@mit-eddie.ARPA, 
    bug-gnu-emacs@prep.ai.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: rmail-reply-to-sender 
In-reply-to: Your message of Mon, 17 Nov 86 18:25:02 -0800.
             <12255782689.9.MRC@PANDA> 
Date: Mon, 17 Nov 86 19:48:06 -0800
Message-ID: <4904.532669686@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Mark - there is a difference between working correctly and working.  Working
correctly is to ignore sender and return-path.  However this is not often
working.  In a perfect world with a diligent protocol police, we would
only worry about working correctly.  This proceeds from a false assumption:
there is neither perfection nor diligence in the Internet.  It is better
to know that you can fall back on sender and/or return path in case you have
to (when working on a poorly constructed message), than to just say "you
can't reply to that".  

/mtr

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86  00:11:18 EST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86  00:08:18 EST
Date: Tue, 18 Nov 86 00:10:36 EST
From: David Vinayak Wallace <GUMBY@AI.AI.MIT.EDU>
Subject:  Replying to Sender or (gasp) Return-path
To: mrose@NRTC-GREMLIN.ARPA
cc: header-people@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 17 Nov 86 19:48:06 -0800 from Marshall Rose <mrose at nrtc-gremlin.arpa>
Message-ID: <[AI.AI.MIT.EDU].119575.861118.GUMBY>

    Date: Mon, 17 Nov 86 19:48:06 -0800
    From: Marshall Rose <mrose at nrtc-gremlin.arpa>

    there is a difference between working correctly and working.  Working
    correctly is to ignore sender and return-path.  However this is not
    often working...there is neither perfection nor diligence in the
    Internet.  It is better to know that you can fall back on sender
    and/or return path in case you have to (when working on a poorly
    constructed message), than to just say "you can't reply to that".

There's a difference between DWIM and incorrectness.  Your mail handler
may reasonably complain "I can't reply to that" and ask the human for
help; it can't reasonably figure out which of From, Sender or Return-Path
might interest the user (for instance, if I want to send a message to
someone who will fix it up I might send a message to the Return-Path,
whereas in a legitimate reply I might be able to construct a valid
destination address).

For purposes of replying there isn't much difference between Return-Path,
Sender, and Subject.  They all have inappropriate semantics.  The machine
shouldn't fake out naive users by using random information.

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86  00:46:33 EST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Nov 86 00:36:29 EST
Received: from ibm.com by RELAY.CS.NET id aa12754; 17 Nov 86 18:09 EST
Date: Mon, 17 Nov 86 13:59:46 PST
From: David Alpern <Alpern@IBM.COM>
To: header-people@MC.LCS.MIT.EDU
Subject: Re: rmail-reply-to-sender
In-Reply-To: Message of Mon, 17 Nov 86 12:53:50 -0800 from
    Marshall Rose <mrose@nrtc-gremlin.arpa>

I don't believe the SENDER field should ever be used when developing
the list of addressees for a reply.  See RFC822 on this.  (Although,
I'll agree, there are times....  My own reply code will use the SENDER
field only if an explicit option is given by the replying human.)

- Dave

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86  03:43:22 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 18 Nov 86 03:40:17 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a018430; 18 Nov 86 0:36 PST
To: David Vinayak Wallace <GUMBY@ai.ai.mit.EDU>
cc: header-people@mc.lcs.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: Replying to Sender or (gasp) Return-path 
In-reply-to: Your message of Tue, 18 Nov 86 00:10:36 -0500.
             <[AI.AI.MIT.EDU].119575.861118.GUMBY> 
Date: Tue, 18 Nov 86 00:36:43 -0800
Message-ID: <18426.532687003@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

    This is NOT, repeat NOT, a case of DWIM.  The issue is simple:  mail
    composers should use "reply-to if" they want to redirect replies
    that would normally go to the "from" field; mail repliers should
    honor "reply-to" over "from", but need to be able to do something if
    neither field is present.  This is yet another example of the trite
    "be conservative in what you send, liberal in what you accept".  

    This emphasizes the key point of my original message:  the sender
    can use "reply-to", but it is upto the receiver to do the right
    thing.  The right thing is to use "reply-to" or "from" for the
    primary recipient(s) of the reply.  There is no concrete right thing
    for generating the list of secondary recipients (usually to and cc
    are the right thing, at the user's option).  For example, my
    original message had a "reply-to" of header-people, and my mailbox
    did NOT appear anywhere in the message except for "from".  I assume
    that Mark explicitly added my address to his reply.  In this case
    the mail composer used "reply-to" to redirect replies, and the mail
    replier did not honor this protocol.  

    A final note:  do not, as your previous message suggests, mistake
    the operation of replying with other message-handling functions
    (e.g., forwarding, and so on).  If you want to send the message to
    someone who will fix it up, you are NOT replying to the message.
    You are sending a message with a different purpose, not a reply to
    the original!

/mtr

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86  11:25:29 EST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU 18 Nov 86 11:22:24 EST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Nov 86 08:16:28-PST
Date: Tue 18 Nov 86 07:57:08-PST
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: Re: Replying to Sender or (gasp) Return-path 
To: header-people@MC.LCS.MIT.EDU
In-Reply-To: <18426.532687003@nrtc-gremlin.arpa>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12255930529.7.MRC@PANDA>

Marshall -

     The Internet mail world is not yet such that it is impossible
to use a mail system that obeys RFC 822 when it comes to the
semantics of replying.  The only reason for adding Return-Path to
your mail user agent's REPLY parser is laziness on the part of the
mail maintainer -- that is, he is unwilling to handle the problems
which occasionally come up and explain the realities of mail to a
user who thinks that the reply address is "always" available in a
Return-Path.

     Various vendors then "validate" their mail software against
this lazy software, since it's located on a Unix and everybody is
running Unix so it must be right...  Then the poor maintainers of
non-Unix software get long, pendantic complaint letters from the
above-mentioned vendors (or their users) stating everything imaginable
about the Internet protocols except the facts.  Wollongong is a
worst case, but not the only case.

     I don't want to argue English semantics, but "be conservative
in what you send" sure means to me that you should be conservative
and not send replies to the Return-Path.  What's more, replying to
the Return-Path is explicitly forbidden by RFC 822.
-------

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86  14:21:29 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU 18 Nov 86 14:18:28 EST
Received: from killer-rat by nrtc-gremlin.arpa id a020495; 18 Nov 86 11:15 PST
To: Mark Crispin <MRC%PANDA@sumex-aim.ARPA>
cc: header-people@mc.lcs.mit.EDU
reply-to: header-people@mc.lcs.mit.EDU
Subject: Re: Replying to Sender or (gasp) Return-path 
In-reply-to: Your message of Tue, 18 Nov 86 07:57:08 -0800.
             <12255930529.7.MRC@PANDA> 
Date: Tue, 18 Nov 86 11:15:08 -0800
Message-ID: <6660.532725308@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Mark:

	If what we are arguing here is "validation", then I appologize.
	I am not talking about validation.  I agree with your argument
	that validating against lazy software is wrong.

/mtr

Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 18 Nov 86 15:06:39 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710180402874677@MIT-MULTICS.ARPA>; 18 Nov 1986 14:53:22 est
Date:        18 Nov 86 18:47 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA
Cc:          bug-gnu-emacs@PREP.AI.MIT.EDU, HEADER-PEOPLE@AI.AI.MIT.EDU,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     reply-to
Message-ID:  <218147@QZCOM>
In-Reply-To: <218025@QZCOM>

> FROM: Scott J. Kramer <sjk@grape.ads.ARPA>
>
> When the recipient responds to a message with a REPLY-TO which also
> has CC addresses, the CC's are omitted in the reply; only the REPLY-TO
> address is used.  RFC822 isn't specific about this; it just says "if
> REPLY-TO exists, then the reply should go to the addresses indicated
> in that field and not to the address(es) indicated in the FROM field."
>
> I'm CC'ing Header-People on this since someone there may know of a way
> to do what I'm trying to do (ie, have CC's get replies if I use
> REPLY-TO).  From what I can tell, the only way is to have a valid FROM
> field.

Hear! Hear!

The solution to your problem is something I have been arguing
for for a long time, but not yet got enough people convinced
of. There should be two different "reply-to" fields, with different
names, one to serve as a replacement for the originator only, and
one to serve as a replacement for all recipients.

Thus, if your mail system, as many of them have, has two commands
to write replies, one for replies only to the originator, and one
for replies to all recipients, then the first command should use
the value from one of the two "reply-to" fields, and the
other should use the value from the other kind of "reply-to" field.

Jacob Palme, QZ Computer Center, Stockholm, Sweden




Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 18 Nov 86 19:49:07 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710197129684579@MIT-MULTICS.ARPA>; 18 Nov 1986 19:32:09 est
Date:        18 Nov 86 18:47 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA
Cc:          bug-gnu-emacs@PREP.AI.MIT.EDU, HEADER-PEOPLE@AI.AI.MIT.EDU,
             AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject:     reply-to
Message-ID:  <218147@QZCOM>
In-Reply-To: <218025@QZCOM>

> FROM: Scott J. Kramer <sjk@grape.ads.ARPA>
>
> When the recipient responds to a message with a REPLY-TO which also
> has CC addresses, the CC's are omitted in the reply; only the REPLY-TO
> address is used.  RFC822 isn't specific about this; it just says "if
> REPLY-TO exists, then the reply should go to the addresses indicated
> in that field and not to the address(es) indicated in the FROM field."
>
> I'm CC'ing Header-People on this since someone there may know of a way
> to do what I'm trying to do (ie, have CC's get replies if I use
> REPLY-TO).  From what I can tell, the only way is to have a valid FROM
> field.

Hear! Hear!

The solution to your problem is something I have been arguing
for for a long time, but not yet got enough people convinced
of. There should be two different "reply-to" fields, with different
names, one to serve as a replacement for the originator only, and
one to serve as a replacement for all recipients.

Thus, if your mail system, as many of them have, has two commands
to write replies, one for replies only to the originator, and one
for replies to all recipients, then the first command should use
the value from one of the two "reply-to" fields, and the
other should use the value from the other kind of "reply-to" field.

Jacob Palme, QZ Computer Center, Stockholm, Sweden




Received: from SRI-NIC.ARPA (TCP 1200000063) by AI.AI.MIT.EDU 18 Nov 86 23:47:48 EST
Date: Tue 18 Nov 86 20:21:57-PST
From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
Subject: Re: reply-to
To: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc: Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    mit-erl!gildea@MIT-EDDIE.ARPA, sjk@ADS.ARPA, bug-gnu-emacs@PREP.AI.MIT.EDU,
    HEADER-PEOPLE@AI.AI.MIT.EDU, AMIGO_Group%QZCOM.MAILNET@MIT-MULTICS.ARPA,
    OLE@SRI-NIC.ARPA
In-Reply-To: <218147@QZCOM>
SRI-International: +1 (415) 859-4536  Home: +1 (415) 325-9427 
Message-ID: <12256066120.25.OLE@SRI-NIC.ARPA>


Jakob,
	I'll have to totally disagree with you on this, Scandinavian
loyalty or not. The issue of who your reply goes to is a matter of
taste and choice depending on the circumstances. I believe it SHOULD
NOT be made part of any protocol, but SHOULD be an option in your
local User Agent. When I started to reply to your message a couple of
minutes ago, my user agent (MM) very cleverly asked me if I wanted to
reply to "sender only" or "all". I think this (thanks to Mark
Crispin!) is exactly the right thing to do. Why add new fields to RFC
822 when you can have smarter user agents?

	I assure you that I am not the only person who has been burnt
by the "reply" function over the last ten years or so. Sometimes you
want your reply to go to "all", while other times you definitely don't.
The trouble is that so many user agents decide what "The Right Thing"
is for you and don't give you the option.


Ole
-------

Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 19 Nov 86 14:27:13 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2710264711211617@MIT-MULTICS.ARPA>; 19 Nov 1986 14:18:31 est
Date:        19 Nov 86 17:27 +0100
From:        Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-to:    Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     Reply-to
Message-ID:  <218423@QZCOM>
In-Reply-To: <12256066120.25.OLE@SRI-NIC.ARPA>

> FROM: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
>
> Jakob,
>     I'll have to totally disagree with you on this, Scandinavian
> loyalty or not. The issue of who your reply goes to is a matter of
> taste and choice depending on the circumstances. I believe it SHOULD
> NOT be made part of any protocol, but SHOULD be an option in your
> local User Agent. When I started to reply to your message a couple of
> minutes ago, my user agent (MM) very cleverly asked me if I wanted to
> reply to "sender only" or "all". I think this (thanks to Mark
> Crispin!) is exactly the right thing to do. Why add new fields to RFC
> 822 when you can have smarter user agents?
>
>     I assure you that I am not the only person who has been burnt
> by the "reply" function over the last ten years or so. Sometimes you
> want your reply to go to "all", while other times you definitely don't.
> The trouble is that so many user agents decide what "The Right Thing"
> is for you and don't give you the option.

Was this a statement of disagreement with anything I wrote?

But I agree completely with you that decisions on where to send a
reply should be up to the writer of the reply, aided by his user
agent. Since two common alternatives is to send a reply to either
only the originator, or to all recipients of the commented
message, so many systems provide simple commands for those two
alternatives which is very good.

You are questioning whether the mail protocols should contain any
support for this at all. However, there may be cases where the sender
or the system of the sender wishes to indicate that replies should
be redirected. Examples:

(1) Replies to the sender only may be redirected to the secretary
of the sender, some special folder for collecting replies to a
certain question etc.

(2) Replies to all may be redirected to avoid duplicates (do not
send me a personal copy, I will get it via the list) or because
some CC recipient with only marginal interest does not want to get
all the replies.

Since there are completely different needs for redirection in
case of replies to the originator and replies to the whole group,
there is a need for two different kinds of "Reply-to" header fields,
one for each kind of reply.

It is of course always up to the writer of the reply and his
UA to decide to which extent they want to heed the advice in
the reply-to fields. No one should be forced to send a reply
to any particular address.




Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 NOV 86  14:24:48 EST
Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 20 Nov 86 14:24:19 EST
Received: from hplms1. by hplabs.HP.COM ; Thu, 20 Nov 86 09:04:21 pst
Received: from hpldat (hpldat) by hplms1; Tue, 18 Nov 86 09:44:08 pst
Return-Path: <taylor@hpldat>
Received: by hpldat ; Wed, 19 Nov 86 16:58:14 pst
Message-Id: <8611200058.AA13911@hpldat>
To: Header-People@mit-mc (The Header People Mailing List)
Date: Wed, 19 Nov 86 16:58:11 PST
From: Dave Taylor <taylor%hpldat@hplabs.HP.COM>
Subject: The current Reply-To: discussion
Organization: Hewlett-Packard Laboratories, Unix Networking Group
Work-Phone-Number: +1 415 857-6887
X-Mailer: Elm [version 1.4]

I think we're all missing the point here...

there are *two* different things being argued currently - one is
a low-level question of how to deal with headers, and the other is
a higher-level question of how to present the results of the header
parsing/munging to the end user.

I think that the low level questions are set out in a reasonably
straightforward manner in '822.  My personal belief (and "elm" is
a result of this) is that the Reply-To: address is a sign of
mutual exclusion - if it's present, that's the *only* address you
reply to, by default.  If you "Group reply" to a message that contains
a Reply-To: header, elm will build a return address based on the
address in the reply-to field and the To: and Cc: list (stripping out
the recipients address, of course).   If the Reply-To: isn't present,
the program will either use the From: address or the results of its
own parsing of the "From_" lines at the top of the message (the results
of those dumb AT&T mail transport systems).

At the user level, they merely know that if they use "reply" that
it will go to the appropriate person, and if they use "group reply" it
will be sent to the "reply" address AND the list of people who received
the original message.  

A wrinkle is added when we start to consider the reliability of information
in the From: and Reply-To: fields...Any mail not from a "real" internet
site has a high likelihood of having an invalid due to omission address.
So how to deal with it?  I don't think we can assume that we can get
the host and login of the ultimate destination machine and route from 
there (e.g. ignore the path the message took) - therein lies painful
death if we have no path, an old path, or, horrors! multiple hosts with
the same name.

Once we get domains fully implemented I anticipate a lot of this hassle
going away, since all addresses will either fully specified by the
sending machine (e.g. "To: taylor" would leave my machine as 
"To: taylor@hpldat.HPL.HP.COM") or by the user (via aliases, I hope!)
as in "To: woodward@scfac" -> "To: woodward@scfac.DEC.COM" etc).  This
also leads to a question of how do we deal with incorrectly specified
domains (e.g. "hpldat.HP.COM") but that's a different story entirely!!

The way the elm gets around this problem is that the default configuration
*ignores* the From: and Reply-To: addresses and simply traces back the
sending route.  The system administrator, installing the program, has to
decide if the addresses contained therein are valid or not (since the 
program sure can't!!).

Anyone have any comments on this user-level .vs. system-level restatement
of the problem??

	[I *don't* think another header is needed!  Gad!  We already have
         enough that it's a bloody pain to figure out the precedence of
	 them all (e.g. From, Sender etc).  "Return-Path:" is ignored in
	 elm because I think it's a bogus header...]

						-- Dave Taylor

						taylor@hplabs.HP.COM

Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 20 NOV 86  15:16:44 EST
Received: from LOKI.BBN.COM (TCP 20026200116) by MC.LCS.MIT.EDU 20 Nov 86 15:10:42 EST
To: header-people@mc.lcs.mit.edu
Subject: Use of Reply-To
Date: Thu, 20 Nov 86 15:08:56 -0500
From: Craig Partridge <craig@loki.bbn.com>


    I do want to point out that the Reply-To can contain multiple
addresses.  If you wanted to incorporate everyone in your cc
list in your Reply-To as well, you are supposed to be able to.

Craig Partridge
CSNET Technical Staff

Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  2 Dec 86 17:06:15 EST
Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 2725;
          Tue, 02 Dec 86 17:01:14 EST
Date: 2 Dec 1986 16:45:17-EST (Tuesday)
From: "Victor S. Miller" <VICTOR@YKTVMX>
To: HEADER-PEOPLE@AI.AI.MIT.EDU
Subject: Redistribution lists

Recently I became the moderator for TheoryNet (a bulletin board for
theoretical computer science).  Every time I post a submission, I get
a large number of error messages from various mail delivery agents around
the world.  Most of them concern recipients who are on redistribution lists
at various sites.  I would think that it would be better for these messages
to go to the local postmaster, or maintainer of the list (they can do
something about them).  How can I arrange that this happens?  Another
thing that I have noticed, is that quite a large number of the recipients
who cause errors are not local recipients.  It would be nice if these names
weren't on the list to begin with.  What I'm leading up to, is that it
would be nice if there were some organized way of finding out who is
responsible for these mailing lists.  At the very least, it would be nice
if the error messages indicated the userid of the original recipient,
since it is not always easy to figure out who it was.
                            Victor S. Miller

Received: from gjetost.wisc.edu (TCP 30003006041) by AI.AI.MIT.EDU  3 Dec 86 07:22:36 EST
Date: Wed, 3 Dec 86 06:21:18 CST
From: solomon@gjetost.wisc.edu (Marvin Solomon)
Message-Id: <8612031221.AA01360@gjetost.wisc.edu>
Received: by gjetost.wisc.edu; Wed, 3 Dec 86 06:21:18 CST
To: VICTOR%yktvmx.bitnet@wiscvm.wisc.edu
Subject: Re:  Redistribution lists
Cc: HEADER-PEOPLE@ai.ai.mit.edu

With regard to your original question:  This subject has been discussed
in this forum many times before and the answer is not simple.
In your situation, there are three parties of interest:  the submitter,
the list maintainer, and the maintainer of a redistribution list
(e.g. joe@randomsite sends to theorynet@yktvmx which relays to
theory-net-local@podunk-u which relays to random-reader@podunk-u;
the three people are joe, the maintainer of theorynet, and the maintainer
of theory-net-local).  Error messages should NEVER go to joe.  If
theory-net-local is somehow broken, the theorynet maintainer should
find out.  If ramdom-reader removes his account, the maintainer
of theory-net-local should find out.

How do you do that?  If the theorynet relay is on the Arpa Internet,
it is sending its mail via SMTP, which is a dialogue that introduces
each message with a
	MAIL FROM:<xxx@yyy.zzz>
command.  Normally, if the SMTP receiver has problems, it will either
reject the message outright, or send back the error message to xxx@yyy.zzz.
Note that the same applies to theory-net-local, although the maintainer
of theory-net has no way to make the maintainer of theory-net-local
do the "right thing".  Similar remarks apply to BITNET if BSMTP (batch SMTP)
is in use.  How do you get the right thing into the SMTP MAIL FROM command?
That's highly system-dependent.  Talk to your mail guru.  (Barry Appleman
is a good choice at Yorktown).

What about headers?  You have a better chance of getting the right
results if the message has lines
	Reply-to: <joe@randomsite>
	Sender: <theorynet-request@yktvmx>
or
	Sender: <theory-net-local-request@podunk-u>
thus, the redistribution software should put the original sender into
the Reply-to: field and put the list maintainer in the Sender: field.
(A common convention is to give the maintainer of "list" the alias
"list-request".)

Now for something slightly different.  The "From:" address in your question
is illegal (as are most of the examples above).  Host names should be
globally unique, but your "From:" address is <VICTOR@yktmvx>.  How
do you know that there isn't some other "yktvmx" in the universe?
The host name "should" be something like "yktvmx.ibm.com" (which would
identify it as the unique yktvmx in the unique ibm in the commercial domain).
In the current state of affairs, a more practical solution would be
for your return address to be
	Reply-to: <VICTOR%yktvmx.bitnet@wiscvm.wisc.edu>
which says that you are on the unique yktvmx in bitnet, but since
Internet hosts are unlikely to understand that, replies should be
sent to wiscvm.wisc.edu for relay into bitnet.

Who is at fault?  Either the software on yktvmx that you used to create
that header in the first place, or the hosts that first transferred the
message out of BITNET and into the Internet.  From the headers on your
message, that would seem to be mitvma.bitnet and/or mit-multics.arpa.

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  4 Dec 86 06:16:06 EST
Date: Thu,  4 Dec 86 06:15:09 EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: [Forwarded: AKLOM@BITNIC, Re: Moving ARPAnet SIGS to BITNET.]
To: header-mins@MC.LCS.MIT.EDU
Message-ID: <126294.861204.CENT@AI.AI.MIT.EDU>

Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  2 Dec 86 19:53:44 EST
Received: from BITNIC(MAILER) by MITVMA (Mailer X1.23) id 3130;
          Tue, 02 Dec 86 18:54:11 EST
Received: by BITNIC (Mailer X1.23b) id 0487; Tue, 02 Dec 86 18:49:18 EST
Date:         Tue, 02 Dec 86 18:53:44 EST
From:         Judith Molka <AKLOM@BITNIC>
Subject:      Moving ARPAnet SIGS to BITNET.
To: MICHAEL S. MAITEN <MSM@MC.LCS.MIT.EDU>, HOBBIT <AWALKER@RUTGERS.ARPA>,
    RICH ZELLICH <ZELLICH@SRI-NIC.ARPA>, JAKE FEINLER
    <FEINLER@SRI-NIC.ARPA>, LARRY LANDWEBER <LHL@WISCVM>, CHARLOTTE MOORE
    <CIC@SH.CS.NET>, ALAN BAWDEN <ALAN@AI.AI.MIT.EDU>, ANDREW GIDEON
    <GIDEON@SU-SCORE.ARPA>, ANDREW KNUTSEN <KNUTSEN@SRI-UNIX.ARPA>, ANDREW
    MOORE <T.MOORE%MIT-EECS@MIT-EDDIE.MIT.EDU>, ANDY CROMARTY
    <ANDY@ADS.ARPA>, ANN WESTINE <WESTINE@USC-ISIB.ARPA>, BILL BOGSTAD
    <BOGSTAD@HOPKINS-EECS-BRAVO.ARPA>, BILL MITCHELL
    <WHM%ARIZONA.CSNET@CSNET-RELAY>, BOB PUYEAR <NU025213@NDSUVM1>, BRAD
    SAGARIN <DRAGON@RINSO.LCS.MIT.EDU>, BRIAN KANTOR
    <BRIAN@SDCSVAX.UCSD.EDU>, BRUCE NEMNICH <BRUCE@THINK.COM>, CHRIS CONDON
    <BITLIB@YALEVMX>, CHRISTOPHER SCHMIDT <SCHMIDT@SUMEX-AIM.STANFORD.EDU>,
    CHUQ VON ROSPACH <CHUQ@SUN.COM.ARPA>, CLIFFORD NEUMAN
    <BCN@MIT-EDDIE.ARPA>, CRAIG ANDERSON <ANDERSON.ES@XEROX.ARPA>, DAVE
    STEINER <STEINER@RUTGERS.ARPA>, DAVE TAYLOR <TAYLOR@HPLABS.ARPA>, DAVID
    C. PLUMMER <DCP@MC.LCS.MIT.EDU>, DAVID E. TOWSON <TOWSON@AMSAA.ARPA>,
    DAVID FUCHS <DRF@SU-SCORE.ARPA>, DICK KOOLISH <KOOLISH@BBN-UNIX.ARPA>,
    DON STONE <DS@SEI.CMU.EDU>, DOUG ALAN <NESSUS@MIT-EDDIE.ARPA>, DR.
    KENNETH I. LAWS <LAWS@SRI-AI.ARPA>, ED FOX
    <FOX%VPI.CSNET@CSNET-RELAY.ARPA>, EINAR STEFFERUD
    <ESTEFFERUD@USC-ECL.ARPA>, ELIOT MOORE <ELMO@MC.LCS.MIT.EDU>, ERIC
    LAVITSKY <LAVITSKY@RED.RUTGERS.EDU>, <E1AR0002@SMUVM1>, FRANK J. WANCHO
    <WANCHO@SIMTEL20.ARPA>, FRANK WANCHO <WANCHO@SIMTEL20.ARPA>, FREDERICK
    S. BRUNDICK <FSBRN@BRL.ARPA>, GARY DELP <DELP@HUEY.UDEL.EDU>, GEORGE
    HARTWIG <GEO@BRL.ARPA>, GEORGE ROBBINS <CBMVAX!GRR@SEISMO.CSS.GOV>,
    GERN <GERN@RADC-TOPS20.ARPA>, GLEN DANIELS
    <MLY.G.DANIELS%MIT-OZ@MC.LCS.MIT.EDU>, GLENN S. BURKE
    <GSB@MC.LCS.MIT.EDU>, GREGOR J. KICZALES <GREGOR.PA@XEROX.COM>, GREGORY
    G. FINN <FINN@USC-ISIB.ARPA>, HENRY NUSSBACHER <HANK@BARILVM>, HOWARD
    WALTER <HOWARD@BRL.ARPA>, J.Q. JOHNSON <JQJ@CORNELL.ARPA>, JACOB PALME
    <JACOB_PALME_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA>, JIM GETTYS
    <JG@ATHENA.MIT.EDU>, JOHN BRUGGE <BRUGGE@SUMEX-AIM.STANFORD.EDU>, JOHN
    FODERARO <JKF@BERKELEY.ARPA>, JOHN LEKASHMAN <LEKASH@AMES-NASB.ARPA>,
    JOHN MALLERY <JCMA@MC.LCS.MIT.EDU>, JOHN MARK AGOSTA
    <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>, JOHN MITCHENER
    <JMITCHENER@SIMTEL20.ARPA>, JOHN ROBINSON <JR@BBNCC5.ARPA>, JONATHAN
    REES <JAR@MC.LCS.MIT.EDU>, JOSEPH GUIRRERI <OJCS-JAD@STL-HOST1.ARPA>,
    <JUP.WELCH@AMES-VMSB.ARPA>, KARL A. NYBERG <NYBERG@USC-ISIF.ARPA>,
    KEITH A. LANTZ <LANTZ@SU-GREGORIO.ARPA>, KEITH PETERSEN
    <KPETERSEN@SIMTEL20.ARPA>, KEN ROSSEN <KROSSEN@CCP.BBN.COM>, KEN VAN
    CAMP <KVANCAMP@ARDEC.ARPA>, KEN YAP
    <KEN%UR-SENECA.LOCAL@ROCHESTER.ARPA>, <KING@KESTREL.ARPA>, LARRY SEWARD
    <LSEWARD@RAND-UNIX.ARPA>, LISTSERV EDITOR <EDITOR@UCF1VM>, LIUDVIKAS
    BUKYS <BUKYS@ROCHESTER.ARPA>, <LWA@MC.LCS.MIT.EDU>, MARK CRISPIN
    <ADMIN.MRC@SU-SCORE.ARPA>, MARK PLOTNICK <INFO-C-REQUEST@BRL.ARPA>,
    MARK RICHER <RICHER@SUMEX-AIM.ARPA>, MARK S. DAY <MDAY@XX.LCS.MIT.EDU>,
    MARK WEISER <MARK@MARYLAND.ARPA>, MARLA BAER-PECKHAM
    <SSC-VAX!MARLA@UW-BEAVER.ARPA>, MARSHALL T. ROSE
    <BUG-ISODE@NRTC.NORTHROP.COM>, MARVIN M. ZAUDERER
    <ZAUDERER@SU-SUSHI.ARPA>, MATT KIMMEL <MATT@UMASS>, MATTHEW SAROFF
    <SAROFF@UMASS>, MEL PLEASANT <PLEASANT@RUTGERS.ARPA>, MICHAEL A. PATTON
    <MAP%MIT-AI.ARPA@MC.LCS.MIT.EDU>, MICHAEL BROWNE <MCB@K.CS.CMU.EDU>,
    MICHAEL HABERLER <HABERLER@SU-SIERRA.ARPA>, MIKE MEYER
    <MWM%UCBOPAL@BERKELEY.EDU>, MIKE MUUSS <INFO-LAW-REQUEST@BRL.ARPA>,
    NATHANIEL MISHKIN <MISHKIN@YALE.ARPA>, ODED FEINGOLD
    <AVIATION-REQUEST@MC.LCS.MIT.EDU>, OWEN T. ANDERSON
    <OTA@SAIL.STANFORD.EDU>, PANDORA B. BERMAN <CENT@AI.AI.MIT.EDU>, PAUL
    POMES <PAUL@UIUCUXC.CSO.UIUC.EDU>, PETER G. NEUMANN
    <NEUMANN@SRI-CSL.ARPA>, PRAVEEN KUMAR <PHAEDRUS@ENEEVAX.UMD.EDU>, RALPH
    G. SBRAGIA <RALPH@UMASS>, RALPH W. HYRE, JR. <RALPHW@C.CS.CMU.EDU>,
    RAMON CURIEL <RAY@SRI-KL.ARPA>, RICH KULAWIEC <RSK@J.CC.PURDUE.EDU>,
    RICHARD ACUFF <ACUFF@SUMEX-AIM.ARPA>, RICHARD FURUTA
    <FURUTA@WASHINGTON.ARPA>, RICK CONN <RCONN@SIMTEL20.ARPA>, ROBERT L.
    KRAWITZ <RLK@ATHENA.MIT.EDU>, RON NATALIE <RON@BRL.ARPA>, S. W. GALLEY
    <SWG@XX.LCS.MIT.EDU>, SCOTT BRIM <SWB@DEVVAX.TN.CORNELL.EDU>, SCOTT
    CAMPBELL <SCOTT@UTORONTO>, STEPHEN PAGE
    <SDPAGE%SEVAX.PRG.OXFORD.AC.UK@CS.UCL.AC.UK>, STEVE STRASSMANN
    <STRAZ@MEDIA-LAB.MIT.EDU>, STEW RUBENSTEIN <LHASA!STEW@HARVARD.ARPA>,
    SUSAN TABRON <TABRON@SIMTEL20.ARPA>, TAMIR WEINER <UMFORTH@WEIZMANN>,
    TODD BOOTH <CSDCTGB@UCLA-CCN.ARPA>, VINCE FULLER <VAF@C.CS.CMU.EDU>,
    VIVIAN NEOU <VIVIAN@SRI-NIC.ARPA>, WALT <HAAS@UTAH-20.ARPA>

The following is a message sent from Larry Landweber, coordinator of the
Wisconsin Gateway to ARPAnet and BITNET List Administrators.

"Because of Arpanet congestion problems, our WISCVM mail relay is unable to
keep up with the quantity of mail sent to it for forwarding. While the
problem is particularly acute in the Bitnet to Arpanet direction, the level
of traffic in both directions is a problem.  A large part of this traffic
results from mailing lists.  Furthermore, while we are usually only sent a
single copy of a list mailing, the recipient list is often very long.  A
single message may require the sending of over a hundred copies <over
BITNET.> This is a problem for two reasons... Arpanet congesion makes it
difficult at times to establish and keep TCP connections and such
connections are slow; second, the implementation of the gateway at present
makes multiple copies for forwarding <to BITNET> (a poor design choice that
is being worked on).  At present, the first problem is far important.

Note that in a about a month we will begin limiting the number of copies we
will relay by putting a limit on the number of recipients in RCPT TO lines
in SMTP and BSMTP.  This limit is likely to be 10.

Thanks in advance for your cooperation in this matter.

Larry Landweber"

The BITNET Network Information Center has been working with Larry Landweber
on the problem discussed above.  If your Special Interest Group does not
have a BITNET site willing to create a sub-list to maintain your BITNET
subscribers, then we will assist in finding you a site.  If you have found
a BITNET site to host your sub-lists, then please send the name of your SIG
and the name of the BITNET sub-list to AKLOM@BITNIC.  This information is
needed by Rich Zellich to update the ARPANET SIGs file.  The BITNIC will
coordinate the efforts of those on the network who are working on
distribution lists.  This includes working with Rich Zellich to provide
instructions in ARPANET SIGs of where users should subscribe for each list,
helping the maintainers of the sub-lists in obtaining existing
subscriptions from the ARPAnet coordinators and contacting the SRI-NIC to
help us set up lists for the ARPAnet subscribers to BITNET lists.

These are the ARPAnet SIGs which we are aware of that have BITNET sub-lists
in operation.

     ARPAnet list                           BITNET list
     ----------------------------------     --------------------
     INFO-VAX@SRI-KL.ARPA                   INFO-VAX@UGA
     INFO-IBMPC@C.ISI.EDU                   I-IBMPC@UGA
     INFO-KERMIT@CU20B.COLUMBIA.EDU         I-KERMIT@UGA
     SF-LOVERS@RED.RUTGERS.EDU              SFLOVERS@UGA
     SECURITY@RED.RUTGERS.EDU               SECURITY@UGA
     INFO-HZ100@RADC-TOPS20.ARPA            INF-Z100@CLVM
     UNIX-SOURCES@BRL.ARPA                  UNIX-SRC@CLVM
     INFO-NETS%MIT-OZ@MC.LCS.MIT.EDU        INFONETS@BITNIC

--Judy Molka, BITNET Network Information Center


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  4 Dec 86 08:54:19 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  4 Dec 86 08:52:59 EST
Received: from AI.AI.MIT.EDU by MIT-MULTICS.ARPA TCP; 04-Dec-1986 08:52:02-est
Date: Thu,  4 Dec 86 06:32:17 EST
From: header-people-request@AI.AI.MIT.EDU
Sender: CENT@AI.AI.MIT.EDU
Subject: 4 POINTS OF ADMINISTRIVIA -- LISTEN UP FOLKS
To: HEADER-PEOPLE@AI.AI.MIT.EDU
cc: HEADER-PEOPLE-REQUEST@AI.AI.MIT.EDU,
    aklom%bitnic%mitvma@MULTICS.MIT.EDU, zellich@SRI-NIC.ARPA,
    lhl@WISCVM.WISC.EDU, RMXJ%CORNELLC.BITNET@WISCVM.WISC.EDU
Message-ID: <126300.861204.CENT@AI.AI.MIT.EDU>

1. Due to the increased usage of MIT-AI, HEADER-PEOPLE, its archives, and
its auxiliary -REQUEST list have moved (back) to (the new) MIT-MC.  The
forwarding pointers on AI are all in place, so this change should be
reasonably transparent (1 more Received: line) for people who mail to the
old address, but everyone is urged to mail directly to MC in an effort to
lighten the total network mail load.  All archives, HEADER MINS00 through
MINS15 (back to 1977!), as well as the recent mail, HEADER MINS, live on
the KSC; directory on MC.LCS.MIT.EDU, and are trivially accessible over the
Arpanet via FTP.  People on other nets who want to see the archives: well,
mostly you should try to get assistance from your friends on net gateway
machines to ship these files through.  But if you can't find any such
acquaintances and are desperate, you can send mail to HEADER-PEOPLE-REQUEST
and try to twist my arm.

2. To reiterate: The chief maintainer of HEADER-PEOPLE does not participate
in the discussion (I'm otherwise busy), so any add/remove/change requests
sent to HEADER-PEOPLE are only an annoyance to other list members.  Please
send such to HEADER-PEOPLE-REQUEST.  HEADER-PEOPLE is maintained but not
moderated, and the master list lives on an ITS, so its primary distribution
is through COMSAT; this means you, the original msg authors, get all those
nasty error reports about non-existent addresses, etc.  Sorry.  Forward
them along to HEADER-PEOPLE-REQUEST and they will get taken care of,
quickly -- I know just how much you feel about junk filling your mailbox.

3. There was, briefly, a problem with some list addresses at Berkeley; the
list referred to the host as merely BERKELEY, when that nickname had been
removed from the relevant host tables.  Some well-intentioned soul replaced
all occurences of BERKELEY in the list file with BERKELEY.EDU.  Thank you,
whoever you are, for trying -- but you did it wrong.  One address was
already a BERKELEY.EDU, so you broke it by adding an extra .EDU; also, you
fucked up the history section of the file.  And you didn't give anyone any
indication that you had done anything to the list.  HEADER-PEOPLE-REQUEST
does exist for a reason; the next time you feel moved to modify the list,
please drop us a line, so we know what's happening and can vet your
changes.

4. WISCVM, the chief ARPANET/BITNET gateway, is getting snowed under:
    Date: 14 November 86 18:33 EST
    To:      ARPANET and BITNET List Administrators
    From:    Larry Landweber  <LHL @ WISCVM.WISC.EDU>
    Subject: WISCVM Mail Relay
    Because of Arpanet congestion problems, our WISCVM mail relay is unable
    to keep up with the quantity of mail sent to it for forwarding. While
    the problem is particularly acute in the Bitnet to Arpanet direction,
    the level of traffic in both directions is a problem.  A large part of
    this traffic results from mailing lists.  Furthermore, while we are
    usually only sent a single copy of a list mailing, the recipient list
    is often very long.  A single message may require the sending of over a
    hundred copies. This is a problem for two reasons... Arpanet congesion
    makes it difficult at times to establish and keep TCP connections and
    such connections are slow; second, the implementation of the gateway at
    present makes multiple copies for forwarding (a poor design choice that
    is being worked on).  At present, the first problem is far important.
    significant.
          To alleviate the problems cited above and enable us to provide
    a reasonable level of service, we are asking Arpanet list maintainers
    to provide list exploders on Bitnet and vice versa.  Your cooperation
    will be very much appreciated. Note that in a about a month we will
    begin limiting the number of copies we will relay by putting a limit on
    the number of recipients in RCPT TO lines in SMTP and BSMTP.  This
    limit is likely to be 10.
          Thanks in advance for your cooperation in this matter.

So we need a volunteer on BITNET to take over the BITNET addresses as a
redistribution point.  Light work, little acclaim, some harrassment when
the more irritable folks have erring mail returned to them -- and if no one
does it, the BITNET side of this list will go down the tube.  Interested
folk are encouraged to apply to (you guessed it) HEADER-PEOPLE-REQUEST;
indications of sanity, experience at dealing with mailing lists, sense of
humor, etc. will be taken into account in choosing the victim////// noble
volunteer.

Thank you for your attention to this public service msg..


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  4 Dec 86 10:11:13 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  4 Dec 86 10:10:04 EST
Date:  Thu, 4 Dec 86 04:41 EST
From:  John C Klensin <Klensin@MIT-MULTICS.ARPA>
Subject:  Marvin's redistribution list comments
To:  VICTOR@YKTVMX.BITNET, Marvin Solomon <solomon@GJETOST.WISC.EDU>
cc:  header-people@AI.AI.MIT.EDU
Message-ID:  <861204094145.321439@MIT-MULTICS.ARPA>

To add two things to this succinct and clear explanation (I am keeping a
copy so I can use it to explain this problem locally (which I need to
do, again and again)):
  The offender is mitvma.bitnet and mit-multics.arpa.  The two machines
have a wire running between them that constitutes a partial
BITNET->Internet gateway.  One explanation for the problem is that each
machine is expecting the other to munge the headers; neither does.
Another explanation is that the proper munging of the headers is at the
bottom of a hole labelled "we think we found a counterexample that
demonstrates at least one case where header-munging fails to produce the
correct/anticipated effect, therefore we will do nothing".
   However, the sending host can overcome a good deal (not all) of the
problem with a small, very popular, and only slightly illegal ruse:  if
the mail leaves yktvmx with the host name 'yktvmx.BITNET' in the header,
i.e., using the pseudo-domain 'BITNET', many Internet hosts, including
the mit-multics->mitvma offending/offensive pseudo-gateway, will know
what to do with it.  And, on those hosts that don't, many human beings
and mail agents will know enough to look at a "host name" ending in
".BITNET" and say "aha, user%yktvmx.BITNET@WISCVM.WISC.EDU" -- so at
least it is possible to get an answer back.
  In this particular case, the sending host, yktvmx, must route the
(RSCS) mail to MAILER@MITMVA on BITNET in order to have it get through
thatthe MITVMA->MIT-Multics gateway.  MAILER@MITVMA is an MTA, and it,
at least, is quite happy to accept From:  and Sender:  fields in
messages that say things like
  victor%yktvmx.BITNET@WISCVM.WISC.EDU
 or, to get things back the way they came,
  victor%yktvmx.BITNET@MIT-Multics.ARPA
 ...whether it should accept Sender/From addresses that differ, even
slightly, from the BSMTP envelope (or what it requires of that envelope)
is an open question, but it does.  That permits the originating host to
fix/avoid the problem itself.
  And so, the third explanation around here is that neither
mit-multics.arpa not mitvma.BITNET should need to do the job, the
originating host (yktvmx) should do so.  I'm not, personally, real
impressed with that story, but, you, Victor, might translate it as
"either put together message headers that conform to the idiosyncracies
of the unofficial gateways that you use, or use an official gateway
(e.g., WISCVM.WISC.EDU) that does the right thing".

Disclaimer:  While I work for/at MIT, I am not part of the organization
that determines whether the situations discussed above are "features" or
problems worth fixing .a and whether the word "explanations" used above
should be spelled "excuses".  In this particular case, perhaps, more's
the pity.
    john


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  5 Dec 86 03:23:09 EST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU  5 Dec 86 03:22:19 EST
Received: from BIONET by SUMEX-AIM.ARPA with Cafard; Fri 5 Dec 86 00:18:17-PST
Date: Fri 5 Dec 86 00:01:41-PST
From: David Roode <ROODE%BIONET@SUMEX-AIM.Stanford.EDU>
Subject: Re: Redistribution lists
To: Victor%YKTVMX.BITNET@WISCVM.WISC.EDU
cc: HEADER-PEOPLE@AI.AI.MIT.EDU
In-Reply-To: Message from ""Victor S. Miller" <VICTOR@YKTVMX>" of Tue 2 Dec 86 13:45:17-PST
Phone: (415) 965-5585
Message-ID: <12260300425.19.ROODE@BIONET>

You should not have to do anything to have error messages for
local exploders route back to the local host.  The local
host should be building a RETURN PATH that will cause this
to happen for all downline messages (until the next 
local exploder).  The problem is incomplete implementations
of exploders at sites being used for mail relaying by your
mailing list.  One alternative is to switch to sites
which do implement this in what has become the
accepted manner.

If you play with the "Sender:" header, or the "Reply-to:" header,
you may trick certain mailers which do not otherwise produce
the desired RETURN PATH into doing so;  you may also cause
legitimate replies to the message from humans to go astray.
-------
 


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 06:44:45 EST
Received: from USC-ECLB.ARPA (TCP 3201600101) by AI.AI.MIT.EDU 14 Dec 86 06:44:14 EST
Date: Sun 14 Dec 86 03:42:27-PST
From: Leonard D. Woren <LDW@USC-ECLB.ARPA>
Subject: question on ReSent-To
To: header-people@AI.AI.MIT.EDU
Message-ID: <12262699910.13.LDW@USC-ECLB.ARPA>

A question came up on what it means to if there are multiple ReSent-xxx
lines of the same type.  RFC 822 seems to ignore this problem.  Can
anyone tell me what a mailer should do, for example, if it receives 
a message with multiple ReSent-To: lines???  How would the mailer 
know which ReSent-To: line to use in delivering the message?  The
problem appears to exist with many (or all) resent- fields.  Suppose
there are multiple ReSent-From: lines.  How would a mailer or user
agent "reply" command know which one to use?

If possible, please reply to (or cc:)
   LDW@USCMVSA.BITNET
-------


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 11:38:06 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 14 Dec 86 11:37:47 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a007324; 14 Dec 86 8:35 PST
To: "Leonard D. Woren" <LDW@usc-eclb.ARPA>
cc: header-people@ai.ai.mit.EDU, ldw%USCMVSA.BITNET@wiscvm.wisc.EDU
reply-to: header-people@ai.ai.mit.EDU
Subject: Re: question on ReSent-To 
In-reply-to: Your message of Sun, 14 Dec 86 03:42:27 -0800.
             <12262699910.13.LDW@USC-ECLB.ARPA> 
Date: Sun, 14 Dec 86 08:35:38 -0800
Message-ID: <7322.534962138@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

    Having multiple Resent-xxx fields is no worse than having multiple
    xxx fields (e.g., To: and cc:).  There isn't a problem.  Programs
    like "mailers" have two units of information: the envelope and the
    message.  The envelope contains (among other things) the recipients
    that the mailer is responsible for, the message has whatever the
    originating user typed in, plus a Received: field for every mailer
    that it's passed through.  If the mailsystem did not separate the
    envelope and the message, then "accurate" delivery would be
    impossible as an address could be an alias which gets expanded to
    other addresses, and so on.  

    Now, for the second part of your question: how does a user agent
    "reply" command know which one to use.  The answer is that it
    doesn't use Resent-From: for replies, nor does it uses any
    Resent-xxx: headers.  For the purposes of replying, it should
    ignore all the Resent-xxx: headers and use the usual
    Reply-To:/From:, To: and cc: fields.

    The Resent fields are used, by my interpretation, for one thing
    only: when a user takes a message s/he received and wishes to
    propagate it in the "mailsystem" to other recipients, the user adds
    Resent fields and says to send the message.  The user agent sees the
    Resent fields, and then using whatever method it has for talking to
    its local mailer, it creates an envelope with the contents of the
    Resent fields.  The mailer acts on this information, not on any
    information in the message.  

/mtr


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 12:30:57 EST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Dec 86 12:29:56 EST
Date: Sun, 14 Dec 1986  12:27 EST
Message-ID: <SRA.12262762638.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "Leonard D. Woren" <LDW@USC-ECLB.ARPA>,
      LDW%USCMVSA.BITNET@WISCVM.WISC.EDU
Cc:   header-people@AI.AI.MIT.EDU
Subject: question on ReSent-To
In-reply-to: Msg of 14 Dec 1986  06:42-EST from Leonard D. Woren <LDW@USC-ECLB.ARPA>

    Date: Sunday, 14 December 1986  06:42-EST
    From: Leonard D. Woren <LDW@USC-ECLB.ARPA>

    A question came up on what it means to if there are multiple ReSent-xxx
    lines of the same type.  RFC 822 seems to ignore this problem.  Can
    anyone tell me what a mailer should do, for example, if it receives 
    a message with multiple ReSent-To: lines???  How would the mailer 
    know which ReSent-To: line to use in delivering the message?  The
    problem appears to exist with many (or all) resent- fields.  Suppose
    there are multiple ReSent-From: lines.  How would a mailer or user
    agent "reply" command know which one to use?

I think you confusing envelope and contents.  RFC822 came out at the
same time as RFC821 (SMTP), which is the answer to your question.  You
aren't supposed to -do- anything based on the Resent-To: lines, you're
supposed to be using the SMTP RCPTs.

In case you haven't heard of it yet, there's this neat adaptation of
SMTP for store-and-forward-file oriented networks (eg, BITNET), called
BSMTP.  It is a minimal set of additions to SMTP (two new commands,
one new reply code) and is a real winner.  I can post the spec (it's
real short) if there's sufficient interest.  I believe that the most
common BITNET mailer (Alan Crosswell's MAILER) now uses BSMTP.  Among
other things, it provides things like SMTP return-path for errors, and
a way to work around the 8 character limit on RSCS user-ids (handy if
you are using a BITNET machine to relay mail to another machine that
isn't an IBM mainframe...).

Of late, we have been converting hosts on the MIT Chaosnet to using
SMTP instead of the old MAIL protocol (which parses the RFC882
headers).  The header parsing was getting too complex and we kept
getting screwed by the lack of SMTP return-paths.

At this point you shouldn't be writing new code that parses RFC882
headers if there is any way to avoid it.  You should put your
programer time into implementing the newer mail protocols.  SMTP isn't
perfect, but a lot of the design decisions in it were based on the
failings of the older protocols (ie, it's a second generation mail
protocol).

Is there some particular environment that you have to work with that
requires parsing RFC882 headers?  I have heard that the WISCVM gateway
is still sending non-BSMTP messages on the BITNET side, even though it
insists on BSMTP for messages going the other way.

--Rob


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 12:30:57 EST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 14 Dec 86 12:29:56 EST
Date: Sun, 14 Dec 1986  12:27 EST
Message-ID: <SRA.12262762638.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "Leonard D. Woren" <LDW@USC-ECLB.ARPA>,
      LDW%USCMVSA.BITNET@WISCVM.WISC.EDU
Cc:   header-people@AI.AI.MIT.EDU
Subject: question on ReSent-To
In-reply-to: Msg of 14 Dec 1986  06:42-EST from Leonard D. Woren <LDW@USC-ECLB.ARPA>

    Date: Sunday, 14 December 1986  06:42-EST
    From: Leonard D. Woren <LDW@USC-ECLB.ARPA>

    A question came up on what it means to if there are multiple ReSent-xxx
    lines of the same type.  RFC 822 seems to ignore this problem.  Can
    anyone tell me what a mailer should do, for example, if it receives 
    a message with multiple ReSent-To: lines???  How would the mailer 
    know which ReSent-To: line to use in delivering the message?  The
    problem appears to exist with many (or all) resent- fields.  Suppose
    there are multiple ReSent-From: lines.  How would a mailer or user
    agent "reply" command know which one to use?

I think you confusing envelope and contents.  RFC822 came out at the
same time as RFC821 (SMTP), which is the answer to your question.  You
aren't supposed to -do- anything based on the Resent-To: lines, you're
supposed to be using the SMTP RCPTs.

In case you haven't heard of it yet, there's this neat adaptation of
SMTP for store-and-forward-file oriented networks (eg, BITNET), called
BSMTP.  It is a minimal set of additions to SMTP (two new commands,
one new reply code) and is a real winner.  I can post the spec (it's
real short) if there's sufficient interest.  I believe that the most
common BITNET mailer (Alan Crosswell's MAILER) now uses BSMTP.  Among
other things, it provides things like SMTP return-path for errors, and
a way to work around the 8 character limit on RSCS user-ids (handy if
you are using a BITNET machine to relay mail to another machine that
isn't an IBM mainframe...).

Of late, we have been converting hosts on the MIT Chaosnet to using
SMTP instead of the old MAIL protocol (which parses the RFC882
headers).  The header parsing was getting too complex and we kept
getting screwed by the lack of SMTP return-paths.

At this point you shouldn't be writing new code that parses RFC882
headers if there is any way to avoid it.  You should put your
programer time into implementing the newer mail protocols.  SMTP isn't
perfect, but a lot of the design decisions in it were based on the
failings of the older protocols (ie, it's a second generation mail
protocol).

Is there some particular environment that you have to work with that
requires parsing RFC882 headers?  I have heard that the WISCVM gateway
is still sending non-BSMTP messages on the BITNET side, even though it
insists on BSMTP for messages going the other way.

--Rob


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 86 18:47:59 EST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by AI.AI.MIT.EDU 14 Dec 86 15:34:37 EST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 14 Dec 86 12:28:49-PST
Date: Sun 14 Dec 86 11:27:01-PST
From: Mark Crispin <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
Subject: Re: question on ReSent-To
To: LDW@USC-ECLB.ARPA, LDW%USCMVSA.BITNET@WISCVM.WISC.EDU
cc: header-people@AI.AI.MIT.EDU
In-Reply-To: <12262699910.13.LDW@USC-ECLB.ARPA>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12262784482.7.MRC@PANDA>

Leonard Woren -

     The first part of your question is meaningless.  The message
header is not used by the mailer in determining who the message
should go to.  That information is stored in the "envelope" of the
message, which is transmitted by the SMTP (RFC 821) protocol out
of band from the message.  There is not necessarily any correlation
between the information in the header and what actually exists in
the envelope, although generally the header information is a *subset*
of the envelope information.

     Replies are sent to the REPLY-TO address if it exists, else
to the FROM address.  Replies are never sent to SENDER, RETURN-PATH,
or any of the RESENT-xxx lines.  If the re-sender had wanted a reply
he would have forwarded the message inside his own message instead
of resending the original message.

-- Mark --
-------


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 00:13:49 EST
Received: from RADC-MULTICS.ARPA (TCP 3200000022) by AI.AI.MIT.EDU 15 Dec 86 00:13:07 EST
Date:  Mon, 15 Dec 86 00:07 EST
From:  Rodney <Peck@RADC-MULTICS.ARPA>
Subject:  x.25 et al
To:  header-people@AI.AI.MIT.EDU
Message-ID:  <861215050735.241268@RADC-MULTICS.ARPA>

   I'd like to find out about all this networking stuff, is there
someplace I can ftp a document explaining X.25 or any of the other nets?
       -rodney


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 04:08:33 EST
Received: from USC-ECLB.ARPA (TCP 3201600101) by AI.AI.MIT.EDU 15 Dec 86 04:05:55 EST
Date: Mon 15 Dec 86 01:06:00-PST
From: Leonard D. Woren <LDW@USC-ECLB.ARPA>
Subject: Resent-xxx, RFC822, BSMTP
To: header-people@AI.AI.MIT.EDU
Message-ID: <12262933571.33.LDW@USC-ECLB.ARPA>

Thanks for the replies.  Obviously, I should have included more
information.  Also obviously, the mailer that I am running has a
problem.  I have UCLA/Mail running on MVS, and the Crosswell mailer
running on VM.  UCLA/Mail was written to conform to RFC822.  It 
will handle BSMTP, but not everything sends it.  Our VM node is not
sending BSMTP to the MVS node.  I'll have to get the VM'ers to check
out whether we're running the latest version of the Crosswell mailer,
or whether there's some definition that needs to be changed to have
it send BSMTP to the MVS system.

WISCVM and other gateways that will remain nameless often send us mail
without BSMTP envelopes, that has bad headers, because they don't mung
them going through the gateway, and that mail cannot be delivered by
UCLA/Mail.  I agree, it appears that I would not be having any problems
if *every* mailer sent BSMTP.  The reason for my original query is that
the author of UCLA/Mail said that one reason he doesn't support a lot 
of RFC822 fields is that they're not clearly defined.  I'll forward my
question and all the responses to him.

If (B)SMTP is the way to go, why was RFC822 even written?  Isn't SMTP
defined in RFC821?  And, thanks for the offer of posting the BSMTP
definition, but I believe that I already have it.
-------


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST
To: "Leonard D. Woren" <LDW@usc-eclb.ARPA>
cc: header-people@ai.ai.mit.EDU
reply-to: header-people@ai.ai.mit.EDU
Subject: Re: Resent-xxx, RFC822, BSMTP 
In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800.
             <12262933571.33.LDW@USC-ECLB.ARPA> 
Date: Mon, 15 Dec 86 07:32:07 -0800
Message-ID: <10351.535044727@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Hopefully you won't get too many flames for your last message "if (B)SMTP
is the way to go, why was rfc822 ever written?"  The answer is simple: they
solve different problems.  SMTP is used by mailers to exchange messages in
transit.  In a correctly managed environment, there is no munging
involved!  The only thing an SMTP implementation will do to the message it
accepts is add a Received: line and update the Return-Path:.  It should do
nothing more.  (The operative term here is "correctly managed".)  SMTP should
spend most of its time handling envelope stuff.

822 is used by user agents to manage a different type of information.  It
is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and
so on.  821/SMTP is totally naive about this kind of stuff.  Now, I can
tell you from long, bitter experience, and I'm sure other people who've I'd
had violent arguments with, like Mark Crispin, will agree with me that:

	If your "mailer" doesn't deal in envelopes, and instead looks at
	the headers of the message to figure out what to do, then it is
	SEVERELY BROKEN and WILL NEVER WORK RIGHT!

As far as your friend's claim that "822 isn't specific enough on the
meanings of the fields it defines", my claim is that it is a matter of
interpretation.  I know of 5 independently coded implementations of user
agents in the ARPA Internet which all manage work together.  While each
implementation team might view that only their code conforms to 822 and
the other four don't, everything still works.  I suspect the best thing to
do, is to ask more questions on header-people, and try to resolve any issues
you might have.

/mtr


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST
To: "Leonard D. Woren" <LDW@usc-eclb.ARPA>
cc: header-people@ai.ai.mit.EDU
reply-to: header-people@ai.ai.mit.EDU
Subject: Re: Resent-xxx, RFC822, BSMTP 
In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800.
             <12262933571.33.LDW@USC-ECLB.ARPA> 
Date: Mon, 15 Dec 86 07:32:07 -0800
Message-ID: <10351.535044727@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Hopefully you won't get too many flames for your last message "if (B)SMTP
is the way to go, why was rfc822 ever written?"  The answer is simple: they
solve different problems.  SMTP is used by mailers to exchange messages in
transit.  In a correctly managed environment, there is no munging
involved!  The only thing an SMTP implementation will do to the message it
accepts is add a Received: line and update the Return-Path:.  It should do
nothing more.  (The operative term here is "correctly managed".)  SMTP should
spend most of its time handling envelope stuff.

822 is used by user agents to manage a different type of information.  It
is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and
so on.  821/SMTP is totally naive about this kind of stuff.  Now, I can
tell you from long, bitter experience, and I'm sure other people who've I'd
had violent arguments with, like Mark Crispin, will agree with me that:

	If your "mailer" doesn't deal in envelopes, and instead looks at
	the headers of the message to figure out what to do, then it is
	SEVERELY BROKEN and WILL NEVER WORK RIGHT!

As far as your friend's claim that "822 isn't specific enough on the
meanings of the fields it defines", my claim is that it is a matter of
interpretation.  I know of 5 independently coded implementations of user
agents in the ARPA Internet which all manage work together.  While each
implementation team might view that only their code conforms to 822 and
the other four don't, everything still works.  I suspect the best thing to
do, is to ask more questions on header-people, and try to resolve any issues
you might have.

/mtr


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 10:33:30 EST
Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 15 Dec 86 10:32:28 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a010353; 15 Dec 86 7:32 PST
To: "Leonard D. Woren" <LDW@usc-eclb.ARPA>
cc: header-people@ai.ai.mit.EDU
reply-to: header-people@ai.ai.mit.EDU
Subject: Re: Resent-xxx, RFC822, BSMTP 
In-reply-to: Your message of Mon, 15 Dec 86 01:06:00 -0800.
             <12262933571.33.LDW@USC-ECLB.ARPA> 
Date: Mon, 15 Dec 86 07:32:07 -0800
Message-ID: <10351.535044727@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>

Hopefully you won't get too many flames for your last message "if (B)SMTP
is the way to go, why was rfc822 ever written?"  The answer is simple: they
solve different problems.  SMTP is used by mailers to exchange messages in
transit.  In a correctly managed environment, there is no munging
involved!  The only thing an SMTP implementation will do to the message it
accepts is add a Received: line and update the Return-Path:.  It should do
nothing more.  (The operative term here is "correctly managed".)  SMTP should
spend most of its time handling envelope stuff.

822 is used by user agents to manage a different type of information.  It
is 822 which defines the semantics of Reply-To:, Subject:, Date:, To:, and
so on.  821/SMTP is totally naive about this kind of stuff.  Now, I can
tell you from long, bitter experience, and I'm sure other people who've I'd
had violent arguments with, like Mark Crispin, will agree with me that:

	If your "mailer" doesn't deal in envelopes, and instead looks at
	the headers of the message to figure out what to do, then it is
	SEVERELY BROKEN and WILL NEVER WORK RIGHT!

As far as your friend's claim that "822 isn't specific enough on the
meanings of the fields it defines", my claim is that it is a matter of
interpretation.  I know of 5 independently coded implementations of user
agents in the ARPA Internet which all manage work together.  While each
implementation team might view that only their code conforms to 822 and
the other four don't, everything still works.  I suspect the best thing to
do, is to ask more questions on header-people, and try to resolve any issues

you might have.

/mtr


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 12:41:52 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 15 Dec 86 12:41:08 EST
Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 4008;
          Mon, 15 Dec 86 12:35:35 EST
Date: 15 Dec 1986 12:30:13-EST (Monday)
From: "Victor S. Miller" <victor@ibm.com>
To: header-people@ai.ai.mit.edu
Subject: Folding long fields

In re-reading rfc822, I find that folding long lines is permitted only where
LWSP is permitted.  What should one do with some horrendously long addresses
one gets from UseNet: in the form a!b!...!z where the total length often
is longer than 140 characters? (of course this comes in a header field
called Path which isn't in the rfc822 standard -- it should be called
X-Path).  The character "!" doesn't have any lexically special meaning in
rfc822 (neither does %), thus it looks like one can't fold it anywhere.
                                Victor


Received: from po2.andrew.cmu.edu (TCP 20000574551) by MC.LCS.MIT.EDU 15 Dec 86 14:26:50 EST
Received: by po2.andrew.cmu.edu (4.12/3.15) id <AA01001>; Mon, 15 Dec 86 13:49:25 est
Received: FROM lititz VIA queuemail
          ID </cmu/common/mailqs/q000/QF.lititz.1fe4508a.df>;
          Mon, 15 Dec 86 13:49:03 est
Message-Id: <MS.V3.18.cfe.80020ffd.lititz.ibm032.340.1@andrew.cmu.edu>
Date: Mon, 15 Dec 86 13:48:32 est
From: cfe#@andrew.cmu.edu (Craig F. Everhart)
To: header-people@mit-mc.arpa
Subject: Re: Resent-xxx, RFC822, BSMTP 


I agree that in the Arpa Internet world nobody should muck with the 822
headers (except for adding Received: and Return-Path: lines.  (Headers should
be composed properly in the first place, but that's another issue.)  In the
Bitnet world, mail is much less well specified.  There are lots of Bitnet
hosts and mailers that don't support the envelope/content distinction that
RFC821 provides (that is generally provided by the BSMTP variant of SMTP),
and they resort to inspection of the header fields.  My belief is that Bitnet
mail is (currently, at least) sufficiently different from Arpa Internet mail
that mail gateway machines must, in general, rewrite the addresses in the
headers.  Not that I'm specifying the transformations here!



Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 14:52:52 EST
Received: from WISCVM.WISC.EDU (TCP 20032201015) by AI.AI.MIT.EDU 15 Dec 86 14:52:13 EST
Received: from (MAILER)DBNGMD21.BITNET by WISCVM.WISC.EDU on 12/15/86
  at 13:51:28 CST
Date:    Mon, 15 Dec 86 20:40 CET
To:  header-people@ai.ai.mit.edu
From:      Peter  Sylvester +49 228 303245
  <GRZ027%DBNGMD21.BITNET@WISCVM.WISC.EDU>
Subject: Re: Folding long fields


> From: "Victor S. Miller" <victor@ibm.com>
....
> one gets from UseNet: in the form a!b!...!z where the total length often
> is longer than 140 characters? (of course this comes in a header field

You put your finger into one of the wounds of the SMTP
interpretation in BITNET (and maybe in other environments, too).
In BITNET there is no RFC821/2 mail. It is EBCDIC and CRLF is
interpreted a "end of card" (80 columns). Blanks are always inserted
and you get either 80 or 79 characters in a "line" (79 if you have
to double a dot in col 1).

79/80 is much less than any of the limits that are in RFC821
although it works in 99.9999% of all "texts".

Peter



Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 86 19:05:25 EST
Received: from BRL-SEM.ARPA (TCP 30001213410) by AI.AI.MIT.EDU 15 Dec 86 16:22:44 EST
Date:     Mon, 15 Dec 86 16:15:58 EST
From:     Ron Natalie <ron@BRL.ARPA>
To:       "Victor S. Miller" <victor@ibm.COM>
cc:       header-people@ai.ai.mit.EDU
Subject:  Re:  Folding long fields
Message-ID:  <8612151615.aa04955@SEM.BRL.ARPA>

There is no restriction on having a header field called "Path,"
receiving sites are free to discard it.  The "X-" prefix is guaranteed
never to be used for anything in the spec so it is available to user
implementations.

-Ron


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 86 22:26:14 EST
Received: from jade.berkeley.edu (TCP 20010104011) by AI.AI.MIT.EDU 19 Dec 86 21:14:44 EST
Received: from web.berkeley.edu
	by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.6)
	id AA08273; Fri, 19 Dec 86 18:09:09 PST
Received: by web.Berkeley.Edu (1.1/SMI-3.0DEV3.4)
	id AA09711; Fri, 19 Dec 86 18:11:39 PST
Date: Fri, 19 Dec 86 18:11:39 PST
From: netinfo%web.Berkeley.EDU@BERKELEY.EDU (Postmaster & BITINFO)
Message-Id: <8612200211.AA09711@web.Berkeley.Edu>
To: header-people@ai.ai.mit.edu, victor@ibm.com
Subject: Re:  Folding long fields
Cc: mark@cbosgd.att.com, usenet@ucbvax.Berkeley.EDU

In reply to:

	Date: 15 Dec 1986 12:30:13-EST (Monday)
	From: "Victor S. Miller" <victor@ibm.com>
	To: header-people@ai.ai.mit.edu
	Subject: Folding long fields
	Status: RO
	
	In re-reading rfc822, I find that folding long lines is
	permitted only where LWSP is permitted.  What should one do
	with some horrendously long addresses one gets from UseNet: in
	the form a!b!...!z where the total length often is longer than
	140 characters? (of course this comes in a header field called
	Path which isn't in the rfc822 standard -- it should be called
	X-Path).  The character "!" doesn't have any lexically special
	meaning in rfc822 (neither does %), thus it looks like one
	can't fold it anywhere.
	                                Victor
	
I concur that Path should not be put in RFC822 mail headers when
news is gatewayed from USENET news to Internet mail systems.

Often Path is not even a mail address. It is actually a list of
USENET news site codes that a USENET news article has passed through.
Altrough USENET users may thing otherwise, there are many news links
that are not UUCP news links.

I would be nice if the USENET/mail gateway software programmers
would delete the Path when it is transported into the mail system,
and optionally use X-Path (if they must) with LWSP between sites
instead of exclamation marks.

Bill Wells
postmaster%web@Berkeley.EDU


Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 86 22:26:22 EST
Received: from jade.berkeley.edu (TCP 20010104011) by AI.AI.MIT.EDU 19 Dec 86 21:33:19 EST
Received: from web.berkeley.edu
	by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.6)
	id AA08456; Fri, 19 Dec 86 18:31:51 PST
Received: by web.Berkeley.Edu (1.1/SMI-3.0DEV3.4)
	id AA09755; Fri, 19 Dec 86 18:34:23 PST
Date: Fri, 19 Dec 86 18:34:23 PST
From: netinfo%web.Berkeley.EDU@BERKELEY.EDU (Postmaster & BITINFO)
Message-Id: <8612200234.AA09755@web.Berkeley.Edu>
To: GRZ027@DBNGMD21.BITNET, header-people@ai.ai.mit.edu, mail-l@bitnic.BITNET
Subject: BITNET mail system

In reply to:

	Date:    Mon, 15 Dec 86 20:40 CET
	From: Peter  Sylvester +49 228 303245
		<GRZ027%DBNGMD21.BITNET@wiscvm.wisc.edu>
	
	... In BITNET there is no RFC821/2 mail....
	
Yes there is no interactive RFC821 on BITNET because
BITNET/EARN/NETNORTH is a file transfer network.
The BSMTP is the non-interactive replacement for SMTP
on BITNET in the VM mailer system..

It might be more correct to say that there is an Internet
mail transport system (VM Mailer from Columbia University) on
BITNET/EARN/NETNORTH, but that many sites with IBM computers
do not participate in this mail system because they only want
to run IBM supported software.

Bill Wells


Received: from po3.andrew.cmu.edu (TCP 20000406037) by MC.LCS.MIT.EDU  7 Jan 87 17:49:28 EST
Received: by po3.andrew.cmu.edu (4.12/3.15) id <AA01063>; Wed, 7 Jan 87 17:44:08 est
Received: via switchmail; Wed,  7 Jan 87 17:43:57 est
Received: FROM lititz VIA queuemail
          ID </cmu/common/mailqs/q001/QF.lititz.2002d9ba.376>;
          Wed,  7 Jan 87 17:42:04 est
Message-Id: <MS.V3.20.cfe.80020ffd.lititz.ibm032.4483.0@andrew.cmu.edu>
Date: Wed,  7 Jan 87 17:41:37 est
From: cfe#@andrew.cmu.edu (Craig F. Everhart)
To: Arpa-MHS@brl.arpa, Header-People@mc.lcs.mit.edu
Subject: Unambiguous local addresses
Cc: cfe#@andrew.cmu.edu (Craig F. Everhart),
        jr#@andrew.cmu.edu (Jonathan Rosenberg),
        nsb#@andrew.cmu.edu (Nathaniel Borenstein)

We have a problem; I suspect that others share it.  Maybe somebody has found
a solution.

Here's the problem.  If somebody knows that I'm reachable via mail to the
domain name andrew.cmu.edu, they could address their mail to
``everhart@andrew.cmu.edu'' or ``craig.everhart@andrew.cmu.edu'' or
``c.f.everhart@andrew.cmu.edu'' and it will get to me just fine, assuming
that the name they give isn't ambiguous.  (If it's ambiguous, they'll be
told.)  But we'd like outgoing mail to be stamped in the From: field with an
address that will never be ambiguous.  In the old days we just used a Unix
username for that: mine is ``cfe'', and my mail had a line like
	From: cfe@andrew.cmu.edu (Craig F. Everhart)
So, because we stamp our mail this way, we have to interpret the localparts
of mail addresses (here ``cfe'') first as Unix usernames, and if that fails
we can try to match it as a surname or whatever.

Well, lots of our usernames are things like rt8p or zt55, so you'd never
confuse them with a surname or given name.  But lots of them (the older ones)
are ``brian'' and ``bob'' and ``bond'' and ``crane''  and like that.  Suppose
Joe Crane's userid is ``crane'' and Sam Crane's is ``sc09''.  Somebody tries
to send mail to their buddy Sam Crane; they guess that
``crane@andrew.cmu.edu'' will either get to Sam or will be rejected as
ambiguous.  Well, wrong: we have to consider it an unambiguous specification
for Joe Crane.  Why?  Because mail from Joe Crane has a From: address of
``crane@andrew.cmu.edu'', and replies to that address need to go to Joe
without complaint.

So what we'd really like is a way to distinguish, lexically, localparts of
mail addresses that are Unix usernames from those that are name probes.  What
we invented was what we call the hash-mark convention: localparts suffixed
with a hash-mark (e.g. ``cfe#@andrew.cmu.edu'') would be considered to be a
Unix username only, and localparts not suffixed that way would be considered
to be name probes.  Thus, mail to ``crane@andrew.cmu.edu'' gets rejected as
ambiguous; mail from Joe Crane has a From: address of
``crane#@andrew.cmu.edu''; replies to that address (with the hash-mark) are
delivered to Joe Crane, username ``crane'', without complaint.

We thought that this convention would be the answer.  We picked the hash-mark
because it needs no quoting to appear in a legal RFC822 address and because
we thought that it had no conflicting conventional use.  It's close, but once
we deployed it we found problems with other sites.  In particular, VM hosts
(much of Bitnet) cannot deal with this character in addresses; it is
conventionally interpreted by low-level VM software as a line-separator or
line-terminator character.  A widespread user mail agent mis-composes replies
if addresses contain that character; users find it difficult to enter that
character by hand as part of a canonical mail address.  In addition, the hash
mark is in ASCII, but it isn't in most international alphabets; people might
have a hard time composing properly-addressed mail to us.

There are two possibilities that seem open.  One is to change our users' Unix
usernames so that they're lexically distinct from given names or
surnames--for example, so they all begin with letter-letter-digit.  This is a
major step.

The other possibility is to find another way to tag localparts as usernames
and not, e.g., surnames.  We like the suffix-character solution; we've
already grown a system that interprets the localpart A#B as submailbox B of
Unix username A's mail.  (So, for instance, I would receive mail addressed to
cfe#photo and I could put such mail into a separate mail class.)

The problem is that lots of the characters already mean something.  I did a
little research.  Given each character, suppose that we started using that
character as our special tag:
	Some characters are widely used for other purposes, so people
composing mail addresses might accidentally misuse them: dot (Brian.Reid),
underscore (Jakob_Palme), hyphen (John Smith-Corona), percent
(foobaz%mit-oz@mit-mc).
	Some characters are conventionally used by some mailers (well, UUCP,
and some UCB Sendmail config files) to indicate an alternate host/user
coupling: exclamation (foo!bar!baz!mumble@Berkeley), colon and circumflex
and maybe slash and equals (Berknet (?)).
	Some characters have special interpretations in other computing
domains: hash-mark (IBM VM makes it hard to use), slash, equals, hash,
underscore (RFC987 suggests another interpretation for them for use on the
other side of a gateway to X.400), dollar sign (a disastrous part of an
address for standard Berkeley 4.2 Sendmail).
	International standard alphabets don't include lots of characters:
dollar sign, tilde, hash-mark, left and right curly brace, vertical bar (all
variable within ISO 646), exclamation, hash-mark, dollar sign, percent,
ampersand, asterisk, circumflex, underscore, open quote (not part of basic
IA5).

This summary leaves us with only the two characters plus sign and question
mark.  It might be funny for a while if my unambiguous address were
``cfe?@andrew.cmu.edu'', but really!.  What I'd like to ask, though, is if
my unambiguous address were ``cfe+@andrew.cmu.edu'', what mailers would fall
over?  What problems might there be?

We might have used something like ``Craig.F..Everhart@andrew.cmu.edu'' as
our unambiguous mail address, but our system is growing to be very large
(3400+ users today, 10000 in a couple of years).  Thus, name conflicts are
inevitable, even if we try to include people's middle names in their
unambiguous addresses.  Even in a small domain it's possible to make one user
``smith'' and another one ``rsmith'', but how does the person outside the
system, guessing what Rob Smith's mail address is, get the mail to the right
person with the greatest probability?

Do we have choices other than renaming hundreds of our users' Unix usernames
to be lexically distinct, switching to using a plus rather than a hash mark
(and running into new and different bugs on widely-scattered mail systems),
or inventing some new unambiguous, uncontroversial annotation on Unix
usernames so that they can be used and recognized as localparts without
hassle?  (Any such invention should provide for submailbox notation also, so
that the trick is to embed both a Unix userid and an arbitrary submailbox
name.)

Yes, with 10,000 users, we'll need to provide some mechanism for
un-flattening the name space (like offering some way to specify ``the Dr.
Smith on the History faculty''@andrew.cmu.edu), but we'll always need to
have an unambiguous mail address, regardless of how many Smiths join the
History faculty.

I apologize for the length of this message.  I hope, however, that somebody
can offer a solution or advice.

		Many thanks,
		Craig Everhart
		Andrew message group



Received: from BRL-SEM.ARPA (TCP 30001213410) by MC.LCS.MIT.EDU  7 Jan 87 19:37:31 EST
Date:     Wed, 7 Jan 87 19:31:43 EST
From:     Doug Kingston <dpk@BRL.ARPA>
To:       "Craig F. Everhart" <cfe#@andrew.cmu.EDU>
cc:       Arpa-MHS@BRL.ARPA, Header-People@mc.lcs.mit.EDU, 
          "Craig F. Everhart" <cfe#@andrew.cmu.EDU>, 
          Jonathan Rosenberg <jr#@andrew.cmu.EDU>, 
          Nathaniel Borenstein <nsb#@andrew.cmu.EDU>
Subject:  Re:  Unambiguous local addresses
Message-ID:  <8701071931.aa10738@SEM.BRL.ARPA>

The MMDF2 Mail System has been using the equals sign "=" for
encoding delivery information in the local part for some time.
We have not run into any problems.  The notation we use yeilds
address such as "dpk=infoterms@vgr.brl.mil".  I would avoid
"?" at all costs.

-Doug-

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  8 Jan 87 11:27:06 EST
Received: from ub.com by csnet-relay.csnet id ab02183; 8 Jan 87 11:23 EST
Date:     Thu, 8 Jan 87 7:50:32 PST
From:     Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
To:       "Craig F. Everhart" <cfe#@ANDREW.CMU.EDU>
cc:       Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, 
          "Craig F. Everhart" <cfe#@ANDREW.CMU.EDU>, 
          Jonathan Rosenberg <jr#@ANDREW.CMU.EDU>, 
          Nathaniel Borenstein <nsb#@ANDREW.CMU.EDU>
Subject:  Re:  Unambiguous local addresses
Organization:  Ungermann-Bass, Inc.

Craig,

This is a brief commentary on some choices we made for MCI Mail.  Anyone
thoroughly familiar with addressing in same may wish to read their next
message...

"login" vs. "full" names are both allowed for referencing.  There is no
syntactic distinction made.  I do not recall ever hearing of a user
problem with this, but there was a major operational difference between
MCI Mail, at that time, and your own environment:  We were entirely
interactive with the data base and the user received a feedback line
that specified the addressee's full name, organization, and location.
If the reference is ambiguous, the user receives this information about
all of the possible choices.

With the advent of back-end, protocol-based submission, MCI may be
having some of the problem you describe.  In general, the philosophy 
was to give users a way to specify a unique addres, if they insisted,
but allow them to hit an unintended recipient, if they were not 
careful.

Login name and Full name were given equal precedence.  So, if there are
two users with a last name of Crane and a third with a login of Crane,
then reference to "crane" is ambiguous.  What we did, to provide a
guaranteed-unique reference, was to have yet-another reference
string for the user, called their MCI ID.  (Mine is 1060171.  So,
you can send to dcrocker, Dave Crocker, Crocker, 1060171 -- only the
last of which is guaranteed always to refer to me and only me.)

To facilitate resolution, when the id is unknown and the name may
be ambiguous, reference to the recipient's organization and/or
location also is permitted.  E.g., "crocker" may be ambiguous,
but "crocker/ungermann/clara" is not.  (org and loc may be substrings of
Ungermann-Bass and Santa Clara.)  Well, it is, now, but my wife used to
work there, so ...

It is worth noting that the Directory Services work that is going on in
the international standards community permits roughly this sort of
reference.

I guess my suggestion is that you should administratively enforce Unix
logins that are cryptic, unique ids and let the Full-Name database
handle the "friendly" references.

Dave

Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU  8 Jan 87 11:59:18 EST
Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa04498; 8 Jan 87 16:56 WET
To: "Craig F. Everhart" <cfe#@andrew.cmu.edu>
cc: Arpa-MHS@brl.arpa, Header-People@mc.lcs.mit.edu, 
    Jonathan Rosenberg <jr#@andrew.cmu.edu>, 
    Nathaniel Borenstein <nsb#@andrew.cmu.edu>, mhs@Cs.Ucl.AC.UK
Subject: Re: Unambiguous local addresses
Phone: +44-1-380-7294
In-reply-to: Your message of Wed, 07 Jan 87 17:41:37 -0500.
             <MS.V3.20.cfe.80020ffd.lititz.ibm032.4483.0@andrew.cmu.edu>
Date: Thu, 08 Jan 87 16:45:54 +0000
Message-ID: <4137.537122754@UK.AC.UCL.CS>
From: Steve Kille <steve@Cs.Ucl.AC.UK>

This is a difficult problem, and shared by very many sites
(although I suspect that quite a few do not realise it yet).
These are my thoughts on how UCL will tackle them.

The first thing is to separate the mail id and user id name
spaces.  These really have different characteristics.   The
latter usually need only be known by a relatively small number of
people, and so can be shorter (and more cryptic).   The mapping
should be done at message creation/deliver times.   As a side
effect, this also improves security, as you do not distribute a
list of login ids every time you send a message.   This does
give an extra binding to maintain, but is not that big a deal
if you are already managing your namespaces sensibly.

We regard the phrase (X.400 free form name) as something the
user should specify, and should not be regulated.   This work
is concerned with what is inside the angle brackets.

The form of the local-part (for human users) should be aligned
with human usage, and the structure made clear.   We will use "." as
the preferred separator (e.g. S.Kille).   Besides feeling right
(at least to me), this structuring will also facilitate usage of X.400.
For recipients, matching will be as flexible as possible.
The key question is "what to put in the From: line".   This
must be unique.   We will default to Single Initial "." Surname.
If this is not unique, more initials will be added, and then
expanded.   (e.g. S.Kille -> S.E.Kille -> Steve.E.Kille...).
The user may chose to use the default, or any other unique
variant (e.g. Kille (if I am the only one) or Steve.Kille but
not Steve (even if it is unique)).  We have decided not to guarantee
permanent uniqueness.   Thus if Steve.F.Kille gets a job at UCL,
S.Kille will become ambiguous (and thus erroneous).    Then, my
From: line would have to change, and anyone sending messages
would need to determine the new value.   For "important" people,
aliases might be used to override ambiguities (e.g. a student
with the same name as a professor).   People with exactly the
same name will not be given accounts!


We regard the "user friendliness" of this approach as overweighing
the (rather painful) problems when clashes occur.   It is clearly
important to make sure that clashes are very rare.  This means
that the larger the namespace, the more of the name must be
used.  The suggested UCL CS dept. policy is on the basis of
500-1000 names (we currently have two P.M.Smiths, but they do
have different christian names.  There are a very small number
of clashes with single initial + surname).   I would be
expecting to find clashes occuring once or twice a year.  With
andrew.cmu.edu, you appear to be talking about rather more (10 000)
users withing the songle domain.   If this made the number of
clashes too high, you would need to do something to reduce them,.
This would imply either having more of the name as default, or
breaking the name another level to the domain (e.g. Department
in the University). This would be adding an
Organisational Unit level in X.400.



Steve

Received: from USC-ECLB.ARPA (TCP 3201600101) by MC.LCS.MIT.EDU  8 Jan 87 13:48:27 EST
Date: Thu 8 Jan 87 10:47:16-PST
From: Bob Larson <BLARSON@USC-ECLB.ARPA>
Subject: Re: Unambiguous local addresses
To: steve@CS.UCL.AC.UK
cc: header-people@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU
In-Reply-To: <4137.537122754@UK.AC.UCL.CS>
Message-ID: <12269330845.37.BLARSON@USC-ECLB.ARPA>

People with exactly the same name will not be given accounts?!!  A new
form of discrimination, I'd like to see you defense when a lawsuit
comes up.  (It's not discrimination your honor, he can get an account
just as soon as he changes his name.)  BTW, I did attend the same
university at the same time as someone else with exactly the same
name.

Using addresses that may suddenly become ambiguous as the from
addresses is not a good idea, not only because of unreliable replying
to your messages.  Mailing list maintainers would curse you for it.
-------

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  8 Jan 87 14:53:10 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  8 Jan 87 14:55:41 EST
Received: from YKTVMX(VICTOR) by MITVMA (Mailer X1.23) id 9239;
          Thu, 08 Jan 87 12:46:24 EST
Date: 8 Jan 1987 12:43:39-EST (Thursday)
From: "Victor S. Miller" <VICTOR@YKTVMX>
To: Craig.F.Everhart@andrew.cmu.edu
Cc: header-people@ai.ai.mit.edu
Subject: Unique addresses

Why not just translate the Unix userid foo into the address
foo.unix@andrew.cmu.edu?  This would work fine, as long as no
one with the last name of `unix' comes along.

                     Victor


Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU  8 Jan 87 19:32:22 EST
Received: from hplms1 by hplabs.HP.COM ; Thu, 8 Jan 87 13:40:23 pst
Received: from hpldat (hpldat) by hplms1; Thu, 8 Jan 87 13:39:43 pst
Return-Path: <taylor@hpldat>
Received: by hpldat ; Thu, 8 Jan 87 13:40:29 pst
From: Dave Taylor <taylor%hpldat@hplabs.HP.COM>
Message-Id: <8701082140.AA21067@hpldat>
To: @MC.LCS.MIT.EDU@hplabs.HP.COM,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart),
        Arpa-MHS@brl.ARPA%MC.LCS.MIT.EDU,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart),
        Header-People@mc.lcs.mit.edu%MC.LCS.MIT.EDU,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart),
        cfe#@andrew.cmu.edu%MC.LCS.MIT.EDU,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart),
        jr#@andrew.cmu.edu%MC.LCS.MIT.EDU,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart),
        nsb#@andrew.cmu.edu%MC.LCS.MIT.EDU,
        %po3.andrew.cmu.edu.cfe#@andrew.cmu.edu (Craig F. Everhart)
Date: Thu, 8 Jan 87 13:40:25 PST
Subject: Re: Unambiguous local addresses
In-Reply-To: Message from "Craig F. Everhart" of Jan 7, 87 at 5:41 pm
Organization: Hewlett-Packard Laboratories, Unix Networking Group
Work-Phone-Number: +1 415 857-6887
X-Mailer: Elm [version 1.5]

An interesting problem you bring up, Craig.  Oddly, though, no-one
has seemed to realize that you're talking about not "how do we use
login names as return addresses" but rather "must we use them, and
if so, how".

I suggest that we consider first whether we need to use login names
at all as return addresses....

On a campus network of any reasonable size, indeed ANY network of a
reasonable size, there are bound to be name collisions, and there will
have to be resolutions arrived at, perhaps as used in MCI mail with
the location name, or company name, or some other extended level of
information.  The key point, though, is that the name resolver is going
to be *on-line* during this whole bit, so when a user is given an
account initially, the administration group can then assign them a
unique identification *based on their name*.  This would then go into,
say, a file on each host, in the form;

userid	unique-user-identification-name

so that as mail is sent off the machine the program jumps into this
file and extracts a *guaranteed unique* name for the person.  As new
users are added to the system, the administration group would see the
name conflicts as they arise and resolve them at that point.  It is 
expected that every so often the entire name space will need to be
expanded, by, for example, adding a department name to each persons
unique address.

It also goes without saying that this will be accessable by the
name resolver, and that there will need to be a single master file
somewhere.  (we want parts of it on different hosts, however, so that
users can have accounts on different machines, but a single email
address).

To show by example, let's consider when I went to school and how there
was this annoying chap David Gurnsey Taylor III, who shared my first
and last name...

Let's say that I have the account ee160-ba and DGT has ee160-ab (for
maximal confusion)...then the files could be something like;

ee160-ba	Dave.A.Taylor
ee160-ab	David.G.Taylor

(we will need to learn to not distinguish between commonly used nicknames,
like Dave and David, as an aside).

But let's actually expand this a bit...and add the department that the
person is majoring in:

ee160-ba	Dave.A.Taylor.EECS
ee160-ab	David.G.Taylor.Humanities

Now we can see that we can in fact remove the middle initial altogether
and still have a unique address...

So, finally, when I would send mail out, while I might be logged
in as ee160-ba@sdccs6 or something, the return address would be
something more like;

	From: Dave.Taylor.EECS@UCSD.EDU (Dave Taylor)

(the field in Parens, or in clear, if <> is used, should be user
defineable too).

No problem!

		Any comments?  Further ideas??

						-- Dave Taylor

			    uniquely addressable as taylor@hplabs

Received: from SRI-IU.ARPA (TCP 1201200002) by MC.LCS.MIT.EDU  9 Jan 87 02:07:01 EST
Date: Thu 8 Jan 87 23:05:15-PST
From: Peter Karp <PKARP@SRI-IU.ARPA>
Subject: Re: Unambiguous local addresses
To: cfe#@ANDREW.CMU.EDU
Cc: Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU,
    jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU
Message-ID: <VAX-MM(196)+TOPSLIB(122)+PONY(138) 8-Jan-87 23:05:15.SRI-IU.ARPA>
In-Reply-To: Message from "cfe#@andrew.cmu.edu (Craig F. Everhart)" of
	     Wed,  7 Jan 87 17:41:37 est

Craig,  

I will suggest that the problem is even worse than your describe.
Here are two other forms that it takes:

First is doing header re-writing to make messages from foreign
mailers RFC822-compatible.  For example, if I'm relaying a message
from a DECnet to the Arpanet, the return path will include the
token "::", which is illegal under RFC822.  One option is to double-quote
the entire address.  Another option  is to re-write these characters
into something legal.  Ultrix Sendmail uses "..", which happens to
be illegal under RFC822 (bozos).  It could be wise to use some
legal characters.

Second, naming other types of local mailboxes.  This is more closely
related to the problem you describe.  For example, if on Tops-20 I
want to mail directly to a file (e.g., a user's mailbox or a bboard
file), I use the address: *filename , e.g., *PS:<KARP>FOO.TXT .  Under
Unix, if I want a piece of mail to be piped down the standard input of
some program, I use: |program , e.g., |/usr/local/bin/foo .  I have
adopted similar conventions for a VMS mail system I've written, but
these are ugly hacks.

It would seem that we want to specify two things in a local mail
name: a type and an identifier within that type, for example:

type=username,  id=crane
type=MM-file,   id=<KARP>FOO.TXT
type=text-file, id=<KARP>BAR.TXT
type=personal-name, id=Peter.Karp
type=program,   id=/usr/local/bin/foo
type=mail-id,   id=pk001

Well, use your imagination to invent a syntax for the above.

Incidentally, I believe the character '&' is also legal under
RFC822.  I don't know if it will break other mailers.

peter

-------

Received: from nrtc-gremlin.arpa (TCP 20030600021) by MC.LCS.MIT.EDU  9 Jan 87 04:06:05 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a000532; 9 Jan 87 1:04 PST
To: Peter Karp <PKARP@sri-iu.ARPA>
cc: cfe#@andrew.cmu.EDU, Arpa-MHS@brl.ARPA, Header-People@mc.lcs.mit.EDU, 
    jr#@andrew.cmu.EDU, nsb#@andrew.cmu.EDU
Subject: Re: Unambiguous local addresses 
In-reply-to: Your message of Thu, 08 Jan 87 23:05:15 -0800.
             <VAX-MM(196)+TOPSLIB(122)+PONY(138) 8-Jan-87 23:05:15.SRI-IU.ARPA> 
Date: Fri, 09 Jan 87 01:03:55 -0800
Message-ID: <524.537181435@nrtc-gremlin.arpa>
From: Einar Stefferud <stef@nrtc-gremlin.arpa>

Having done some work on Gateways, one thing is very clear to me ---

When a message goes from DECNET to INTERNET, it should lose all its
DECNET attributes as it passes into INTERNET.  As it leaves the
gateway, all addresses, including the RETURN-PATH must be exactly
RFC822, and nothing else.  If this is not true, then nothing is
standard and anything in RETURN-Path must be execptable from anyone
anywhere at any time.

Therefore, it is my judgement that your referenced DECNET/INTERNET
gateway is defective is at least one very significant way.  It shoudl be
fixed at the Gateway site, and we should all guard very zealously
agfainst letting that gateway's bad behave trigger netwide compensations
for its erroroneous ways.  

This is just an INTERNET form of the old problem of tryin g to keep
local problem from becoming global network problems.  OK?  -- Stef

Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU  9 Jan 87 04:44:43 EST
Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa01719; 9 Jan 87 9:39 WET
To: Bob Larson <BLARSON@usc-eclb.arpa>
cc: header-people@mc.lcs.mit.edu, jr#@andrew.cmu.edu, nsb#@andrew.cmu.edu
Subject: Re: Unambiguous local addresses
Phone: +44-1-380-7294
In-reply-to: Your message of Thu, 08 Jan 87 10:47:16 -0800.
             <12269330845.37.BLARSON@USC-ECLB.ARPA>
Date: Fri, 09 Jan 87 09:35:04 +0000
Message-ID: <971.537183304@UK.AC.UCL.CS>
From: Steve Kille <steve@Cs.Ucl.AC.UK>



         From:    Bob Larson <BLARSON@arpa.usc-eclb>
         Subject: Re: Unambiguous local addresses
         Date:    Thu 8 Jan 87 10:47:16-PST

         People with exactly the same name will not be given accounts?!!  A
         new form of discrimination, I'd like to see you defense....
This was said slightly toungue in cheek.   In the short term,
we will genuinely do this (there are paper world precedents).
If we get that pathological clash, one or both will need to
register with a different name.   In the medium term, directory
services and a more flexible name structuring (see Dave
Crocker's message) will enable a more natural disambiguation in
these cases (e.g. by locale or department or work area).


         Using addresses that may suddenly become ambiguous as the from
         addresses is not a good idea, not only because of unreliable replying
         to your messages.  Mailing list maintainers would curse you for it.

Mailing addresses change quite a lot, and people leave, and......
Mailing list maintainers have too many instabilities already (I do
maintain more than one list).  I would cerainly suggest use of
"more stable" variants on lists (e.g. the list might contain
Andrew.Eustace.Jones, even if the From: was A.Jones).
However, I clearly agree that a "preferred" (i.e. From:) name
becoming ambiguous would be a substantial pain.   One thing we
would do (not stated last time) is to "transition" in all such
cases, so that there would be some use of the new From: field
before the old one did not default correctly.   This would help
with replies.   This is only acceptable if it is a pretty rare
occurence.   Howeever, I believe that removal of "unnatural"
ids is worth a SMALL number of clashes.

Steve

Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  9 Jan 87 05:25:46 EST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU  9 Jan 87 05:28:25 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2714637835076478@MIT-MULTICS.ARPA>; 09 Jan 1987 05:03:55 est
Message-ID:  <225907@QZCOM>
In-Reply-To: <SRA.12262762638.BABYL@XX.LCS.MIT.EDU>
Date:        08 Jan 87 09:53 +0100
From:        Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-To:    Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             HEADER-PEOPLE@AI.AI.MIT.EDU
Subject:     question on ReSent-To

A quiet reflection: comparing with X.400, the ReSent-xxx fields
would roughly correspond to the X.400.P1.Envelope.TraceInformation,
i.e. they do not really belong to the message header, rather
the envelope, 821.





Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 11 Jan 87 20:15:43 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 87 16:58:41 PST
Date: Sun, 11 Jan 87 16:58:26 PST
From: Murray.pa@Xerox.COM
Subject: Re: Unambiguous local addresses
In-reply-to: <MS.V3.20.cfe.80020ffd.lititz.ibm032.4483.0@andrew.cmu.edu>
In-reply-to: <VAX-MM(196)+TOPSLIB(122)+PONY(138) 8-Jan-87
 23:05:15.SRI-IU.ARPA>
To: cfe#@andrew.cmu.edu (Craig F. Everhart), Peter Karp
 <PKARP@SRI-IU.ARPA>
Cc: Arpa-MHS@BRL.ARPA, Header-People@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU,
 nsb#@ANDREW.CMU.EDU, Murray.pa@Xerox.COM
Message-ID: <870111-165841-4156@Xerox>

Craig:

If I was working on your problem, I would:
	1) Assign everybody a long name - something that would be almost
unique. (More later.)
	2) Disconnect your automatic attempt to try unix usernames.
	3) Gain back the functionality lost in step 2 by adding a manually
controlled alias table.
	4) Modify your mail sending software to automatically translate short
usernames and/or aliases into long/unique names, especially on mail that
goes off campus.

I said "almost" unique because I don't know how to totally solve that
problem. As the user community grows, clashes are bound to happen. My
guess is that names like "Craig F. Everhart" will be good enough for a
user community of 5000 to 10000 people. I'd expect a few soft-clashes
each year. I'd expect to be able to dodge around most of them one way or
the other, for example by using just a middle initial rather than
spelling out the whole middle name. I'm called Hal, but my formal/legal
name is Hallam. I have a friend named Craig, but he is really Robert.
His father had prior claim to Robert so he got Craig to solve the same
problem in a different context. ...

As the system grows, you will probably want to distribute the
responsibility for assigning names. Spliting on something like a
department level seems like a reasonable way to do that as well as
reducing clashes.

Somebody is bound to point out that long names are hard to type (and
ugly and...). True, but it's not as bad as you might think. You don't
type in names as often as you send mail. Most of the time, you use the
Answer, Reply, or whatever-your-system-calls-it command. On top of that,
many initial messages are sent through distribution lists. (It helps a
lot if the software used to maintain distribution lists automatically
fixes up aliases. Think of it as abbreviation expansion.) I might be a
bit far out on this one, but many systems now have a mouse. I can select
and copy a long name just as easily as a short one. Finally, you can use
aliases, so you don't have to type in the whole long name as long as you
know a short name and are willing to recover if/when the alias goes
away.

I feel that the stability of long names is necessary for tomorrow. An
alias table can bridge the gap during the transition. A bit of software
could probably make maintaining the alias table a lot easier and/or warn
you when an expected/automatic alias turns into a clash.

If you try to reduce the probility of name clashes, for example, by
suffixing the department name, you get into a different sort of trouble.
Parts of organizations occasionally get shuffeled and hence formal
department names get changed. History departments probably don't change
their name very often, but EE/CS departments are less stable. This also
happens within companies, Xerox being a wonderful example. In the case
that comes to mind, they just kept using the old names. New people ask
questions, but it works.

Our corporate telecommunications people suggested a neat trick. Make the
users long/unique name correspond to the one listed in the company phone
book. There probably has to be some simple algorithim, like delete
puncutation and compress duplicate blanks. (And for the arpa world,
change blanks to periods.) This would help a lot for internal mail, but
doesn't do any good for outsiders. Every little bit helps though, and
internal mail is a major portion of the problem. With a bit of work, you
could probably get the phone book online.

-----

From Peter Karp:

"For example, if I'm relaying a message from a DECnet to the Arpanet,
the return path will include the token "::", which is illegal under
RFC822.  One option is to double-quote the entire address."

If your goal is to simply and conviently exchange mail with as many
sites as you can, I strongly suggest that you avoid double quotes. Some
of our user names contain spaces. I tried quoting them. It doesn't work
very well. Postel told me I was asking for trouble. At the time, I
didn't understand what he was saying. After all, the specs were pretty
clear to me. Well, there are an amazing number of systems out there that
just can't correctly process quoted strings.

When we first started generating names with double quotes, we
encountered a somewhat expected flurry of confusion. I knew many of the
people who maintained the mail systems on nearby machines so we sorted
out the first layer of quirks right away. The next layer took a bit
longer to solve, but most of the major mail sites have pretty sharp
people taking care of them. Then I started getting replies like "Sorry,
we don't have sources" or "Huh, we are still using 2.8 and we don't have
a system programer". After a while, I figured out what Postel had
already told me.

We've had pretty good luck after we translated spaces to/from underbars.

This was several years ago. Things have probably gotten better around
the internet, but then, more systems are joining the metanet so I won't
bet that the change is actually in the right direction.

Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 Jan 87 09:16:08 EST
Received: from ucl-cs-vax2 by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa03306; 12 Jan 87 14:06 WET
To: cfe#@andrew.cmu.edu, Header-People@mc.lcs.mit.edu
Subject: Re: Unambiguous local addresses
Date: Mon, 12 Jan 87 13:59:45 +0000
From: george@Cs.Ucl.AC.UK


10000 users is of the same order of magnitude as the community of UNIX
e-mailers within the UK as a whole, at least those who know about and 
can use e-mail to the internet.

This size of community is too big for one person to administrate.

Assign username & friendly mailboxes for *ALL* academics in the UK from
rutherford laboratories? -nochance!

Trying to strike a balance between unambiguous names and ease of use is
going to prove very difficult in practice. Trying to maintain a single 
logical address-space of this size must be a nightmare *anyhow* so to my 
mind partitioning of the "namespace" is of dual benefit:

(1) smaller namespaces allow for shorter unique names

(2) partitioned management reduces the load per manager

Why not use local "dummy" hosts as logical sub-domains to divide
people/mailboxes up amongst the community? 

(1) logical domains do *not* have to map into any "physical" domain.

(2) method uses existing special characters, addressing format,
    so no problem with rest-of-world user training.
	-suggestions for assigning new chars in names/new formats
	have to address this problem.

(3) routing/aliasing is (at least) a known problem, if not a solved problem.
	-since most mail manages to (finally) route through the 
	internet we can assume a considerable body of knowledge 
	exists to cope with problems encountered here...

I suggest departments/faculties as a model of sub-domains, one global
administrator to assign domain-names to each, then each department using 
the computer system to nominate a name-manager who assigns terminal mailbox
names within that sub-domain.

	User.Friendly%Computer-Science@bighostname
	John.Smith%Physics@bighost
	John.Smith%Astro-physics@bighost
	John.Smith%Inst-Aardvark-Studies@bighost

...Catch-all is no-domain (ie just true host) for root, uucp etc etc

Lots of scope for providing special-case system-wide aliases to route
mail to heavy users sent stuff as person@bighost, also for inquiry
systems / intelligent replies for mail sent to site without sub-domain.

Can be implemented through special local-channel, final mailbox names
are any system-wide unique string, assigned from any dumb(ish) program.

	model: take any local area network and imagine set of separate
	       physical machines are logical sub-domains of the virtual 
	       machine...

	This model suggests to my mind that problems to be encountered
	are exactly the same as those encountered by a large community
	accessing a large pool of machines: dupication of mail, addressing,
	authorisation. Even if it provides problems of its own, they are
	likely to belong to a known set, rather than being fresh ones we
	don't know about yet.

Can even re-write login to ask for logical sub-domain before username
& have partitioned /etc/passwd....

	George Michaelson, University College London

PS X-400 probably *won't* solve all these problems (sigh)...

Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 13 Jan 87 04:17:06 EST
Received: from ub.com by csnet-relay.csnet id ag10891; 13 Jan 87 4:07 EST
Date:     Sun, 11 Jan 87 12:50:30 PST
From:     Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
To:       Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
cc:       "Craig F. Everhart" <cfe#@ANDREW.CMU.EDU>, Arpa-MHS@BRL.ARPA, 
          Header-People@MC.LCS.MIT.EDU, 
          "Craig F. Everhart" <cfe#@ANDREW.CMU.EDU>, 
          Jonathan Rosenberg <jr#@ANDREW.CMU.EDU>, 
          Nathaniel Borenstein <nsb#@ANDREW.CMU.EDU>
Subject:  Re:  Unambiguous local addresses
Organization:  Ungermann-Bass, Inc.

There is a very small, very important point that I forgot to include,
in my description of MCI Mail addressing.  Some notes that followed
suggest that I should have been explicit:

Mail that is sent from someone must have a unique identifier for that
person.  At the very least, it must be possible for a recipient's
auto-reply software to generate a return address that will work.

This is the kind of reason that drove us to define MCI ID numbers.  They
are not user-frienldy, but they are guarateed unique.  Even after their
owner goes away, re-use of a number is not supposed to happen (well, not
within our lifetime...).

There was not attempt to make logins unique for MCI Mail, for a marketing
reason; a smaller/different operation may want to merge unique id with
login.  (The marketing reason was that we wanted users to be able to
choose their own login name.)  Hence, login name is just-another-name,
like "Formal Name" and the same rules for disambiguation apply.

Dave

Received: from vax.darpa.mil (TCP 30001211143) by MC.LCS.MIT.EDU 13 Jan 87 05:23:38 EST
Received: by vax.darpa.mil (4.12/4.7)
	id AA20742; Tue, 13 Jan 87 05:21:30 est
Date: Tue 13 Jan 87 05:21:22-EST
From: Dennis G. Perry <PERRY@VAX.DARPA.MIL>
Subject: Re:  Re:  Unambiguous local addresses
To: dcrocker@engr.ub.com
Cc: dcrocker@engr.ub.com, cfe#@ANDREW.CMU.EDU, Arpa-MHS@BRL.ARPA,
        Header-People@MC.LCS.MIT.EDU, jr#@ANDREW.CMU.EDU, nsb#@ANDREW.CMU.EDU,
        perry@VAX.DARPA.MIL
Message-Id: <VAX-MM(195)+TOPSLIB(124) 13-Jan-87 05:21:22.VAX.DARPA.MIL>
In-Reply-To: Message from "Dave Crocker <dcrocker@engr.ub.com>" of     Sun, 11 Jan 87 12:50:30 PST

Los Alamos also has 'unique' id numbers, it is also you badge number.  How
many site have to move to unique id numbers before some sites choose the 
same numbering mechanism and start with the same seed.  Perhaps the
spector of end times is upon us, where the unique id willl be written upon
our forehead!

dennis
-------

Received: from BRL-SEM.ARPA (TCP 30001213410) by MC.LCS.MIT.EDU 13 Jan 87 20:02:12 EST
Date:     Tue, 13 Jan 87 19:43:05 EST
From:     Ron Natalie <ron@BRL.ARPA>
To:       "Dennis G. Perry" <PERRY@vax.darpa.MIL>
cc:       dcrocker@engr.ub.COM, dcrocker@engr.ub.COM, cfe#@andrew.cmu.EDU, 
          Arpa-MHS@BRL.ARPA, Header-People@mc.lcs.mit.EDU, jr#@andrew.cmu.EDU, 
          nsb#@andrew.cmu.EDU, perry@vax.darpa.MIL
Subject:  Re:  Re: Unambiguous local addresses
Message-ID:  <8701131943.aa08017@SEM.BRL.ARPA>

Several of us proposed at Martin Marietta to have the phone switch
modified so that using your badge number as your extension number
would always get you to the right place.

-Ron

Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 18 Jan 87 19:30:21 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2715466860193766@MIT-MULTICS.ARPA>; 18 Jan 1987 19:21:00 est
Message-ID:  <228235@QZCOM>
In-Reply-To: <MS.V3.20.cfe.80020ffd.lititz.ibm032.4483.0@andrew.cmu.edu>
Date:        18 Jan 87 19:18 +0100
From:        Matts_Kallioniemi%QZCOM.MAILNET@MIT-MULTICS.ARPA
Reply-To:    Matts_Kallioniemi%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             arpa.mhs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
To:          Header_People_mailing_lists%QZCOM.MAILNET@MIT-MULTICS.ARPA,
             "X.400/ARPA Conversion" <ARPA-MHS@BRL-AOS.ARPA>,
             header-people@MC.LCS.MIT.EDU,
             arpa.mhs_mailing_list%QZCOM.MAILNET@MIT-MULTICS.ARPA
cc:          "Jonathan Rosenberg" <jr#@ANDREW.CMU.EDU>,
             "Nathaniel Borenstein" <nsb#@ANDREW.CMU.EDU>,
             "Craig F. Everhart" <cfe#@ANDREW.CMU.EDU>,
             John_O'Connor_UCD@EUROKOM.UUCP
Subject:     Unambiguous local addresses

Craig,

Would it be a bad idea to consider your personal mailbox as a subdomain?
I.e. <photo@cfe.andrew.cmu.edu> and in the from: something like
<mailbox@cfe.andrew.cmu.edu> or perhaps prettier <cfe@cfe...>


Matts Kallioniemi, Systems Programmer, KOMunity Software




