From bblue Sat Sep 19 11:19:49 1987
Date: Sat, 19 Sep 87 11:19:45 PDT
From: bblue (Bill Blue)
To: jeh
Subject: Re: an addressing question

You write:
>How are ! and @ operators handled when there are both pre-@ and post-@
>!'s in the address?  For instance, suppose someone gives me an address
>of 
>        system!user@dept.company.COM
>
>I've gotten some like this, and been able to send mail to them from 
>pnet just by saying
>
>        crash!system!user@dept.company.COM
>
>What I think is happening is that you can go from a bang-path, 
>through domain, to another bang-path.   The first machine in the
>bang-path that understands @'s (in this case crash) processes the
>@, and what's left of the bang-path is processed at the target
>machine of the @-path.  True?
>
>        --- Jamie

You seem to have a good mental picture of things.  The key to understanding
what happens is routing is having a general idea which machines give
precendence to !'s and which to @'s.  If you go crash!user@site, crash
gets user@site and converts it to site!user for delivery to site.  Sites
that do @ to ! conversion, always produce a full ! path as far as their
conversion is concerned.  The exceptions would be if there is more than
one @ in a path.  It's not exactly legal syntax, but does occur.  For
example, the path crash!user@site2@site1 would go to crash as user@site2@site1
and get converted to site1!user@site2 for delivery to site1.  Then site1
would do further conversions if it understands @ routing.  I do this
occasionally if I want a different site to 'smartroute' for me, 'cause I
know the route they'll produce will be different from what crash's router
would produce.

The only fly in the ointment in all of this is machines that optimize even
specific routes.  If you had something like crash!site1!site2!user@site3,
crash would get site1!site2!user@site3 and convert to
site3!site1!site2!user for delivery to site3.  Now, if site1 was an optimizer
when it gets the path site2!user from site3 it might very well change the
path.  But it will always do so in standard ! syntax by inserting the
new path in front of site2.

Oh, and in case it isn't obvious, crash!somesite.bozo.com!user is perfectly
legal, and is the same as crash!user@somesite.bozo.com.  In fact, that's
how the conversion would take place.  Say if bozo.com was gotten to by
the route of hp-sdd!hplabs!rutgers, crash would convert the path to
hp-sdd!hplabs!rutgers!somesite.bozo.com!user.  

--Bill

Message-ID: #584.pnet01.digest/info-nets 67 lines, 2435 chars.
Reply-To: crash!decwrl.DEC.COM!sdchem!!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:shimono%tkov58.DEC
Date: 10-May-1987 1758  <posted Sun, 10 May 87 06:56:12 PDT>
From: crash!decwrl.DEC.COM!sdchem!shimono%tkov58.DEC  (Takao 'Ta?i' Shimono)
To: Info-Nets@mc.lcs.mit.edu, shimono%tkov58.DEC@decwrl.DEC.COM
Subject: FYI: Address for Japanese sites (JUNET)

  The following below is a recent Info-Japan article
  on the e-mail address to Japanese JUNET site.
  JUNET stands for Japan Uni? NETwork as well.

  forwarded to Info-Nets without permission by
                   -Ta?i (Takao shimono%tkov58.DEC@decwrl.DEC.COM)
..................... ? is a trademark of Project Hatena in Japan.
......................?...........................................
From:	RHEA::DECWRL::"Hiroshi "Gitchang" Okuno Okuno@SUMEX-AIM.STANFORD.EDU" "Hiroshi GITCHANG Okuno" 18-APR-1987 13:22
To:	stuart%hwalhw50%WISCVM.WISC.EDU@SUMEX-AIM.STANFORD.EDU
Subj:	RE: hiroshima university address
[ some header lines deleted by -Ta?i]
Date: Thu, 16 Apr 87 11:17:52 PDT
Cc: info-japan@MC.LCS.MIT.EDU, nishimura@SUMEX-AIM.STANFORD.EDU
Message-Id: <12295015606.13.OKUNO@SUMEX-AIM.STANFORD.EDU>

As far as I know, there is no host of Hiroshima University on the
JUNET (Japanese University NETwork).  Hiroshima may be on the BITNET,
but I don't know.

JUNET consists of university and non-university members and 
each group has its own international gateway:

To send a message to a university, use CSNET:

	<user>%<host&subdomain>.junet%utokyo-relay.csnet@relay.cs.net

To send a message to a non-university, use UUCP:

	kddlab!<host&subdomain>.junet!<user>@seismo.CSS.GOV
or
	{ihnp4, seismo, hplabs, mcvax}!kddlab!<host&subdomain>.junet!<user>

The university subdomains are u-tokyo, waseda, keio, titech, uec, tsukuba,
tsuda, shizuoka, nagano, tokoku-u, kyushu-u, kyoto-u, sophia,
hokkaido, osaka, kobe, seikei, toyohashi, ulis, yamanashi, yokohama
and so on.  Hiroshima and nagoya are not on the JUNET.  If you have a
qustion, you may contact the postmaster of each domain.

[Note 1] According to Mr. Takagi, ICOT, the following addresses are
valid, but I have no experience:

	<user>%<host&subdomain>.junet%japan.csnet@relay.cs.net
and
	<user>%<host&subdomain>.junet@seismo.CSS.GOV

[Note 2] ICOT is a member of CSNET and its address is

	<user>%icot.jp@relay.cs.net

[Note 3] NTT is *not* a member of JUNET and has its own international
gateway.  The address to the NTT-domain is

	<user>#<host>.ntt%nttca.uucp@shasta.stanford.edu  (to univ.)
or
	...!shasta.stanford.edu!nttca!<host>.ntt!<user>   (to non-univ.)

NTT will become a member of CSNET soon and its address is

	<user>%ntt.jp@relay.cs.net
or
	<user>%<host>.ntt%ntt.jp@relay.cs.net

[Note 3] MITI's Lab, ETL, is not a university site.

- Gitchang -

Message-ID: #602.pnet01.digest/info-nets 16 lines, 442 chars.
Reply-To: crash!ATHENA.MIT!sdchem!!MC.LCS.MIT.EDU:!OZ.AI.MIT.EDU:!MC.LCS.MIT.EDU:henry
To: "David D. Story" <FTD-P%MIT-OZ@MC.LCS.MIT.EDU@ATHENA.MIT.EDU>
Subject: Re: Path to Woods Hole Oceanographic Institute ...UUCP 
Date: Fri, 22 May 87 13:07:21 EDT  <posted Fri, 22 May 87 23:54:11 PDT>
From: Henry Mensch <crash!ATHENA.MIT.EDU!sdchem!henry>

>> 	Anyone on in net land have a path to Woods Hole.

Woods Hole Oceanographic Institution (WHOI-DOM)
   150 Clark Laboratory
   Woods Hole, MA 02543

   Domain Name: WHOI.EDU

   Administrative Contact, Technical Contact, Zone Contact:
      Maffei, Andrew R.  (ARM5)  mit-erl!aqua!arm@EDDIE.MIT.EDU
      (617) 548-1400 ext 2764

   Domain servers:

   AQUA.WHOI.EDU                128.128.16.1
   POLAR.WHOI.EDU               128.128.24.5
Message-ID: #609.pnet01.digest/info-nets 23 lines, 1244 chars.
Reply-To: crash!XX.LCS.MIT.EDU!xrjjm%scint.span%JPL-VLSI.ARPA
Date:    Tue, 26 May 87 10:05:09 PDT  <posted Tue, 26 May 87 17:16:26 PDT>
From: crash!Jpl-VLSI.ARPA!sdchem!xrjjm%scint.span
Subject: Woods Hole... Part 2...
To: Info-Nets@Oz.Ai.Mit.Edu

Comment:   Begin User Supplied Mail Headers.
*Site:     NASA Goddard Space Flight Center - Greenbelt, Maryland, USA.
*Position: 76 Deg. 52' 28.5" West, 38 Deg. 59' 59.8" North.
*From:     John J. McMahon, Systems Programmer, STX - ST Systems Corporation.
*Project:  COBE Science Data Room (CSDR), Code 401.1
*Reply-To: (Arpa-Internet)       XRJJM%CSDR.SPAN@JPL-VLSI.ARPA [Old Format]
*Reply-To: (Arpa-Internet)       XRJJM%CSDR.SPAN@VLSI.JPL.NASA.GOV [New Format]
*Reply-To: (Bitnet)              ZMJJM@SCFVM
*Reply-To: (Span/Physnet/Hepnet) 6173::XRJJM = CSDR::XRJJM (Node 6.29)
*Reply-To: (TEXnet)              UTADNX::UTSPAN::CSDR::XRJJM

In addition to the info posted about Wood's Hole previously, they have 
several Vaxes on the Nasa Space Physics Analysis Net (SPAN).  These
nodes include "RED", "BLUE", "AQUA", "RSVP", "SLATE"... a few other
colors.. etc.  Arpa-Internet mail to these nodes can be routed thusly:

userid%node.SPAN@VLSI.JPL.NASA.GOV (or @JPL-VLSI.ARPA)

Regards,
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
John J. McMahon (Fast-Eddie)                     
Disclaimer: Views expressed in this letter are my own, 
            and are not meant to represent the views of my employers.
From ncr-sd!ncrcae!hubcap!gatech!seismo!mcvax!enea!liuida!lel Mon May 18 08:59:09 PDT 1987

In article <588@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> The solution is trivial though it would need a change in most
> software.  Introduce symbols that allow you to group address
> components.  I have used parentheses above, but they are already
> taken.  Perhaps square brackets could be used.

The solution is NOT to introduce more symbols.  There are many enough
already, thank you.  What is needed is the conformance to a single
standard, whenever possible, and for the Mail Transfer Agents to
otherwise do intelligent full translations from the transmitting net's
standard to the receiving net's.

In article <958@xanth.UUCP> kyle@xanth.UUCP (kyle jones) writes:
> What we DO need are some rules on how to interpret the wild mixes of the
> non-standard operators such as "%", "!", and "::".  The precedences we use
> here are "@ then "!" then "%".  "::" is a horror from some network of which
> we're (apparently) not a member.  Also I've seen addresses with "@!" and "!@"
> in them.  Any ideas on what to do with these???

OK, let's see:
   "!" is used as a routing operator in the UUCP world.
   "%" on top of "@" is a de facto routing operator in the ARPANET world.
   "::" is a routing operator for VAX/VMS mail.
   "!@" can appear on RFC822 routes embedded in UUCP paths, as in:
	node!node!@domain,@domain:user@domain

Let's then assume that you are a Domainist, ie. you will give "@"
precedence before "!" by parsing routes like:
   node2!node1!user@node3
as:
   node3 -> node2 -> node1 -> user

Now, since "%" is the natural routing operator on top of "@", an
address like:
   node1!user@node2
that is autorouted through "node3" will probably end up looking as:
   node1!user%node2@node3
meaning:
   node3 -> node2 -> node1 -> user

Giving "!" priority over "%" is clearly an error in this case.  However,
if you have a "!" path address ending with a "user%node", you can safely
prioritize "!" over "%", since this cannot be interpreted as a domain
address.  Thus,
   node3!node2!user%node1
should be read as:
   node3 -> node2 -> node1 -> user

One thing that *could* complicate this, is VAX/VMS mail that uses "%"
as special operator delimiting a "Foreign Mail Protocol" from the host
name, as in:
   PSI%24020010040403::LISBET::L-LOVSTRAND
meaning:
   to host 24020010040403 using the Packet Switched Interface, then
   -> LISBET -> L-LOVSTRAND

Fortunately, I haven't seem much of them on the net.  Their forwarding
MTAs seems to be intelligent enough to properly translate them into the
receiving net's standard.  I just wish more MTAs would do the same thing
with "!" addresses going into domain land...

Oh well, just wishing.
--Lennart
(Or perhaps not, see "Electronic Mail Addressing in Theory and Practice
 with the IDA Sendmail Enhancement Kit" being released to you on this net
 (very) shortly)


From ncr-sd!ncrcae!hubcap!gatech!rutgers!ames!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!hpfclp!diamant Mon May 18 09:01:36 PDT 1987

> Also I've seen addresses with "@!" and "!@"
> in them.  Any ideas on what to do with these???
> 
> kyle jones   <kyle@xanth.cs.odu.edu>
> old dominion university, norfolk, va

The first form ("@!") is total trash and I haven't the faintest idea what
you could do with it (I've never seen one either).  The second form ("!@")
occurs when mail is sent from RFC-822 world into UUCP and the From: line
had a source route in it and the gateway doesn't know what to do with it.
I regularly see mail coming from hplabs (my ARPANET gateway) of the form:

hplabs!@foo:user@bar

If this is the kind of thing you are talking about, you can ignore everything
up to the first @ and treat it like a standard RFC-822 source route.  Of
course, you aren't allowed to do that by RFC-822, since this address
is already illegal and no standard is going to tell you what to do with
an illegal address.


John Diamant
SCO				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO


From ncr-sd!ncrcae!hubcap!gatech!rutgers!ames!ptsfa!ihnp4!meccts!ahby Mon May 18 09:02:17 PDT 1987

In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) writes:
All sorts of excellent information about routing and routing
symbols...
>Now, since "%" is the natural routing operator on top of "@", an
>address like:
>   node1!user@node2
>that is autorouted through "node3" will probably end up looking as:
>   node1!user%node2@node3
>meaning:
>   node3 -> node2 -> node1 -> user

It seems to me that undef RFC 976, something autorouted through "node3"
should be transmitted as:
    node2!node1!user@node3

Also, since "node2" started life after an @, it must by definition have a 
domain suffix attached to it.  So, if th initial address had been:
    node1!user@node2.edu
it would be autorouted as:
    node2.edu!node1!user@node3
which, under RFC 976 and UUCP would be translated for forwarding as:
    node3!node2.edu!node1!user
-- 
Shane P. McCarron		UUCP	ihnp4!meccts!ahby, ahby@MECC.MN.ORG
MECC Technical Services		ATT	(612) 481-3589
(C) Copyright 1987 Shane P. McCarron
	Redistribution allowed only if your recipients can redistribute


From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!ptsfa!vixie!paul Mon May 18 09:03:13 PDT 1987

Since I've already come out for leaving the From: line alone, it won't
surprise anyone that I totally disapprove of adding .UUCP to an address.

My own domain name is currently vixie.UUCP, because I'm in between 
installing smail and registering the domain.  .UUCP is "used for testing
only"... (giggle)

I'd previously said that a host shouldn't use .UUCP because sendmail.cf's
often use it as a mock domain (instead of the newer ".UUX").  This is true,
but misleading.  You shouldn't use .UUCP because it is not a registered
domain -- there is no "authoritative site" for it, no domain administrator,
no MX records, no nothing.

The UUCP domain is being split (has been split) into the .COM, .EDU, .ORG,
etc. domains.  There is no .UUCP domain.

In <771@mcgill-vision.UUCP> (ugh), Der Mouse says:

>Something that seems to be getting commoner is interpretation of
>foo.bar!user as meaning the same thing as user@foo.bar - the .uucp gets
>added only if there are no dots in the "host" part.  This allows two
>intelligent hosts to speak to one another using a dumb !-only host as
>their link.

I think he may be confused.  Some sendmail.cf files will use a .UUCP or
.UUX internally to mark an address which either came from or is destined
for a UUCP-linked neighbor.  The .UUCP (.UUX) should be stripped off
before the mail is actually queued.  In practice, this is often not done;
thus many sendmail.cf's will strip it off of incoming mail, hopefully
before adding their own magic cookies to it.

>What I shudder to see are things like netnews postings with messes like
>
>From: user@host.dept.univ.edu.UUCP

Since the news software is older than the UUCP domain breakup, I can't
really blame it for adding ".UUCP" to addresses without "."'s in them.
Since they do this, the above address is not likely to be seen.

What news software OUGHT to do is just leave the darned addresses alone,
with provision for the news admin to force their full domain name to be
added instead of just their host or UUCP name.

Mail software, same policy: don't add .UUCP to anything leaving your
machine.  ("Smail test-mode sites excepted, of course," said paul@vixie.UUCP)
-- 
Paul A. Vixie        {ptsfa, crash, winfree}!vixie!paul
329 Noe Street       dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU
San Francisco        
CA  94116            paul@vixie.UUCP     (415) 864-7013


From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucbvax!cbosgd!stargate!pleasant Fri Jul 31 13:23:50 PDT 1987


This is a *MUST READ* announcement for all site administrators
maintaining map entries published in the comp.mail.maps newsgroup.  Please
read the entire message carefully before attempting to modify your entry.


In an attempt to comply with RFC822, RFC976 and other mail
standards documents, The UUCP Mapping Project will no longer publish map
entries that contain certain types of constructs.  Since most of these
constructs have not been accepted in new map entries for quite some time,
most of you will not be affected by this announcement.  Sites that
currently have these constructs were allowed to keep them through
grandfather clauses that can no longer be invoked.  One currently accepted
construct, involving the use of pathalias network characters, will
unfortunately no longer be accepted.  So, with your current map entry at
your side, I urge you to read the entire announcement, make corrections as
appropriate, any send in your update.  Since I'll be on vacation until the
end of August, questions will be fielded by Mark Horton (stargate!mark).


 o - site and domain names may contain the following characters: a
     through z, 0 through 9 and dash (-).  Fully qualified domain
     names may contain the character dot (.).  No other characters,
     including uppercase alphabetics and underscore will be accepted
     anywhere in the name.  In addition, site names and each section
     of the domain name must begin with a lowercase alphabetic and
     may *not* end with a dash.

	The above applies to all names given on the #N and #F lines as
	well as all names that appear in the link description portion of
	your map entry.  It does *not* apply to pseudo network names used
	to help describe internal networks, as defined in the pathalias
	documentation.


 o - The link description of your entry as published by the UUCP Mapping
     Project must generate pure "bang" paths.  Essentially, the only
     network character (as documented in the pathalias man page) allowed
     in a published map entry will be the bang (!).

	RFC976 defines the @ network character as having precedence over
	the bang (!) when both appear in mixed mode addresses.  This
	essentially invalidates the use of the @ and other network
	characters as they were commonly used in the UUCP community, except
	at the local level.


As stated earlier, this announcement will have no effect on the vast
majority of you.  However, it can have a profound effect on those who wish
to have their entry published but do not currently comply.  For one, a
small percentage of you will have to change your site name.  In doing so,
you'll have to contact all of your uucp neighbors and co-ordinate the
change with them.  An even smaller percentage will have to change domain
names.  We recognize that, for those of you who have to make some change,
doing so can be a vast undertaking.  To that end, we do not plan to
publish another set of maps to the comp.mail.maps newsgroup until
September 11th.  We hope that everyone will be able to affect the
necessary changes within the next 5 1/2 weeks.  We recognize that domain
name changes will have to be co-ordinated with the NIC and will not take
any default action while that effort is working its way through the mill.
Members of the UUCP Zone having to make a domain name change due to this
announcement will not incur any additional fees or charges.


At posting time (September 11), the following default actions will take
place for any site or domain name that does not comply (except as
previously noted):

 o - All uppercase characters in a sitename will be converted to lowercase.

 o - Any sitename that begins with other than a lowercase alphabetic, ends
     in other than a lowercase alphanumeric, or contains underscores will
     cause either a link or an entire map entry to be dropped.  If the
     offending name is the map entry's name (#N) or the name of the
     forwarder (#F) the entire map entry will be dropped.  In all other
     cases, the particular construct will be dropped.  In general, this
     will be the link in which the name is involved.

     EFFECTIVE IMMEDIATELY, names containing dashes that *would* match
     existing names containing underscores are now placed on reserve i.e.
     the name "why-not" is on reserve for the site "why_not" and will
     remain so until September 11th.  Note, we will not actually make this
     type of change for you.  We're simply setting aside the most obvious
     name that you might want to use for your site.

 o - Any links that will cause pathalias to generate other than a pure
     bang path will be modified such that a pure bang path will be
     produced.  Note that we will make an educated guess here.  If you
     don't want us guessing, update your map entry.  In most cases, our
     guess will consist of dropping the network character involved.


-Mel Pleasant (cbosgd!uucpmap)
-UUCP Mapping Project


From ncr-sd!ncrcae!hubcap!gatech!ukma!rutgers!umd5!brl-adm!adm!netinfo%garnet.Berkeley.EDU@violet.berkeley.EDU Tue Nov 17 10:34:07 PST 1987

I have noticed at least one mail gateway for a UUCP zone domain name that
does not do domain to uucp address conversion, but expects the non-domain
name address mail transport agents down the line to be able to interpret
domain names.  Please, if you are setting up a mail exchanger (MX) entry
in an Internet domain server, remember that your mail gateway is also
responsible for doing any needed address conversion.

Bill Wells
postmaster@jade.berkeley.edu

From ncr-sd!hp-sdd!ucsdhub!sdcsvax!ames!husc6!necntc!ima!think!barmar Sun Dec 20 14:55:41 PST 1987

In article <569@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>To:	personA,personB,personC@machine1.smalldomain.largedomain
>
>	If the above address is attached to a message whic is received
>at a machine which is a member of "largedomain", that machine will
>look for "machine1" and if not found "smalldomain".  If neither is
>found then the message will be frowarded to the top of "largedomain".
>If this is the top of large domain, the message will bounce [fail].
>This domain-resolution will continue through each seccussive domain
>until the machine is found or the samllest domain is encountered and
>fails to resolve the machine refrence.

Domains are name registries; a machine is not a member of a domain,
but its name can be.  I'll presume this is what you mean when you say
"a machine which is a member of 'largedomain'".  Now that I've cleared
that up, I'll tell you that it doesn't matter what domain the
receiving machine's name is a member of.  Binding a domain name to a
machine is independent of the local machine's domain.

What happens is that when a machine wants to send mail to an address
whose domain part (the part after the @) is of the form
name1.name2.name3 it tries to contact the nameserver for the
name2.name3 domain, and asks it for the information on how to send
mail to name1.name2.name3.  If it doesn't know the address of the
name2.name3 nameserver (possibly because there isn't one) it makes the
query of the nameserver for name3, and so on up the domain hierarchy.
When it finally gets to a point where it knows the appropriate
nameserver (the process must end because everyone is supposed to know
the addresses of the root nameservers, although it is conceivable that
all of them could be down simultaneously), the nameserver will either
give it the information or tell it to ask the server for a subdomain
(and hopefully it will include the address of the server).  This could
be repeated when the machine queries the specified nameserver, etc.,
but eventually it will find out how to send mail to name1.name2.name3.

The message would never actually be transmitted to name2.name3 or
name3 unless the mail information for name1.name2.name3 specifically
says that one of these hosts should be used for mail addressed to it.
But it is just as possible for the mail information for
name1.name2.name3 to specify that its mail should be delivered to
other1.other2.other3.  But if no nameserver has ever heard of
name1.name2.name3 the message will be returned.

>	Upon reaching "machine1" the message will be delivered to
>three seperate accounts "personA" "personB" and "personC"  If any of
>these accounts do not exist then those messages will bounce without
>interfeering with deleivery to the accounts which do exist.

This is wrong.  First of all, the above header is invalid, because all
addresses must be of the form <user>@<domain>.  There is no automatic
grouping.  If your mail-sending program allows the above To: line and
interprets all the addresses as being on
machine1.smalldomain.largedomain, then it must translate them to the
standard format before transmitting the message over the network.
When the SMTP protocol is being used to transfer mail between
computers the header isn't actually used, though; the recipients are
specified as part of the SMTP protocol, and the header is just part of
the data portion.

>To:	personA@sdomain.mdomain.ldomain
>
>	The top of "sdomain" will be sought [as above] if it can be
>found, it will search it's accounts, aliases, mailing-lists, and
>group-lists [as exist] for an account or refrence to "personA" and
>send the message to that [those] accounts.  A list of accounts [as
>above] may exist in place of "personA" [i.e.
>"group1,group2,list1,personB,personC"]

How a message is delivered once it is received by the destination
mailer is completely up to that host.  Your description above is
typical of most systems, though.

>To:	personA@machine1%machine2%machine3
>
>	The sending machine will send to "machine1" and remove
>"machine1%" from the address [netting personA@machine2%machine3%].
>machine1 will similarly forward to "machine2" removing "machine2%"
>[netting personA@machine3].  Machine2 will forward to "machine3"
>leaving the header unchainged.  Machine3 seeing "personA@machine3"
>will deliver to that/those account/list/group.

No.  Everything to the right of the @ MUST be a domain name.  There
are some machines that recognize %, but it must be to the LEFT of the
@.  The syntax of an address is <local-part>@<domain>.  The syntax of
<local-part> is arbitrary, and this is what permits hosts to treat
some characters within it as routing information.  The use of % is
completely unsanctioned by standards, but it has become extremely
common.  The way the above would usually be written is

To: personA%machine3%machine2@machine1

The important point is that the host sending to machine1 doesn't have
to recognize % for this to work; as far as it is concerned, it is
sending to a user whose name contains a bunch of % characters (and
there's no reason why some computer system couldn't have users with
such names).  When machine1 receives it, it presumably replaces the
last % in the <local-part> with an @ and drops its own name, resulting
in "personA%machine3@machine2" and reprocesses this normally, by
sending it to machine2.


>To:	personA@machine1%machine2@machine3%machine4
>
>	This one I am not shure about.  My best guess would be:
>machine3->machine4->machine1->machine2.  It is clear that the "%"
>[percent] symbols can be used like a bang path for explicit routing.
>It is also clear that the "@" [at] sign has higher precidence, and
>that the "@" groups right to left, leading me to read this as "personA
>(at machine1 then machine2 (at machine3 then machine4))".  Of course
>"personA" may again be a list [as above].

Multiple "@" are not permitted in an address.  However, this can be
permitted by using quoting, e.g.

To: "personA@machine1"@machine2

The quoting removes the special interpretation of the first @, so this
becomes an address whose <local-part> is personA@machine1 and whose
<domain> is machine2, so the message would be delivered to machine2.
If machine2 happens to treat an @ embedded in the <local-part> as
routing information (like % above) then this is a way to force
routing; however, again, the interpretation of <local-part> is
completely unspecified.

>	IS THIS CORRECT??
>
>To:	machine3!personA@machine1%machine2
>
>	This again is a guess: machine1->machine2->machine3->personA
>	IS THIS CORRECT?

First, I'll treat the above as "machine3!personA%machine2@machine1",
correcting your earlier error.

The interpretation of an address that contains both ! (the UUCP
routing character) and @ (the SMTP routing character) depends on the
way the host processing the address is configured.  A host that only
knows about UUCP will most likely not recognize the @ at all, so it
will treat the above as the user "personA%machine2@machine1" on host
"machine3", so the message will probably take the path
machine3->machine-1->machine2->personA.  A host that doesn't know
about UUCP will ignore the !, so it will treat it as user
"machine3!personA%machine2" on host "machine1", and the actual path
will depend on how machine1 deal with ! and %.  If a host recognizes
both then one of them will have to have a higher precedence than the
other, to resolve the ambiguity, and quoting could be used to force
grouping.  Some systems adjust the precedence based on the protocol
used to receive the message, so that if a message is received using
UUCP protocol the UUCP addressing style will be favored.

>To:	machine2!personA,personB@machine1
>
>	Another Guess: machine1->personB
>				>machine2->personA
>	IS THIS CORRECT?  IS IT LEGAL?

Well, I would treat this as machine2->personA and machine1->personB,
because none of the mail sending programs I use automatically group
comma-separated addresses as being for the same host.  In other words,

To: personA,personB@machine1

is equivalent to

To: personA
To: personB@machine1

and most systems interpret the first line as meaning personA on the
local system.

>To:	(text)
>
>	The material within the "(" [lparen] and ")" [rparen] is a
>comment, and generates NO delivery address or forwarding at all.
>	IS A COMMENT ALONE ON A LINE LEGAL?

The only address field that may contain no addresses is the BCC:
field.  All the rest require at least one address.

>Also, any of the above formats may occur on the same line as any other
>as long as there is at least one unit of whitespace seperating each
>form of address.  The order of such combination, or multiple
>occuarances of the "To:" "Cc:" and "Bcc:" header lines are immaterial
>to the delivery, and should be processed on a first come first served
>basis.

Well, since the header isn't used to determine delivery information,
the order is obviously immaterial.  A message may be delivered to
people no listed in the header at all.  This can often happen when
using blind-carbon-copy, since it is permitted to leave the BCC: field
empty.  The SMTP protocol looks like:

MAIL FROM:<user1@domain1>
RCPT TO:<user2@domain2>
RCPT TO:<user3@domain2>
...
DATA
<header>
<blank line>
<body>
.

The message is delivered to user2 and user3, regardless of the names
specified in the header.  I am aware that there are other mail
delivery protocols that do actually use the addresses in the header.

>Precidence map:
>
>	"(" ")" 	Grouping L->R	MAtched Pairs required.

Since parentheses are not binary operators, I don't know what you mean
by "grouping L->R".

>	"," "@"		Grouping R->L
>	"%"		Grouping L->R
>	"!"		Grouping L->R

The actual precedence is more like:

	double-quotes	No grouping	Matched Pairs required
	( )		No grouping	Matched Pairs required
	,		No grouping
	@ !		! groups L->R
			only one @ permitted
	%		groups R->L
	

>Finally, a question:  I have seen ";" [semicolon] refrenced in some of
>what I have read on mail addressing.  What is the ";" for and have I
>missed any other symbols?

There is a special address syntax allowed instead of
<local-part>@<domain>, called named groups, whose syntax is:

	<name>: <users> ;

where <users> is 0 or more <local-part>@<domain> addresses (if <users>
is empty then this is just a placeholder for an unenumerated mailing
list).  This syntax only exists in headers, it isn't allowed in the
SMTP delivery protocol.

The complete specification of the format of message headers is in
RFC-822.  SMTP is described in RFC-821.  If you have access to the
Internet these can be copied from SRI-NIC.ARPA, from the files
RFC:RFCnnn.TXT.  You can get hardcopy from the DDN Network Information
Center; for information on this, call (800) 235-3155 between 7am and
4pm Pacific time.  Of course, neither of the above standards will
mention % or !, since they aren't officially part of the protocol.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar

  There's another rule that applies if there's an internet address
  in the bangpath.  If you send to an address like
  
  	a!b!c!d!user@system.site.domain
  
  it goes to a, then b, etc., until it hits a site that understands @-addresses.
  If this happens to be b, the address effectively becomes
  
  	a!b!system.site.domain!c!d!user
  
  Which is to say, b hands it to internet; eventually it reaches 
  system.site.domain, who then sends it to c, etc.  If we had grouping 
  operators, the address would look like 
  
  	a!b!(c!d!user@system.site.domain)
  
  but only because it's b who interprets the internet address.  


From crash!bblue Tue Mar 31 19:57:18 1987
Received: by crash.CTS.COM (5.54/UUCP-Project/rel-1.0/09-14-86)
	id AA14677; Tue, 31 Mar 87 19:20:26 PST
Date: Tue, 31 Mar 87 19:20:26 PST
From: crash!bblue (Bill Blue)
Ppath: pnet01!jeh
To: jeh@pnet01
Subject: misc

An address of the form

	a!b!user@gateway-site.domain

Is up for grabs depending on how the local site handles things.
If that address was entered on crash, or any other site that understands
domainized addressing, the @ stuff will be processed first, expanded,
and then the a!b!user stuck to the end.  The equivalent would
be gateway-site.domain!a!b!user, and gateway-site.domain would be
replaced by a real route if they are not one hop from the originating
site.

The only places where the a!b would be processed first would be on
a site that does not understand @'s.  Under normal circumstances
a site that does understand @'s will not produce a path with any @'s
left in it - pure !'s are supposed to be for transports.

There are some systems that allow "" for grouping, but I have no idea
who they are.

When you deal with or write hybrid addresses such as your above 
example, you should be very sure about what sites understand @'s
and what ones don't.

Trick:  If I wanted to get some @ syntax out, say, to hp-sdd for
it to process, I could do user@sitename@hp-sdd.  Crash would send
user@sitename to hp-sdd who would then look things up and substitute.
The % operator is also used in that fashion, but should only be used
in specific places where it is a known host that gets the resulting
syntax and knows to convert it to @ and continue processing.  Happens
most frequently across networks.

You are correct about the nameserver lookup for domains if they are not
known locally.  And any site that cts.com (for example) knows about
could currently be addressed via that domain.  jeh@jehsystem.cts.com
would work if jehsystem was known to crash.

Yes, crash.cts.com is redundant, but is included for overall clarity
since it may not be clear to all that crash is cts.com.  In the mapping
database you can name sites and domains that crash is the same as, but
also is knowledgable of.  So crash=.cts.com, but crash is also knowledgable
of cts.com, .cts.com and crash.cts.com.  The net result is that all
variations of the syntax work, redundant or not, since crash IS the
domain cts.com.

The usability of jeh@pnet01.cts.com depends on the NIC nameserver
knowing who the forwarder for cts.com is (in this case it is uiucuxc),
uiucuxc knowing how to contact crash (which it does, directly), and
crash knowing of pnet01.  Even if the nameserver didn't know of cts.com,
it still does know of .com (seismo) and seismo would know of .cts.com
since that's all part of the uucpmap postings.  So there can be a large
amount of error in uucp sites databases and it won't affect the domain
address as long as the forwarder and the nameserver are knowledgable.
Within the uucp world (not across networks), for a site to know directly
how to get to crash.cts.com, it would have to have an up to date database.
Otherwise it would have to know how to get to either cts.com or .com
in the hopes that one of them can resolve the path.  If a site had
no such database, a route would have to be expressley provided, or
the path passed on to a relay site - one that did know routing.

This is all sort of confusing, I know.  I had a heck of a time getting
the whole thing to sink in.  Hope I didn't confuse you more.

Here comes the newsgroups list.  It (btw) can be found in 
/news/lib/news/newsgroups on crash.

--Bill


From ncr-sd!ncrcae!hubcap!gatech!amdcad!rpw3 Thu Mar 31 15:45:36 PST 1988

>In article <23560@hi.unm.edu> kurt@hi.unm.edu (Kurt Zeilenga) writes:
>-What is considered defacto standard way(s) of rewriting "a!b%c"?

The "%" is neither a "!" nor a "@", and thus is (or *should* be) left
alone by any of the transport/routing programs. It *may* be interpreted
by "local" mail delivery systems, and in particular is handled by "sendmail",
and many SMTP mailers (although seldom by non-sendmail UUCP mailers).

The defacto standard way, and the reason for the "%" at all (as opposed
to "@"), is to defer any rewriting unless you are system "a", in which
case you have already stripped the "a!", and are trying to deliver mail
to a local "user" named "b%c". At this point (and *only* at this point),
you notice the "%", and re-write "b%c" as "b@c", and then do whatever
you do locally with "@" addresses (including sending it back out again).

If you are not "a", you send it via UUCP to "a" (if you know how :-).

The purpose of the "%" is to avoid the ambiguity that arises with mixed
"!" and "@".

By the way, "%" is often used in the SMTP world. The address "b%c@a"
means exactly the same as above: If you are system "a", the "b%c" is
a "local-part", which you can (but are not required to) re-write to "b@c".
So, for example, in SMTP-land you can often send a "mail-echo" be sending
to "me%my-system@other-system".


p.s.
Note that the usual example, "a!b@c", *cannot* be parsed corectly unless
you know what kind of transport it came in on. If it came in on SMTP, then
"a!b" is the "local-part", and you should send it to "a" via UUCP. If it
came in on UUCP, then "b@c" is the "user", and you should send it to "c"
with SMTP (or maybe UUCP, depending on your mail system). Such a mixed-mode
horror should *never* be generated locally! If you *have* to send to a "domain"
via a UUCP first hop, then use full-bang domain addressing: a!c.dom.ain!b
Mailers such as "smail" understand this form.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403



From ncr-sd!hp-sdd!hplabs!ucbvax!ucsd!brian Sat Dec 10 13:43:50 PST 1988
Article 2801 of comp.mail.uucp:
Path: crash!ncr-sd!hp-sdd!hplabs!ucbvax!ucsd!brian
>From: brian@ucsd.EDU (Brian Kantor)
Newsgroups: news.admin,news.sysadmin,comp.mail.uucp
Subject: Re: Rewriting From: lines
Message-ID: <1306@ucsd.EDU>
Date: 9 Dec 88 18:38:32 GMT
References: <1227@vsi1.UUCP> <871@acer.stl.stc.co.uk> <944@dlhpedg.co.uk> <1296@ucsd.EDU> <10510@swan.ulowell.edu> <504@pacbell.PacBell.COM>
Reply-To: brian@ucsd.edu (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Lines: 43

In article <504@pacbell.PacBell.COM> david@pacbell.PacBell.COM (David St.Pierre) writes:
>Um Brian, you're taking liberty with what I said. I didn't say I was
>doing the right thing - I did say that traditional System V mailers
>didn't attempt to support RFC822 and didn't really support "headers".

You're right, David, and I apologize for misquoting you - I must have some
missing bits in the wetware.  But as we discussed over a beer two days
ago, the difficulties of combining two networks with essentially
different addressing semantics make any definitive answer difficult to
achieve.  I hope your suggestion to ames helps this situation.  (BTW, 
wasn't it nice of Sun and AT&T to pay for the drinks and munchies while
we discussed this in person?)

The key here is that the From: line in a uucp world is a strange
beastie: it has no meaning to sites which run pure uucp mail.  Yet this
mail network is no longer pure uucp; even if it only used uucp as a
transport mechanism, the thousands of sites using sendmail (even those
not connected to the internet) are using internet semantics and we must, 
as a practical matter, cope with that.

In the pure uucp world, there are no addresses, there are only paths.

In the internet world, there are normally no paths, just addresses.

When you mix these worlds together, you get problems, and to solve the
problem you have to process the address according to the semantics which
apply.

Luckily, it is often possible to decide which is the correct set of
rules, because the addresses/paths contain clues which most of the time
will allow you to guess correctly whether what you are looking at is an
address or a path.  And that's what we do with From: lines, and that's
what I advocate others to do with From: lines.

Those who say that one should never touch the contents of a From: line
would seem to be those who believe that the From: line always contains
an address.  Regrettably, that is not always true, and sometimes 
the From: line contains a path, which must, by definition, be updated.

	Brian Kantor	UCSD Postmaster
		UCSD Office of Academic Computing
		UCSD B-028, La Jolla, CA 92093 USA
		brian@ucsd.edu	BRIAN@UCSD ucsd!brian


From ncr-sd!ncrcae!ece-csc!mcnc!decvax!decwrl!vixie Sat Dec 10 13:50:53 PST 1988
Article 2814 of comp.mail.uucp:
Path: crash!ncr-sd!ncrcae!ece-csc!mcnc!decvax!decwrl!vixie
>From: vixie@decwrl.dec.com (Paul A Vixie)
Newsgroups: news.admin,news.sysadmin,comp.mail.uucp
Subject: Re: Rewriting From: lines
Message-ID: <VIXIE.88Dec9231324@bacchus.pa.dec.com>
Date: 10 Dec 88 07:13:24 GMT
References: <1227@vsi1.UUCP> <871@acer.stl.stc.co.uk> <944@dlhpedg.co.uk> <1296@ucsd.EDU> <10510@swan.ulowell.edu> <504@pacbell.PacBell.COM> <1306@ucsd.EDU>
Sender: vixie@decwrl.dec.com
Organization: DEC Western Research Lab
Lines: 31
In-reply-to: brian@ucsd.EDU's message of 9 Dec 88 18:38:32 GMT

[Kantor]
# Those who say that one should never touch the contents of a From: line
# would seem to be those who believe that the From: line always contains
# an address.  Regrettably, that is not always true, and sometimes 
# the From: line contains a path, which must, by definition, be updated.

I am one who has advocated leaving From: lines alone wherever possible, and
I find that I agree with this exception.  The sendmail.cf running at UB.COM
and FAI.COM will assume that a From: line with only one "host/domain" in it
is an address and should be left alone, whereas something with more than one
"host/domain" is probably not an address, and is probably either hopelessly
screwed up because not everybody has updated it (in which case updating it
won't make it worse) or it has been correctly updated so far (in which case
updating it will still not make it worse).  There are other details involved,
but that's the general approach.  I havn't heard any complaints so far...

The trick is to leave them alone if they don't appear to have been dinked
with already.  If everybody did that, they would never get dinked with at
all.

Except when passing through a network gateway, which breaks this whole
scheme into a million shards.  Hopefully a fully domainized internet will
make most of the things we think of as "gateways" disappear either by
hiding the whole "other network" in a domain tree ("sxn@ingersoll.sun.com"
is on "another network" but I don't have to treat it that way), or by
hiding all recipients on the "other network" behind a generic domain name
(I'm not really "vixie@decwrl.dec.com" but you don't have to know that).
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013


From ncr-sd!ncrcae!hubcap!gatech!ncar!husc6!purdue!decwrl!vixie Sat Dec 10 13:57:39 PST 1988
Article 2815 of comp.mail.uucp:
Path: crash!ncr-sd!ncrcae!hubcap!gatech!ncar!husc6!purdue!decwrl!vixie
>From: vixie@decwrl.dec.com (Paul A Vixie)
Newsgroups: comp.mail.uucp
Subject: Re: "From:" vs. "From_"
Message-ID: <VIXIE.88Dec9235200@bacchus.pa.dec.com>
Date: 10 Dec 88 07:52:00 GMT
References: <VIXIE.88Dec3171712@bacchus.pa.dec.com> <1297@ucsd.EDU> <1299@ucsd.EDU> <2379@ficc.uu.net>
Sender: vixie@decwrl.dec.com
Organization: DEC Western Research Lab
Lines: 81
In-reply-to: peter@ficc.uu.net's message of 6 Dec 88 12:57:54 GMT

Three-in-one special today:

[de Silva]
# Perhaps RFC976 needs a Path: line, which everyone diddles, and a From:
# line, which only gateways diddle.

That is easily the best header enhancement idea I've heard in quite some time.
There are people around who want to update RFC976; I hope one or more of them
sees this.  There should be a way for smart agents to find their own way back
to the sender, and for dumb ones to go back along the original path.  Since
not all MTA/MUA interfaces preserve the envelope sender address and even if
they did it is not guaranteed to be in any particular format, some kind of
"Return-Path:"-like entity inside the headers looks like a good idea.

The RFC976++ crowd ought to plan on something that will address this hetero-
geneous, chaotic, anarchic mess we call a "network" in its real form with all
the unregistered sites, all the non-standard and incompatible syntaxes &etc.
If you start now and finish before 1995, you will still beat the X.400 design
people by five years and you will have something that people will actually
_use_ instead of another design-by-committee, ivory-tower lamp-post that we
can all glance at on our way to whatever we _really_ do every day.

I'm not volunteering, just kibitzing.

[Orrison]
# counter-example: If I receive mail from a bitnet site at my "internet"
# site, I just want "joe@site.bitnet" because I've got a good, close,
# bitnet gateway that probably wasnt used when the mail came to me.  Why
# should whatever gateway it came through on the way to me assume that it
# has to go back the same way?

A good question with a sad but simple answer: .BITNET isn't on the list of
approved top-level Internet domains.  Put another way: you may know a way
to get back to .BITNET, but I don't think there's a *.BITNET "MX" record in
the core name servers and I think Jon Postel likes it that way.  Since you
are on the Internet you have to take the lowest common denominator, which
is that a gateway between a non-internet site and an internet site has to
dink the From: line such that the prototypical "average" internet site will
be able to "reply" to the message with no special intelligence.

The UUCP map has entries for .BITNET and, for that matter, .UUCP.  But those
are just not going to make it into the core name servers, ever.  Both of these
networks are collapsing into internet subsets with oddball transport media --
it is common for BITNET and UUCP sites to have internet names, which means
that in what Dr. Reid likes to call the "fullness of time", you won't have
to see .UUCP or .BITNET and will be able to treat all hosts identically since
they will all have internet domain names.

There is nothing keeping you from peeking ahead in locally-generated or
locally received mail and saying, in effect, "ah, this came from .BITNET
and I'm going to short-circuit the route".  Please don't do this to pass-
through mail, though.

[rja@edison]
# If BITNET and DEC were to convert to the domain-name standard that is 
# now used world-wide, none of that mangling would occur.  

BITNET is changing over to use internet domain names.  They told me that
they were something like 1/3 or 1/2 done and expected 90% conversion by
1990.  Most BITNET sites are IBM and VMS, neither of which are known for
being willing to update their software very often.  1990 is _quick_, in
other words.

DEC, on the other hand, already puts their internal easynet mail into
internet domain name format when it passes through the decwrl.dec.com
gateway.  If you see a From: line like "user@host.DECNET", that was done
by some random DEC customer who didn't know how to set up their sendmail.cf
file to rewrite things that came from the Mail-11 side into something that
the Internet side would find palatable.  Unfortunately, DEC doesn't offer
a great deal of help to customers who want to do this kind of thing.

***As always, I am not speaking as a DEC employee!  I don't set or
** publicize DEC policy in this or any area!  All opinions are my own,
** do not reflect corporate policy!  I don't even _know_ what corpor-
** ate policy is in this area!
***

--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013


From ncr-sd!hp-sdd!hplabs!pyramid!decwrl!vixie Sat Dec 10 13:59:31 PST 1988
Article 2817 of comp.mail.uucp:
Path: crash!ncr-sd!hp-sdd!hplabs!pyramid!decwrl!vixie
>From: vixie@decwrl.dec.com (Paul A Vixie)
Newsgroups: comp.mail.sendmail,comp.mail.uucp
Subject: Re: Pathalias and routing of mail
Message-ID: <VIXIE.88Dec10052803@bacchus.pa.dec.com>
Date: 10 Dec 88 13:28:03 GMT
References: <2189@unmvax.unm.edu> <1665@valhalla.ee.rochester.edu> <4199@mailgw.cc.umich.edu> <2194@unmvax.unm.edu>
Sender: vixie@decwrl.dec.com
Followup-To: comp.mail.uucp
Organization: DEC Western Research Lab
Lines: 28
In-reply-to: mike@turing.unm.edu's message of 10 Dec 88 10:56:58 GMT

[ Followups to comp.mail.uucp ]

[Bushnell]
# This allows us to handle two cases of passive routing: where we are given
# only an address and no path at all, and where the next hop of the path is
# unreacheable.  In the second case, we are justified in rerouting since the
# original path was invalid.

You are certainly justified in finding a route to the first host in the
path (or the only host in an address) is not a direct neighbor.  There is
great controversy over the practice of peeking ahead, beyond the first host
in the path, no matter what kicked your mailer into that mode.

Canonically, this is usually put: "given a!b!c!user, go ahead and get to 'a'
by any means available, but don't assume that your 'c' is the same as the 'c'
known to 'b'".  Details such as 'c' being a fully qualified domain are not
really that interesting, since your route to that fully qualified domain may
not be as good as the one that's being chosen, and you have no way of knowing
that unless you monitor all the links as they go through their daily dance of
the yo-yo.

Forgive me, everyone, if this seems like I'm picking nits.  The word 
"reroute" in the above-quoted text can be taken two ways.  I support one
way, and oppose the other.  The difference seems very important to me.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013