🚀 go-pugleaf

In article <16238@amdcad.AMD.COM>, bandy@amdcad.AMD.COM (Andy Beals) writes:
> Now, to all the hosts (leadsv, for example) that pass mail without adding
> myhost! to the front but don't pass mail via bsmtp, tisk tisk -- do you know
> how much mail you cause to bounce every day?

For this reason I cut hoptoad's link to leadsv a month or so ago.

Every message that came out of there had a return address that did not
work for replying (leadsv.leads.lmsc.com!user, which is not registered,
so the Internet ".com" handler rejects it).  These messages typically
were replied to, either by mailer daemons or by people, and then the
replies would bounce at hoptoad.  As Postmaster, I got tired of seeing
all this needless junk mail and tried to encourage leadsv to fix their
mailer.  After repeated pleading for them to fix it, I broke the link.

All they would have had to do is add "leadsv!" to the front of what they
had, and/or avoid using a domain name until it was registered; this was too
much for them.

I don't think there's a need for UUCP Protocol Police, but if you have
a neighbor that generates screwy addresses, producing lots of bounced
mail, consider applying a bit of peer pressure.  As their links drop away
they might schedule time for mailer maintenance.  Whether or not they do,
your site will never be bothered by their junkmail again!
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu

Yeah, but smail doesn't (can't?) prepend myhost! on the From: line.
What am I supposed to do?  And what is bsmtp?

-- 
Mojo     mojo@micropro.UUCP
... Morris Jones, MicroPro Int'l Corp., Product Development
{lll-crg,ptsfa,dual,well,pyramid}!micropro!mojo
Not the opinion of MicroPro!

The various standards in place around the net (in RFC form) say: no.

In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:
# Now that we have bsmtp, the answer is simple.  If you want to be
# domainist, send mail to all your remote neighbours with bsmtp and
# don't prefix myhost! on to the front of the From: header.

You don't get a lot of choice whether to be a domainist--the world at large
is becoming domainist.  If you don't want to use domains, or routing, etc.,
use the From_ line for your replies -- this is banged up by UUCP, and is
(usually) left along by sendmail.  Leave the From: line alone in all cases,
however!  Here's an example (Sun, are you listening?):

	I am vixie!paul.  vixie talks to ptsfa, who talks to sun and ames.
	Sun tweaks From: lines -- ames doesn't.  Ptsfa doesn't.  When
	sun!foo!bar sends me mail through sun!ptsfa!vixie!paul, the message
	gets here looking like
		From ptsfa!sun!foo!bar
		From: sun!foo!bar
	If ames!foo!bar sends mail to sun!ptsfa!vixie!paul, it looks like:
		From ptsfa!ames!foo!bar
		From: foo!bar

Now, my autorouter will handle either -- but sun may not be the fastest way
to foo, I'd rather find a route directly to foo than directly to sun.  (This
can be fixed by doing aggressive path optimization, but that has problems of
it's own).

The From_ line is correct for literal routers, and the From: line should be
kept pristine for autorouters.  Granted, many literal routers (v6mail, etc)
depend on a full route in the From: line, but it's easier to fix them to
use From_ than it is to add another header for RFC-standard mailers to use.)

# Be sure
# that you know how to route though!  (Otherwise mail won't get though
# when people reply back)

The people who have to know how to autoroute are the people trying to reply!
If you would leave the From: line alone, they wouldn't count on it being
possibly correct (it is, sometimes).  If they saw

	From foo!bar!baz!xyzzy!fump!joebloe
	From: fump!joeblow

... they would know very quickly whether their machine talked to 'fump', and
they would know which From? line to use.  If they saw instead

	From foo!bar!baz!xyzzy!fump!joebloe
	From: foo!baz!fump!jowblow

They could infer (correctly, in this case) that the longer path is correct.
But there are more bizarre possibilities than this, as every e-mail user
knows.  (Sorry, lame example, but I think the point is made).
 
# If you want your mail to work rather than be strictly correct according
# to the rules,

... and to break more mailers in the evolving RFC world, and keep this
incompatible nonsense around another few years ...

#		prefix myhost! on the front of mail to your remote neighbours
# and send it via rmail.

I use smail here.  I wish ATT and UCB would put it into their standard
distributions, and support it.  It's PD, and easily available, but many
sites don't run it just because they would have to support it themselves.
The UUCP project may solve this problem by providing support of their
own, but many small and conservative sites would prefer a single vendor
solution...

#			Mail will go through because it's worked this
# way for years.

Mail *may* go through because of all the people between you and your mailee
who are running broken and non-standard software.  It may also come back as
undeliverable.  It will probably go into some postmaster's mailbox, after
which it will go to the bit bucket.

#		(Not to mention that you should probably convert @hosts into
# leading host.do.main!s just so someone else's mail down the road won't break
# it up in an un-replyto-able way...)

NO NO NO!  Sun does this too -- rewriting addresses is WRONG!  Sun gets
addresses in the form paul@vixie from ptsfa, and rewrites them into
sun!vixie!paul.  Sun doesn't talk to vixie.  Is this the kind of replyability
you want?  Use the From_ line, please (pleading voice)...

# Now, to all the hosts (leadsv, for example) that pass mail without adding
# myhost! to the front but don't pass mail via bsmtp, tisk tisk

I applaude them!  Yay team!  Go go go!  Yip!

They are conforming to the standard -- which applies to you no matter what
transport protocol you use to move mail.  

#							 -- do you know
# how much mail you cause to bounce every day?

Like the little-endian/big-endian battles (I'm LE, btw), either side's
method would work well if the other side would conform.  Unlike LE/BE,
there is a standard (lots of standards, really) for mail addresses --
it says several apparently unpopular things:
	-- don't alter addresses in the headers, only in the envelope
	-- ignore ! when @ is present ("@" > "!" > "%")

I get mail bounced too.  If everyone would conform to the published
standards, it wouldn't happen (so often :-)...

John Gilmore responds to Andy's article:

# [mentions breaking of hoptoad!leadsv connection, explaining that...]

# All they would have had to do is add "leadsv!" to the front of what they
# had, and/or avoid using a domain name until it was registered; this was too
           ****************************************************
# much for them.

I certainly support this.  I use vixie.UUCP and it causes me all kinds of
trouble.  I'm going to change it to just read 'vixie' until i get my domain
named.  Leadsv should do the same.

# I don't think there's a need for UUCP Protocol Police, but if you have
# a neighbor that generates screwy addresses, producing lots of bounced
# mail, consider applying a bit of peer pressure.  As their links drop away
# they might schedule time for mailer maintenance.  Whether or not they do,
# your site will never be bothered by their junkmail again!
# -- 
# Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
# (This is an effort to bend Stargate to work with Usenet, not against it.)
# {sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu

(John, for the record: do you want your copyright notice included in 
followups?  It's makes things messy...)

I agree with this, though I'd implement it differently.  If they cause lots
of bounced mail, forward the mail to them and do not handle it yourself. The
people who sent (and did not receive) the mail will do your job for you in
the form of endless nastygrams.  You can offer to send them a copy of smail.
You CAN be constructive at a small cost to yourself -- think of the help you
give to the net, if not to the offender (or yourself!).

----

Andy, I'm not as nasty as this article indicates.  I stepped up the voltage
a little bit to show that there are hot feelings on BOTH SIDES.  Your 
solution would put the Internet back several years, progress-wise.  UUCP
is (becoming) part of the Internet, to the great benefit of both.  If
everyone gets behind the published standards and pushes, gently but firmly,
the end result will be a single, world-wide, homogeneous network where mail
is fairly reliable and you don't have to memorize the network topography
to get things from A to B.

Please, people: in your comments on this issue, Be Constructive.

-- 
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

In article <364@micropro.UUCP> mojo@micropro.UUCP (Morris Jones) writes:
>Yeah, but smail doesn't (can't?) prepend myhost! on the From: line.
>What am I supposed to do?  And what is bsmtp?

Smail has nothing to do with it.  The sendmail.cf file distributed
with smail (really built by making smail) is what does not prepend
hostnames.  And rightly so, by my way of thinking.  The chnage to make
it prepend hostnames is trivial.  But, no, I'm not going to tell you.

For years now different mailers have used different From lines to
compose return addresses.  Some have done it correctly.  Some have
not.  Some have in a very limited environment (e.g., assuming only
UUCP bang addresses).   What is being discussed (for the umpteenth
time) attempts to set a different standard.  That is to say, every
site that handles a mail message should prepend their hostname! ...
But what if they are not a UUCP site?  What is being suggested
requires that any site that gateways (is that a verb?  I know...
anything can be nowadays) mail out to the UUCP Mail Net must reform
the From: address into bang notation.  This is chauvanistic.
Just tacking on a host name yields addresses like:
     host1!CSNET-RELAY.ARPA!username%siednarb%brandeis.csnet
(A real address from a From: line.)

Fred

In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:

Glossary for the newcomer.  In the following mail:
1	From uucp <date>
2	>From uucp <date> remote from mumble
3	>From bar <date> remote from foo
4	Date: <date>
5	From: bar@foo.com
The "From: line is the 5th line, the "From_" line (the "_" represents
a space) is the conglomeration of lines 1, 2, and 3, in effect becoming
the single line
1	From mumble!foo!bar <date>
(Some mail systems actually do this collapsing, others don't, it doesn't
matter.)

>Now that we have bsmtp, the answer is simple.

"We" may have BSMTP, but the fraction of net sites that support BSMTP
is pretty tiny.  The most widespread implementation has a serious
problem: it blindly throws the BSMTP file at sendmail -bs and hopes it
works - if anything goes wrong, the mail is thrown on the floor.  Because
of this, hardly anybody is using BSMTP today.  I sure won't write code
that assumes that everybody supports it properly.

>If you want your mail to work rather than be strictly correct according
>to the rules, prefix myhost! on the front of mail to your remote neighbours
>and send it via rmail.  Mail will go through because it's worked this
>way for years.

Nonsense.  "For years" what has worked has been the From_ line, which is
a working bang path on the whole net, no matter what software they run.
The only implementations that prepend myhost! on the From: line are 4.2BSD
and 4.3BSD.  System V doesn't.  V7 doesn't.  Xenix doesn't.  4BSD doesn't
if you run smail.  All the standards (822, 976) explicitly say you leave
the From: line in domain format - it is not and was never a bang path.

If your reply command wants a bang path, there's one sitting in the From_
line just waiting to be used.  There is no excuse for violating the
standards by scribbling on a valid domain From: line.

>Now, to all the hosts (leadsv, for example) that pass mail without adding
>myhost! to the front but don't pass mail via bsmtp, tisk tisk -- do you know
>how much mail you cause to bounce every day?  And don't tell me that it
>isn't so.. Being on the postmaster alias for a backbone site tends to show
>one which mail does and doesn't go through.

Any system that depends on *every host* in the path to update a header
line isn't worth its value in spare bits unless every host updates that
header line.  Everybody DOES update the From_ line.  Almost nobody updates
the From: line, and those that do only do so because they installed the
4.2 or 4.3 tape and haven't fixed it.  (An easy fix is to install smail.)

But don't go advocating that the 90% of the world that obeys the standards
suddenly break that conformance in order to try to prop up an undocumented
convention that never worked and duplicates an existing, working, documented
standard.

	Mark

In article <1320@decuac.DEC.COM> avolio@decuac.dec.com (Frederick M. Avolio)
writes:
> Just tacking on a host name yields addresses like:
>      host1!CSNET-RELAY.ARPA!username%siednarb%brandeis.csnet
> (A real address from a From: line.)

Hey, that's at least parsable!  What do you say about examples like:
   enea!seismo.CSS.GOV!!wiscvm.wisc.edu:IMHW400!INDYCMS.BITNET
or
   enea!seismo.CSS.GOV!!OZ.AI.MIT.EDU,!MC.LCS.MIT.EDU:ebg!REAGAN.AI.MIT.EDU
which are real "From_" line instances produced by our backbone.  (They are
very nice and cooperative otherwise, no blame intended for anything except
the above.  Their From: lines are much better, for instance.)

I don't know, but I guess the European UUCP mail climate differs a lot
from the US.  We have the EUnet organization and "official" backbones to
rely on.  The backbones keep complete UUCP and domain maps, which
simplifies things much for the rest of us.

Re: whether to prefix myhost! onto the From: or not..  Well, we
*completely* rewrite *all* addresses to domain format internally and
then turn them back into !-paths for some, but not all, UUCP traffic.
(Do I see a flame coming? :-) It actually works well too, but probably
only because we don't use standard sendmail source or config files...

As for the UUCP world, our strategy has been to divide it into three
different classes:

   1) bsmtp nodes, for which we supply RFC822 conformant addresses only.
      Our node name is prepended to the "MAIL FROM:" line using the RFC822
      source routes syntax.
   2) "smart" UUCP nodes, for which we supply domain style addresses in
      the header lines and domain/!-paths as appropriate for envelope
      addresses.  Our node name is only prepended to the "From_" line.
   3) "dumb" UUCP nodes, for which we only supply !-paths with our UUCP
      node name prepended whereever applicable (both envelope and
      headers).

This means that we rely on our neighbors to forward mail using whatever
appropriate format they use on further communication.

For local mail and mail relayed into the TCP/IP or DECnet worlds,
addresses are produced to be essentially conformant with RFC822.  This
goes for both envelope and header items.  In that way, they never have
to bother with !-paths--they never even see them.

In case anybody would be interested, I plan to package our changes to
the sendmail source together with our locally produced config files and
send them to mod.sources.  I've put down a lot of effort on making the
changes as minimal(?) and clean as possible while still getting the
required functionality.  The stuff is based on the 5.51 version of
sendmail and has been implemented on Sun-3 OS 3.2, Gould with UTX/32 and
a PDP-11/73 with BSD2.9(!)

The source changes include the following features:
   o  A general and direct interface to named dbm databases (selectable
      from your sendmail.cf).  This means you can read your pathalias
      output directly from sendmail.
   o  Batched SMTP support in sendmail.  Both a client end that produces
      SMTP scripts and a server end that mails back errors.
   o  Separate control over envelope and header rewriting rulesets.
      Header addresses are passed through rulesets 1 & 2 while envelope
      addresses are formatted using rulesets 5 & 6.  Mailer specific
      envelope/header rewriting rulesets are selected in the mailer defs.
   o  Support for the `p' mailer flag (M_FROMPATH) in the code that
      produces UUCP "From_" lines, thus making it possible for you to
      add your hostname to the envelope sender only.
   o  A new `V' mailer flag (M_RELATIVIZE), which removes the recipient
      host (+ "!") from paths through the them and adds your hostname to
      the other header addresses.  recipient!user are not touched, however.
   o  Support for default arguments in nametable and dbm file lookups.
      Eg. "$[ foo $: bar $]" will expand to foo's official hostname if
      known or to bar otherwise.
   o  Support for multi-token class matches.  If you have a string like
      "foo.bar.edu" in class X and have "." as a separator char, the old
      sendmail just wouldn't match it.  This one does.
   o  Support for embedded ruleset calls (like "$>4$>10$>6 $1@.$2").
   o  Support for completely separate UUCP and domain names.
   o  More elaborate match mechanism for searching unknown local
      recipients in the full name part of /etc/passwd.
   o  Support for Maryland's mdbm package for systems that don't have ndbm.
   o  Symbolic ruleset test mode output (ie. "$#" for "^X" or whatever
      it normally is).
   and a couple of bug fixes.

The config file fully understands and supports:
   o  Domains--both user@domain and domain!user.
   o  RFC822 Source Routes, ie. <@domain,...:user@domain>
   o  RFC822 Group Names, ie. "Foo: misc_addresses ;"
   o  The Ole ARPAnet %-kludge.
   o  UUCP !-paths.
   and a resonable mixture of the above.

We also use it for maintaining a set of generic local usernames, as in
the case of "lel@ida.liu.se", which is not a user on a specific
machine, but rather an entry in a shared aliases table with a
forwarding pointer to my preferred machine.

Puh, I'll refrain myself from going further into detail.  I think I've
gone far enough already to put at least some of you into instant
boredom.  And other into instant flaming...  Ack, that's life.

The summer is coming.  Enjoy!
--Lennart, writing to you from a slowly thawing country in northern Europe.
--
Dept of Computer and Information Science, University of Linkoping, Sweden
Internet: Lennart.Lovstrand@IDA.LiU.SE       EAN/X.400: lel@ida.liu.sunet
UUCP: {mcvax,munnari,seismo}!enea!liuida!lel    EARN/BITNET: LEL@SELIUI51

In article <600@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>The various standards in place around the net (in RFC form) say: no.

After the Nth last time this was discussed (*sigh*), I tried to verify
this for a paper I was writing.  (I'm sorry: the paper is  s t i l l
being written.)  Various people, including Mark Horton (!), told me
that they couldn't find where this was said, either.  If this has
changed, and someone has found the citation, I'd really appreciate
hearing about it!

My opinion (sorry, but it hasn't been represented yet):

You're both right.  And you're both wrong.

Mail should be sent in such a way that it can be answered.  In the
best of all possible worlds, I actually agree that a domainist con-
struction is better than a pathist.  If all machines have some rule
determining that X@Y.OFFICE.GROUP.ORG is a valid address and means a
specific mail address on a specific machine, and they all know how to
get to it; great!  However, I have seen no sendmail configuration file
that even understands the above correctly; mailx of course doesn't;
and I'm afraid I haven't had the freedom to work with smail much.

[Note that:
Cw Y						# machine name
CD UUCP GROUP.ORG OFFICE.GROUP.ORG		# domains
...
R$+@$=w.$=D	$1@LOCAL	# name@host.domain -> name@LOCAL
does  n o t  (not, not!) match the above!  The address above is split
into  n i n e  different lexemes, seven after the '@'; and the rule
above only has  t h r e e  lexemes after the '@'.]

I've been using these rules of thumb.  If I'm sending between machines
that both know domains and both know each other, I use domains and
nothing else.  Similarly, machines passing mail in pure-domain form
should not alter pure-domain addresses.  (This can be hard to figure
out.  It's only really appliable when one has control over the entire
mail path.)  If I'm sending from a machine not registered in a domain
through a domain machine to a domain machine, I will modify the
address appropriately.  (E.g., hadron!jsdy -> hadron!jsdy@dtix.ARPA;
or joe@dt18.DT.MIL -> joe%dt18.DT.MIL@dtix.ARPA.)  This is surely
allowable; it also happens to be necessary.  If I'm sending between
or to machines that have no idea what domains are like, I will modify
the return addresses, so that mailers which rely on paths will work!
I dislike (detest, hate, loathe, revile) ">From_" lines, so all SysV
machines with which I work run my version of rmail that does things
"right"; that is, collapses "From_" and ">From_" lines as Mark H.
illustrated earlier.  This is especially helpful, as not all mail
agents and mailers (very few, near as I can tell) understand the
">From_" form.  [Well, this is, of course, the reason for my mild
distaste for it.]

One thing I am perplexed by is machines that modify To: and From: but
not Cc: .  This seems mighty odd to me, not to mention totally
confusing to all mail agent programs I've seen used.

Eventually, it should be worth while for (e.g., I can persuade) the
various folk I assist to put up smail and "real" domainism.  Until
then, there are too many machines coming up with UUCP only (or
something).

And i am rather glad that even the prominent domainists who have
said that they never modify From: lines really do when they send
me mail, out of courtesy (i assume); thus, i can send mail back
more easily.

	Joe Yao		jsdy@hadron.COM (not yet domainised)
	hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

In article <524@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
>In article <600@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>>The various standards in place around the net (in RFC form) say: no.
>
>After the Nth last time this was discussed (*sigh*), I tried to verify
>this for a paper I was writing.  Various people, including Mark Horton (!),
>told me that they couldn't find [it] either.  If this has
>changed, and someone has found the citation, I'd really appreciate
>hearing about it!

You can find an RFC that will tell you that @ is the delimiter between the
user and the host part of an address, and that same RFC will (possibly)
mention ! as an optional, nonstandard thing that some sites do.  This is
sufficient, in my mind, to justify an operator precedence of @ over ! --
you don't start looking at the non-standard characters if there is a
standard one remaining, right?

But that's beside your point (sorry, but you didn't remind me what I was
talking about when I said "no" :-)... Okay, net-at-large, where in the RFCs
pertaining to mail does it say thou-shalt-not-modify-from-and-to-lines ?

>And i am rather glad that even the prominent domainists who have
>said that they never modify From: lines really do when they send
>me mail, out of courtesy (i assume); thus, i can send mail back
>more easily.

No, prominent domainists write a From: line in the user@domain form; some
site between you and the sender rewrote into a form your mail user-agent
could deal with.  Your transport agent should be able to do this for you;
depending on non-standard hosts to rewrite headers for you is chancy at
best, and at worst, they will either do the wrong thing, or some standard
host "after" them will do the right thing (i.e., very little) and you will
have a path a!b!d!e where 'c' isn't listed because they were "correct".

Re: smail.  It's cheap (free), well documented (uhhhh...) and easily
installed (really!).  Have your sysadmin mail to me if they are having
some specific problem; I'd rather use up some of my own time and effort
THAT way than to have my mail bounce because your mail transport agent did
the wrong thing when I wasn't looking...  Really, I'm serious: I'll help.
-- 
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

In article <600@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes:
> In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:
> # [just tack on host! and use rmail and] [M]ail will go through
> # because it's worked this way for years.

> Mail *may* go through because of all the people between you and your
> mailee who are running broken and non-standard software.

Is software "broken" because it accepts some things which do not
Conform to the Standard?  (Note: "accepts", not "does".)

However, bandy is close to right.  I'll take working over conforming
any day.  I had to change our sendmail configuration from RFC822 route
addresses (@x,@y:u@z) to RFC7-something (u%z%y@x) because nearly every
*other* piece of software which had to interpret the resulting
addresses broke, taking the commas to indicate a list of addresses.
Often, in spite of enclosing <>s (which, incidentally, I never did
manage to make sendmail generate correctly).

> I get mail bounced too.  If everyone would conform to the published
> standards, it wouldn't happen (so often :-)...

If everyone would conform to *any* set of standards, it wouldn't happen
so often.  The problem is not a lack of standards, or a problem with
the standards; it is a lack of uniformity (ie, a lack of compatibility
with one another).

					der Mouse

In article <3546@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes:
> The only implementations that prepend myhost! on the From: line are
> 4.2BSD and 4.3BSD.  [...] 4BSD doesn't if you run smail.

Smail uses sendmail, right?  How does smail persuade sendmail to put
different things in the From_ and From: lines?  I never managed to make
sendmail change the From_ line without changing the From: line at the
same time.

> All the standards (822, 976) explicitly say you leave the From: line
> in domain format - it is not and was never a bang path.

What if it isn't in domain format originally?  What happens to mail
that was really truly sent to a bang address?

> Almost nobody updates the From: line, and those that do only do so
> because they installed the 4.2 or 4.3 tape and haven't fixed it.  (An
> easy fix is to install smail.)

Where do we get a fix to just this problem, without dragging in all the
rest of smail?

					der Mouse

				(mouse@mcgill-vision.uucp)

In article <3546@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:
>"We" may have BSMTP, but the fraction of net sites that support BSMTP
>is pretty tiny.  The most widespread implementation has a serious
>problem: it blindly throws the BSMTP file at sendmail -bs and hopes it
>works - if anything goes wrong, the mail is thrown on the floor.  Because
>of this, hardly anybody is using BSMTP today.  I sure won't write code
>that assumes that everybody supports it properly.

Well.  In the hopes that everybody would start using BSMTP, I've finished
my BSMTP program to where I'm now letting myself call it "Version 1.0".
I gave Mark a pre-release of this program and it dissappeared into
the smail project somewhere (I forget who it was given to).  Anyway,
I've already sent this to Rich $alz (as of around 27-28 Apr) and he
says his backlog is "3 weeks".  So expect it to start making it's
rounds of the net around the middle of May.  I've cleaned this program
up a LOT since I gave Mark the early copy.

Anyway.  After I'd finished the program I tried to figure out how the
net would go about using it.  I still haven't figured it out very
well but have a few ideas.  Details are in the README in the source
distribution.  Basically I don't know how we'll know which sites out
there can run BSMTP.  Eventually *all* sites will want to do it, but
for now not all will.  For a time we can live with hand-building tables
for routing to BSMTP sites, but eventually we'll want some more
automatic mechanism (like with pathalias now) to do this.

I've set up a mailing list here to discuss bsmtp.  To join the list
send mail to "bsmtp-users-request@ms.uky.csnet".  We also appear
to the world as "cbosgd!ukma!" and "ukma.bitnet".  Of course, the
mailing list is just "bsmtp-users".  And, yes, that's a legit way
to handle our csnet hostname, and until our Computing Center manages
to get our domain name that's what we're stuck with.



-- 
-----   David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet
-----  (also "postmaster", "news", and the Usenet map maintainer for Kentucky.)
-----                 "Doodle, doodle, dee;                Wubba, wubba, wubba"
/*

In article <749@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>Smail uses sendmail, right?  How does smail persuade sendmail to put
>different things in the From_ and From: lines?  I never managed to make
>sendmail change the From_ line without changing the From: line at the
>same time.

It doesn't.  The fix is to change sendmail.cf so that it _doesn't_ do
anything to either the From_ or From: lines.  The message then goes
through smail, which doesn't touch the From: line.  If you are a
uucp-only site, there is an option to smail to skip sendmail
altogether (smail replaces rmail, so it can process incoming message
directly if they aren't going to go somewhere other than uucp).

>What if it isn't in domain format originally?  What happens to mail
>that was really truly sent to a bang address?  

If your machine processes mail from/to a network that adheres to the
rfc822 mail standard, then mail that originates at your host, but is
transported elsewhere on the net should contain a From: line of the
form: 

	From: localpart@domainpart

Where domainpart is your hostname, and localpart is something that can be
interpreted by your mail software.  

So mail coming from uucp, in non-domain format, going to the other net
should have its From: line modified by appending an "@" and your
hostname:

	From: uucp-path-from-host-abc.com@abc.com

If the mail is coming from uucp, and going to uucp (through your
machine), you have the option of using a From: line of the above form,
or prepending your hostname and a "!".  As long as the message stays
within uucp, path-format From: lines are fine.  At sites like this
one, where many networks are involved, we chose put non-domain format
From: lines into domain format (i.e. append @hostname) whenever they
are leaving the machine, which is legal according to everybody's
standards.

>Wheredo we get a fix to just this problem, without dragging in all the
>rest of smail?

You don't.  At least not with sendmail.  Smail isn't that bad, though
(and doesn't take very long to install):

% size /bin/smail
text	data	bss	dec	hex
23552	5120	15844	44516	ade4
%

Jeff

In <749@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes:
> Smail uses sendmail, right?  How does smail persuade sendmail to put
> different things in the From_ and From: lines?  I never managed to make
> sendmail change the From_ line without changing the From: line at the
> same time.

No persuasion is necessary.  Let's think this through...

General Scenario: UUCP thru mail arrives at site snarf.  rmail invokes
sendmail as

	sendmail -ffoo!bar!sender mumble!scream!recipient

The relevant message headers are:

	From foo!bar!sender <ctime-date-string>
	From: sender@sushi.bar.com

It is sendmail's job to convert this combined input into a call to uux:

	/usr/bin/uux - mumble!rmail '(scream!recipient)'

with the relevant headers modifed to be

	From foo!bar!sender <ctime-date-string> remote from snarf
	From: sender@sushi.bar.com

Notice is that NOWHERE is snarf! prepended to an address. (!)  It will be
prepended to the From_ address by the NEXT host's (mumble's) rmail.  Thus
sendmail can leave the addresses in both From_ and From: alone.  All sendmail
has to do is add the "remote from host" part, and indeed there is a mailer
flag that causes sendmail to do just that.

> > All the standards (822, 976) explicitly say you leave the From: line
> > in domain format - it is not and was never a bang path.
> 
> What if it isn't in domain format originally?  What happens to mail
> that was really truly sent to a bang address?

There is no such thing as a bang address.  Bang syntax is a form of ROUTING,
and as such belongs in the message envelope, not in the message headers.
The From_ line is not a header, it is part of the message envelope.

> Where do we get a fix to just this problem, without dragging in all the
> rest of smail?

Again, sendmail will already generate the From_ lines with the "remote from
host" stuff on the end, so what else is there to do?  All you have to do is
make sure your configuration does not alter bang routes and be sure the 'U'
flag is part of the mailer definition that invokes uux (I'm sure it is
already).

So you don't HAVE to have smail to be able to conform to the standard.  But
the program is already written, works, and is GREAT!  Why NOT use it??  Could
it be that you enjoy hand-routing all your UUCP mail?

kyle jones   <kyle@xanth.cs.odu.edu>
old dominion university, norfolk, va

In article <748@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <600@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes:
>>In article <16238@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:
>>>[just tack on host! and use rmail and] [M]ail will go through
>>>because it's worked this way for years.
>
>> Mail *may* go through because of all the people between you and your
>> mailee who are running broken and non-standard software.
>
>Is software "broken" because it accepts some things which do not
>Conform to the Standard?  (Note: "accepts", not "does".)

We are having a communication problem, I think.

If u1@a sends mail to u2@d, and the mailer decides to route the message
as b!c!d!u2 because 'd' is a UUCP site and b!c!d is the shortest path...

First, let's say that a, b, and d all conform to the RFC pseudo-standards, and
do not modify 'From:' addresses, but that 'c' is running some mailer that
prepends hostname! onto the front of the address in the From: lines.  Further
assume that of all these hosts, only 'a' has an autorouter running.  Last,
let's leave operator precedence out of this for a moment, and assume that h!u
were acceptable in place of u@h.  Ok?  So, at each host, the From: address
LEAVES THE MACHINE looking like this:

	host	From:		From_
	----	-----		-----
	'a'	a!u1		a!u1
	'b'	a!u1		b!a!u1
	'c'	c!a!u1		c!b!a!u1
	'd'	c!a!u1		(n/a)

When u2@d tries to REPLY to this message, the mail will bounce back from 'c'
since 'c' doesn't speak to 'a'... "Bad system name: 'a'".

Note that the From_ line is in *fine* shape, usually.  Replying to that will
usually work well, if inefficiently.  Gateways can be a pain, too, but on the
whole: it will work.

If the From: line would just arrive in it's original form, and the replying
machine (either the final destination or some complainer along the path)
can do a path lookup on the From: address and send the mail back.  If it
doesn't run an autorouter, it can use the From_ address.  Since the From:
line will normally arrive bungled and mangled, direct routing will usually
not work, and autorouting to the first (or last) host in the path is very
likely to result in more bungling and mangling.

So, yeah, you can accept non-conforming mail and do constructive things with
it -- without violating the spirit of the standard.  I don't know what the
standards say you are supposed to do with evil addresses -- but I personally
feel that an evil address should be stopped where discovered, and sent home
to momma to get dressed right before being sent out into the world.  Yes,
this would result in more mail being returned undeliverable even than occurs
in the current mixed-mode mailing scheme we have -- but we would see more
mailers standardized in less time under such a policy than under any other
I've heard suggested.
-- 
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

>>> All the standards (822, 976) explicitly say you leave the From:
>>> line in domain format - it is not and was never a bang path.

>> What if it isn't in domain format originally?  What happens to mail
>> that was really truly sent to a bang address?

> There is no such thing as a bang address.

Gee, what's that thing on the command line after "mail"?

% mail snarf\!mumble\!scream\!person

What should appear on the To: line of this letter?

					der Mouse

				(mouse@mcgill-vision.uucp)

> > There is no such thing as a bang address.
> 
> Gee, what's that thing on the command line after "mail"?
> 
> % mail snarf\!mumble\!scream\!person

That thing is a route, not an address.  This route to "person" would work for
you only if your host talks to snarf.  A proper address to this person would
be something like person@scream.technisound.com.  A user can send mail to an
address like that and not have to worry about how the mail will get there.
The routing is left up to the mail transport mechanism, whatever it may be.

> What should appear on the To: line of this letter?

If the UUCP host scream has a domain name (e.g. scream.techisound.com) then
that is what should be on the To: line (person@scream.techisound.com).  If
scream doesn't have a domain name, person@scream.uucp is best, since on smart
UUCP hosts replying to this will allow an appropriate path to be generated.
Not-so-smart UUCP hosts leave this up to the user and force them to put routes
into the mail headers... but there is no longer any need for this!  THere is
FREE software available to do the routing more or less invisibly.

kyle jones   <kyle@xanth.cs.odu.edu>   old dominion university, norfolk, va

In article <788@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) 
quotes somebody who says:
>> There is no such thing as a bang address.

with:
>Gee, what's that thing on the command line after "mail"?
>
>% mail snarf\!mumble\!scream\!person

This is a good time to recapitulate.  I originally posted an article
suggesting that one ought to be able to specify precedence within
a mail address, so [a!b]@c.EDU would be different from a![b@c.EDU] and 
neither would be ambiguous.

Here is a summary of the objections that were raised to my suggestion
and my response.

Objection:  We would have to add another special character to mail
addresses and there is no point in complicating things.

Response:  Actually, we already have three pairs of characters used for
bracketing:  (), [], and <>.  Since () is taken up for comments, that
leaves [] and <>.  Either set could be used.  However, ARPAnet syntax
uses [] to hold a numeric address.  It would be kinder to ARPAnet
software to let it keep the [], although there is not reason why such
software could not be modified to recognize the meaning of [] by
testing its contents to see whether they included anything other than
digits and dots.  But <> is already used to specify precedence,
although only one level of <> is used.  All we need to do is allow the
nesting of <>.

Objection: There is no such thing as a bang address.

Response:  Should we dignify this head-in-sand attitude by responding
to it?  I don't think so.

Objection:  There is no problem with precedence because @ always has
the highest precedence, and anything to the left of that is only
interpreted by the site named after the @.

Response:  This is pure chauvinism.  A user of the ! syntax, whose
mailer does not understand @ syntax, treats all addresses as made up of
components separated by bangs.  Even programs that understand both
types of addresses may arbitrarily choose one over the other.  As far
as I can tell from the documentation, smail gives precedence to the !
over the @ when it sees both in the address field of an incoming
message.  I have encountered messages whose address fields were badly
mangled because some sites gave precedence to @ and others gave
precedence to !.

Think about it, folks.  Ken Iverson designed APL to be very regular
in its operator precedence.  With prefix notation, you ought to be
able to dispense with all bracketing symbols.  So why did he retain
[] and () anyway?
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

In article <1192@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) quotes der Mouse:
>> Gee, what's that thing on the command line after "mail"?
>> 
>> % mail snarf\!mumble\!scream\!person

and claims:

>That thing is a route, not an address.  This route to "person" would work for
>you only if your host talks to snarf.  

It is both.  A route and an address don't have to be mutually exclusive.
If site `scream' is on the UUCP map, then scream!person is an address
that other sites will recognize and generate a route for.  Smart routers
will also successfully generate a route for snarf!mumble!scream!person,
therefore that is an address too.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

Okay, let's do it again.... sigh...

In article <756@bsu-cs.UUCP> dhesi%bsu-cs@iuvax.UUCP (Rahul Dhesi) writes:
>This is a good time to recapitulate.  I originally posted an article
>suggesting that one ought to be able to specify precedence within
>a mail address, so [a!b]@c.EDU would be different from a![b@c.EDU] and 
>neither would be ambiguous.
>
>Here is a summary of the objections that were raised to my suggestion
>and my response.

And here are my objections to your responses.

>Objection:  We would have to add another special character to mail
>addresses and there is no point in complicating things.
>
>Response:  [...] All we need to do is allow the nesting of <>.

For the various non-recursive finite-state parsers out there, nested <>'s
would be a painful thing to support.

What I want to point out, though, is that you are suggesting a change to
the software of every (or nearly every) node on the internet.  At least,
those sites that wanted to reply to sites using your new syntax, would
have to upgrade their software to understand the new syntax.  This is not
in itself a bad thing; at this point I only want to point out the scope
of the change you are suggesting -- I need it below.

>Objection: There is no such thing as a bang address.
>
>Response:  Should we dignify this head-in-sand attitude by responding
>to it?  I don't think so.

This is unprofessional in the extreme.  All you do with this kind of a 
response is to convince the people who have the attitude you are making
fun of, that YOU are a jerk and that your ideas are probably worthless.
Try to be constructive, okay?

Now the fact is that there IS NO SUCH THING as a bang address.  Bangs are
used in routes, not addresses.  At-signs are used in addresses.  There is
such a thing as a 'route-addr', which uses colons and commas, but I really
don't understand much of that (which is too bad, since my sendmail.cf does!)

This is a question of terminology.  A string consisting of "words" seperated
with bangs is CALLED a route.  A string with two "words" with an at-sign in
between them is CALLED an address.

According to the standards adopted by the Internet, "From:" and "To:" lines
contain addresses, and addresses are of the form "lhs@rhs", and "rhs" has
a syntax making it a domain, and "lhs" can be anything at all.  An address
(really: a From: or To: line's contents) that does not contain an at-sign
is considered a "local" address, subject to whatever meaning the local
mailer wants to give it.  Usually, it is scanned for bangs and forwarded
if appropriate -- but this is a defacto-standard, not an approved one.

THIS WORKS.  There is no need for precedence operators in a network where
every site acts according to the standard.  Maybe we need a standard that
will transform the defacto handling of bangs in LHS into an approved thing;
if this is what you want to to, write an RFC -- the net would canonize you.

My point in this part of this article is that there is a standard, and that
if all sites adhered to it, it would work well enough to do what you are
trying to do with your additional precedence operator(s).  Also, I urge you
not to brush off this point, or I (and others, no doubt) will think that YOU
have YOUR head in the sand.

>Objection:  There is no problem with precedence because @ always has
>the highest precedence, and anything to the left of that is only
>interpreted by the site named after the @.
>
>Response:  This is pure chauvinism.

Chauvinism = preference of one thing over another for non-objective reasons.
There ARE good reasons for doing it this way -- because that's the approved
standard, mostly; if you do it this way, you mail will get through, and mail
forwarded through your system will get through.  This is not chauvinism.

>A user of the ! syntax, whose mailer does not understand @ syntax, treats all
>addresses as made up of components separated by bangs.  Even programs that
>understand both types of addresses may arbitrarily choose one over the other.

A user of the ! syntax can get SMAIL for free, and join the internet.  A
program that understands both bangs and at-signs can either do it the way
the standards tell us to do it, or do it some other way.  If the program
adheres to the standard, everybody's mail will get through.

Points:	internet mail handlers can be had for free (SMAIL).
	there IS a standard way to handle addresses with both @ and !.

>As far as I can tell from the documentation, smail gives precedence to the !
>over the @ when it sees both in the address field of an incoming message.

Since SMAIL is advertised as a RFC-compliant mailer, this can't be right.
Can a UUCP-Project member comment on this?

>I have encountered messages whose address fields were badly mangled because
>some sites gave precedence to @ and others gave precedence to !.

So have I.  And I curse and bitch and moan and send mail to the site admins
of the offending systems, and they usually say "oh, sorry, didn't know, let
me install smail".  Really, that's the usual response.  I've been amazed.

>Rahul Dhesi	UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

You're done, so let me get to my conclusion.  Since SMAIL is free, and since
it adheres to the published standards, and since if everyone adhered to the
published standards mail would be much more reliable, and since you are
suggesting that everyone (even currently compliant sites) change their mail
handlers to accept your (unneccessary) additions, it follows that you should
instead advocate a wider acceptance of SMAIL: it does what you want done
(get mail through faster and more reliably); it already exists (so there is
no effort involved in designing and coding what you suggest); it is free
(obvious benefits); and anyone already compliant with the published stand-
ards doesn't have to do anything (fewer people have to upgrade their mailers).

Can we let the precedence-character argument drop, now, and get on with the
business of bringing the gospel of SMAIL to the heathens(*) :-)   ??

(* = stolen from Cal Thixton's outgoing mail headers)
-- 
Paul A Vixie Esq
329 Noe Street       {ptsfa, crash, hoptoad, ucat}!vixie!paul
San Francisco        ptsfa!vixie!paul@ames.ames.arc.nasa.gov
CA  94116            paul@vixie.UUCP     (415) 864-7013

>>As far as I can tell from the documentation, smail gives precedence to the !
>>over the @ when it sees both in the address field of an incoming message.
>
>Since SMAIL is advertised as a RFC-compliant mailer, this can't be right.

Well, the documentation to smail 2.3 says so. "To preserve compatibility with
rmail".  But please enlighten me: why should there ever be a mixed address
in UUCP land?

There is also no need rewrite the envelope unless the destination CANNOT deal
with it, so only gateways should have to do it, right?  And a UUCP to RFC822
gateway can always produce a <> route, and a RFC822 to UUCP gateway can always
produce a ! route, right?

It is much more likely that we can get fixed gateways than asking all sites in
the universe to perpetuate the confusion between a route and an address.  What
Rahul is asking is a new way to write routes, and we already have perfectly
unambiguous ways to do that.

Jean-Francois Lamy                        lamy@ai.toronto.edu
AI Group, Dept Computer Science           {seismo,watmath}!ai.toronto.edu!lamy
University of Toronto, Canada M5S 1A4                          

>>As far as I can tell from the documentation, smail gives precedence to the !
>>over the @ when it sees both in the address field of an incoming message.

> Since SMAIL is advertised as a RFC-compliant mailer, this can't be right.
> Can a UUCP-Project member comment on this?

I'm not a UUCP-Project member, but I have and use SMAIL 2.3 (the latest
version).

SMAIL does give @ first precedence in accordance with RFC 822.  I am certain
of this.  Not long ago I complained bitterly in this forum that SMAIL did not
handle @ and ! precedences correctly, and was promptly corrected by Mark
Horton.  The problem was that I had an old version of SMAIL, which did have
this bug.

So if you are running SMAIL or installing it for the first time, make sure you
have version 2.3.

kyle jones   <kyle@xanth.cs.odu.edu>   old dominion university, norfolk, va

The routing software for UUCP is *not* free. It doesn't cost anything, but
boy does it ever chew up those disk blocks and CPU-seconds. Some people just
don't have the power to spare... and I'm not just talking about private nodes.

In <177@sugar.UUCP> peter@sugar writes:
>The routing software for UUCP is *not* free. It doesn't cost anything, but
>boy does it ever chew up those disk blocks and CPU-seconds. Some people just
>don't have the power to spare... and I'm not just talking about private nodes.

Given this philosophy, I guess you should give up on using UUCP mail all
together. :->

Basically, smail is one program. It adds one more link in the chain of mail
that usually includes /usr/ucb/Mail (or equivalent) and uux (and friend
uucico). The database to support smail can be LARGE or small. It is your
option. smail does one thing that the user agent and uux do not usually
do... they make the mail RFC-822 compliant. This is getting more and more
important as the internet becomes more expansive.

By the way, if you are a private node, then you would have to send
an AWFUL lot of mail to chew up most of the CPU power of on any
reasonable computer (80286, 68000 and up). For "multi-user" nodes,
mail is just like any other function. If it is important, then resources
will be made available. Otherwise, it is not important.

-- 
Stan	     uucp:{killer,rice,hoptoad}!academ!sob     Opinions expressed here
Olan         domain:sob@rice.edu                            are ONLY mine &
Barber       CIS:71565,623   BBS:(713)790-9004               noone else's.

>>Objection:  There is no problem with precedence because @ always has
>>the highest precedence, and anything to the left of that is only
>>interpreted by the site named after the @.
>>
>>Response:  This is pure chauvinism.
>
>There ARE good reasons for doing it this way -- because that's the approved
>standard, mostly; if you do it this way, you mail will get through, and mail
>forwarded through your system will get through.  This is not chauvinism.

I think it's chauvinism.  Your internet standard/software may talk 
'@' addresses, but my software may not, and arbitrary sites between
me and my desired destination may not.

How about an example.  I need to send '@' mail to a site (call it
site3) three uucp hops away which is a gateway to an '@' network:
There is one site in the middle (call it "site2") which doesn't
understand '@' addresses (bear with me a moment!).  The site
immediately next to us (call it site1) interprets '@' addresses.  My
first guess at an address would be:

site1!site2!site3!user@foo.NETWORK

This won't work, because site1 interprets that '@', and tries to send
relay mail to foo.NETWORK, with the username site2!site3!user.  This
fails.  If I send an address like user@foo.NETWORK to site1, and
assuming IT understands that it needs to relay to site2 (a big
assumption, but nevermind), then site2 gets an address like
user@foo.NETWORK, and dies.  What is "smail" supposed to generate, if I
give it an address like user@foo.NETWORK if we are not on that
network?  Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work?
Unlikely, or unreadable, at best.  What if MY site ONLY talks bang.
Will site!site3!user@foo.NETWORK@site2.UUCP work?  I doubt it!

Now, suppose that all of site1, site2, and site3 talk '@' addresses, but
site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway.
HOW do I send mail now?  Does site1 HAVE to understand .NETWORK?  I think
this is unreasonable, especially when I already KNOW how to get mail to
.NETWORK (I relay through site1, site2, and site3!).  Can I say:
user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP?  Does this work?
It this really the approved way to send mail over non fully-connected
networks (i.e. where some path components MUST be specified)?

Maybe I'm just confused...

In article <4106@teddy.UUCP>, jpn@teddy.UUCP (John P. Nelson) writes:
> How about an example.  I need to send '@' mail to a site (call it
> site3) three uucp hops away which is a gateway to an '@' network:
> ... [and sites along the way handle @ differently] ...
> site1!site2!site3!user@foo.NETWORK
> user@foo.NETWORK, and dies.  What is "smail" supposed to generate, if I
> give it an address like user@foo.NETWORK if we are not on that
> network?  Would site3!user@foo.NETWORK@site2.UUCP@site1.UUCP work?
> Unlikely, or unreadable, at best.  What if MY site ONLY talks bang.
> Will site!site3!user@foo.NETWORK@site2.UUCP work?  I doubt it!
> [etc.]

First of all, you can *never* have more than one @-sign per address
if you want to preserve any sanity at all.  [Exception: route-addrs.]

This is what RFC976 and smail take care of!  A "class 3" UUCP site,
including all sites running smail, will accept do.ma.in!user, not just
user@domain.  So in the first scenario above, your mail transport
agent should generate the address
		site1!site2!site3!foo.NETWORK!user

Now with an intelligent user agent, or even a not so intelligent user
agent that just passes the address along to smail, you should just be
able to say
	mail user@foo.NETWORK
and have smail generate the above all-bang address for you.  The
RFC822 mail headers (To: line, etc.) should only have the
user@foo.NETWORK address, and the rmail commands that get passed from
uucico to uucico will only have bangs.

I've been using ".NETWORK" since that's what you used in your
examples, but you should be aware that what you're going to see on the
right side of the @-sign is almost always a domain address, which
might or might not imply any particular network.  Addresses that
explicitly indicate a network (".ARPA", ".UUCP", ".BITNET", etc.) are
using "pseudo-domains", and are becoming increasingly more rare, in
favor of network independent domain names (ending in ".COM", ".EDU",
".UK", or whatever).

You (and anyone else interested) should read RFC976 (and maybe the
"What is a Domain?" paper), included with the smail documentation.

-- 
John Owens		Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU		old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 4529		old uucp: {seismo,harvard,sun,hoptoad}!xanth!john

You should be able to specify a route like

	site1!site2!host.domain!user

as an alternate to

	site1!site2!user@host.domain

Sites that gateway between @ and ! networks should be able to
grok host.domain!user for this very reason (according to the
RFC you love to hate :-) If you look at the paths generated
by smail, they will use the host.domain!next_part convention in
preference to user@... to enable these type of addresses to
be routed through hosts that understand @ as well as ! without
any confusion arising.

In article <4106@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>[...]
>Now, suppose that all of site1, site2, and site3 talk '@' addresses, but
>site1 and site2 only know UUCP domain, and site3 is still the NETWORK gateway.

A gateway is allowed (maybe required, I'm not sure) to rewrite as neccessary
when forwarding messages between networks.  Therefore you could send to
	site1!site2!site3!foo.network!user
and the dest addr will be rewritten to be
	user@foo.network
when site3 forwards it.  What to set the From: line to in that situation, I
don't know.  As I weary of this whole discussion, I begin to wish that the
RFCs would recognize bangs as a low-precedence operator, since the route-addr
form with all the colons and commas looks really really ugly.  But there is
a way to do even that -- routing in the ARPAnet.  Something like
	:site3.network,:site2,:site1,you@home
but don't quote me.  Whatever form it takes, site3 as the gateway could
rewrite from that to the bang-form.  That will make replies to the message
work okay; getting the original message through is the easy part, and that's
all you asked about.

>HOW do I send mail now?  Does site1 HAVE to understand .NETWORK?  I think
>this is unreasonable, especially when I already KNOW how to get mail to
>.NETWORK (I relay through site1, site2, and site3!).  Can I say:
>user@foo.NETWORK@site3.UUCP@site2.UUCP@site1.UUCP?  Does this work?

Nope, only one @ per address.  But there IS a route-form, I promise!  I just
don't remember the syntax.  Help?

>Maybe I'm just confused...

You and me and everybody else, too.
-- 
Paul A Vixie Esq
329 Noe Street       {ptsfa, crash, hoptoad, ucat}!vixie!paul
San Francisco        ptsfa!vixie!paul@ames.ames.arc.nasa.gov
CA  94116            paul@vixie.UUCP     (415) 864-7013

In-reply-to: jpn@teddy.UUCP's message of 15 Jun 87 21:05:43 GMT


jpn@teddy.UUCP writes:

> >>Objection:  There is no problem with precedence because @ always has
> >>the highest precedence, and anything to the left of that is only
> >>interpreted by the site named after the @.
> >>
> >>Response:  This is pure chauvinism.
> >
> >There ARE good reasons for doing it this way -- because that's the approved
> >standard, mostly; if you do it this way your mail will get through and mail
> >forwarded through your system will get through.  This is not chauvinism.
>
> I think it's chauvinism.
> [long examples of hypothetical foul-ups...]
> Maybe I'm just confused...

Yes, you are confused.  The means by which remote gateways are reached
are very straightforward; smail handles it quite neatly.

Consider not a hypothetical example, but a real, working arrangement:
this site.  This is cbstr1.att.com.  We talk nothing but UUCP.  We
don't know anything about other networks aside from the info gleaned
from pathalias and smail.

You can run smail with the -d (debug) flag, in which case it makes
routing decisions but doesn't attempt any delivery (uux is not
called).  I have found the command
	smail -d user@site.domain.spec < /dev/null
to be so useful that I have an alias set up for it.  Consider the
output of this command on some sample properly domainified addresses:

"mbj@spice.cs.cmu.edu," a very real address I type all the time.  Note
that cbosgd is the local gateway (as far as my system's understanding
is concerned) to reach the .edu domain.  I believe it, in turn, hands
it off to seismo.  But I don't know for sure, and I don't care - the
mail gets there.  This is as it should be: users care about addresses,
and back-end, low-level software cares about routes.

resolve: parse address 'mbj@spice.cs.cmu.edu' = 'mbj' @ 'spice.cs.cmu.edu' (DOMAIN)
getpath: looking for '.spice.cs.cmu.edu'
getpath: looking for 'spice.cs.cmu.edu'
getpath: looking for '.cs.cmu.edu'
getpath: looking for 'cs.cmu.edu'
getpath: looking for '.cmu.edu'
getpath: looking for 'cmu.edu'
getpath: looking for '.edu'
route:  'spice.cs.cmu.edu' (edu) = 'cbosgd!%s' (99)
resolve: parse route 'cbosgd!spice.cs.cmu.edu!mbj' =
'spice.cs.cmu.edu!mbj' @ 'cbosgd' (UUCP)
resolve 'mbj@spice.cs.cmu.edu' = 'spice.cs.cmu.edu!mbj' @ 'cbosgd'
(UUCP)
COMMAND: /usr/bin/uux  - cbosgd!rmail '(spice.cs.cmu.edu!mbj)'
From Karl.Kleinpaste  Wed Jun 17 10:41:24 1987 remote from cbstr1
Received: by cbstr1.att.com (smail2.3)
        id AA05995; 17 Jun 87 10:41:24 EDT (Wed)
Date: 17 Jun 87 10:41:24 EDT (Wed)
From: Karl.Kleinpaste@cbstr1.att.com
Message-Id: <8706171041.AA05995@cbstr1.att.com>
To: mbj@spice.cs.cmu.edu

"joe@random.commercial.site.com," a hypothetical, but syntactically
correct address.  Cbosgd is again the route taken.

resolve: parse address 'joe@random.commercial.site.com' = 'joe' @ 'some.random.commercial.site.com' (DOMAIN)
getpath: looking for '.random.commercial.site.com'
getpath: looking for 'random.commercial.site.com'
getpath: looking for '.commercial.site.com'
getpath: looking for 'commercial.site.com'
getpath: looking for '.site.com'
getpath: looking for 'site.com'
getpath: looking for '.com'
route:  'random.commercial.site.com' (com) = 'cbosgd!%s' (99)
resolve: parse route 'cbosgd!random.commercial.site.com!joe' = 'random.commercial.site.com!joe' @ 'cbosgd' (UUCP)
resolve 'joe@random.commercial.site.com' = 'random.commercial.site.com!joe' @ 'cbosgd' (UUCP)
COMMAND: /usr/bin/uux  - cbosgd!rmail '(random.commercial.site.com!joe)'
From Karl.Kleinpaste  Wed Jun 17 10:51:18 1987 remote from cbstr1
Received: by cbstr1.att.com (smail2.3)
        id AA06242; 17 Jun 87 10:51:18 EDT (Wed)
Date: 17 Jun 87 10:51:18 EDT (Wed)
From: Karl.Kleinpaste@cbstr1.att.com
Message-Id: <8706171051.AA06242@cbstr1.att.com>
To: joe@random.commercial.site.com

"romig@ohio-state.edu."  Local pathalias info tells smail that
ohio-state.edu is the same host as osu-eddie.  So that is the route
taken, but the user doesn't even have to know that; "ohio-state.edu"
is quite sufficient.

resolve: parse address 'romig@ohio-state.edu' = 'romig' @
'ohio-state.edu' (DOMAIN)
getpath: looking for '.ohio-state.edu'
route:  'ohio-state.edu' (ohio-state.edu) = 'osu-eddie!%s' (99)
resolve: parse route 'osu-eddie!romig' = 'romig' @ 'osu-eddie' (UUCP)
resolve 'romig@ohio-state.edu' = 'romig' @ 'osu-eddie' (UUCP)
COMMAND: /usr/bin/uux  - osu-eddie!rmail '(romig)'
From Karl.Kleinpaste  Wed Jun 17 11:09:45 1987 remote from cbstr1
Received: by cbstr1.att.com (smail2.3)
        id AA06689; 17 Jun 87 11:09:45 EDT (Wed)
Date: 17 Jun 87 11:09:45 EDT (Wed)
From: Karl.Kleinpaste@cbstr1.att.com
Message-Id: <8706171109.AA06689@cbstr1.att.com>
To: romig@ohio-state.edu

"person@relay.csnet."  My CSNet gateway is Ohio State, an X.25 CSNet
site.  Ohio State acts like a proper domain host these days, so I
could modify our local pathalias data to use it for all .com, .edu,
and .gov addresses if I cared to, but methinks that would be asocial.

resolve: parse address 'person@relay.csnet' = 'person' @ 'relay.csnet' (DOMAIN)
getpath: looking for '.relay.csnet'
getpath: looking for 'relay.csnet'
getpath: looking for '.csnet'
route:  'relay.csnet' (csnet) = 'osu-eddie!%s' (99)
resolve: parse route 'osu-eddie!relay.csnet!person' = 'relay.csnet!person' @ 'osu-eddie' (UUCP)
resolve 'person@relay.csnet' = 'relay.csnet!person' @ 'osu-eddie' (UUCP)
COMMAND: /usr/bin/uux  - osu-eddie!rmail '(relay.csnet!person)'
From Karl.Kleinpaste  Wed Jun 17 10:53:01 1987 remote from cbstr1
Received: by cbstr1.att.com (smail2.3)
        id AA06306; 17 Jun 87 10:53:01 EDT (Wed)
Date: 17 Jun 87 10:53:01 EDT (Wed)
From: Karl.Kleinpaste@cbstr1.att.com
Message-Id: <8706171053.AA06306@cbstr1.att.com>
To: person@relay.csnet

In summary, smail does exactly what it should do.  Other sites in this
dept that don't have UUCP set up to talk to Ohio State can still reach
osu-eddie as a CSNet gateway, by way of cbstr1 or cbrma.  I don't care
about the intervening hops - smail takes an ADDRESS and generates a
ROUTE, just like a pure transport agent should.

Do you realize that, if every UUCP site ran smail, no one would ever
again ask, "How do I get mail from UUCP to BITNET?" in comp.mail.misc?
Gee, I don't know how I get there, let's find out:

"zsyjkaa@wyocdc1.bitnet," an acquaintance at the University of
Wyoming:

resolve: parse address 'zsyjkaa@wyocdc1.bitnet' = 'zsyjkaa' @ 'wyocdc1.bitnet' (DOMAIN)
getpath: looking for '.wyocdc1.bitnet'
getpath: looking for 'wyocdc1.bitnet'
getpath: looking for '.bitnet'
route:  'wyocdc1.bitnet' (bitnet) = 'cbosgd!%s' (99)
resolve: parse route 'cbosgd!wyocdc1.bitnet!zsyjkaa' = 'wyocdc1.bitnet!zsyjkaa' @ 'cbosgd' (UUCP)
resolve 'zsyjkaa@wyocdc1.bitnet' = 'wyocdc1.bitnet!zsyjkaa' @ 'cbosgd' (UUCP)
COMMAND: /usr/bin/uux  - cbosgd!rmail '(wyocdc1.bitnet!zsyjkaa)'
From Karl.Kleinpaste  Wed Jun 17 11:22:17 1987 remote from cbstr1
Received: by cbstr1.att.com (smail2.3)
        id AA06986; 17 Jun 87 11:22:17 EDT (Wed)
Date: 17 Jun 87 11:22:17 EDT (Wed)
From: Karl.Kleinpaste@cbstr1.att.com
Message-Id: <8706171122.AA06986@cbstr1.att.com>
To: zsyjkaa@wyocdc1.bitnet

I've been told that Harvard gets involved in that route, but it's at
some point down the line that I really don't care about.

So get off smail's case, try installing it and running it for a couple
of weeks with valid pathalias information, and see how long it is
before you forget how to type a `!' in a mail destination string.

Karl

	Okay, so I've got a question.  First let me say that I know 
	next to nothing about this stuff, though I do understand the 
	concept of domains etc.  I am relatively naive about mail/uucp 
	networking issues.  Please don't chop my head off...  

	Why wouldn't the following be a "good thing"?:

	Let's assume that for quite some time there will be UNIX boxes 
	around that know nothing about domains.  I don't think that's 
	too farfetched.  Let's assume that I use one regularly.  Don't 
	even assume that.  I do.  Let's also assume that I want to 
	send mail to a friend who logs into a similar box running 
	similarly antiquated (you say) software.  

	It used to be that I could send mail to friend on theirbox via 
	various machines as: 

		mail mach1!mach2!theirbox!friend

	And *sometimes* they could reply as:

		mail mach2!mach1!mybox!pgfox
	
	At other times (or for other friends), the path would not be 
	reversible, and different hops would be used:

		mail mach3!mach4!mybox!pgfox

	This is the anarchy we've all grown to know and love, 
	expressed in an incredibly intuitive (I think) syntax.  

	Now if I ruled the world, and had thought of domains (which I 
	might not have, that's a different problem), I might have 
	tried to preserve the syntax so beloved to all of my subjects, 
	and invented some "meta-machines" for people to send mail 
	through, as in: 

		mail EDU!UNIV!theirbox!friend

	The path is non-reversible, of course.  My friend would type:

		mail COM!ATT!mtune!pgfox

	but that's okay, because we're already used to non-reversible paths.

	The reason I mention this is that it extends naturally to the 
	current situation where neither mybox nor theirbox speaks 
	domains.  If we assume we both talk to machines that do know 
	domains (mine is mtune), then we get: 

		mail mtune!EDU!UNIV!theirneighbor!theirbox!friend

	and of course:

		mail theirneighbor!COM!ATT!mtune!mybox!pgfox

	In reality, of course, mtune, which understands domains, will 
	eat both the EDU and the UNIV "meta-machines", treating them 
	however it does now in "theirneighbor@UNIV.EDU".  

	I thinks this also eliminates precedence problems (of the NO 
	NO NO NO NO variety.  (As well as the problem that my 
	addresses are always being swallowed by my line kill 
	character.  :-) 

	Okay-- I've proved my ignorance-- rip me apart.

	By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM",
	but I *know* I can be reached at "ihnp4!mtung!pgf".

-- 
			Paul Fox, AT&T Information Systems, Middletown NJ.
			  [ihnp4|vax135]!mtung!pgf (201)957-2698

In article <969@mtung.ATT.COM> pgf@mtung.UUCP (gws-Paul Fox) writes:
->	The reason I mention this is that it extends naturally to the 
->	current situation where neither mybox nor theirbox speaks 
->	domains.  If we assume we both talk to machines that do know 
->	domains (mine is mtune), then we get: 
->
->		mail mtune!EDU!UNIV!theirneighbor!theirbox!friend
->
->	and of course:
->
->		mail theirneighbor!COM!ATT!mtune!mybox!pgfox
->
->	In reality, of course, mtune, which understands domains, will 
->	eat both the EDU and the UNIV "meta-machines", treating them 
->	however it does now in "theirneighbor@UNIV.EDU".

There already is such a thing, though it doesn't work quite the way you
describe.  Check out RFC 976, "UUCP Mail Interchange Format Standard".
According to that, your first example would become:

               mail mtune!UNIV.EDU!theirneighbor!theirbox!friend

Since mtune understands domains, it should be able to deal with the UNIV.EDU
part, and your mail gets sent happily along its way.  It's almost, but not
quite, what your idea says.  The big problem with your system is:  what if
EDU or UNIV, or whatever other meta-machines you might recognize, are
coincidentally the *real* names of *real* machines?

->	I thinks this also eliminates precedence problems (of the NO 
->	NO NO NO NO variety.  (As well as the problem that my 
->	addresses are always being swallowed by my line kill 
->	character.  :-) 

Try "stty dec".  Oh, wait, you work for AT&T, right?  Ooops, never mind. :-)

->
->	Okay-- I've proved my ignorance-- rip me apart.
->
->	By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM",
->	but I *know* I can be reached at "ihnp4!mtung!pgf".

From a domain-based machine, it would more likely be "mtune!p.g.fox@ATT.COM".

->-- 
->			Paul Fox, AT&T Information Systems, Middletown NJ.
->			  [ihnp4|vax135]!mtung!pgf (201)957-2698


--Pat.

In article <969@mtung.ATT.COM> pgf@mtung.UUCP (gws-Paul Fox) writes:
|Okay, so I've got a question.  First let me say that I know 
|next to nothing about this stuff, though I do understand the 
|concept of domains etc.  I am relatively naive about mail/uucp 
|networking issues.  Please don't chop my head off...  

Okay :-).

|Why wouldn't the following be a "good thing"?:
...
|It used to be that I could send mail to friend on theirbox via 
|various machines as: 
|	mail mach1!mach2!theirbox!friend
|And *sometimes* they could reply as:
|	mail mach2!mach1!mybox!pgfox
|
|At other times (or for other friends), the path would not be 
|reversible, and different hops would be used:
|	mail mach3!mach4!mybox!pgfox
|
|This is the anarchy we've all grown to know and love, 
|expressed in an incredibly intuitive (I think) syntax.  

I wouldn't call it anarchy - there IS structure to it.  FYI, !-paths are
a form of what's called 'source routing', and also fall generally under the
term (loosely applied here): "route-address".

|Now if I ruled the world, [...]
|	mail EDU!UNIV!theirbox!friend
|The path is non-reversible, of course.  My friend would type:
|	mail COM!ATT!mtune!pgfox
|but that's okay, because we're already used to non-reversible paths.

You and your friend are used to non-reversible paths.  As the general public
begins to use this stuff, they need to be able to just say 'reply' and have
the message get back to the sender.  This is one of the reasons why domains
were "invented".

Your syntax will actually work on some hosts, because of the way the first
steps of address parsing ("canonicalization" or "homogenation") are sometimes
done.  (Please, don't anyone press me for specifics!  I have a sendmail.cf
that I'm experimenting with that would accept this -- quite by accident).

However, the syntax that most domain-uucp hosts would accept is:
	mail theirbox.UNIV.EDU!friend
which means that "domain!user" when there's only one "!" will often be taken
as equivilent to "user@domain".

|If we assume we both talk to machines that do know 
|domains (mine is mtune), then we get: 
|	mail mtune!EDU!UNIV!theirneighbor!theirbox!friend

	mail mtune!theirneighbor.UNIV.EDU!theirbox!friend

|and of course:
|	mail theirneighbor!COM!ATT!mtune!mybox!pgfox

	mail theirneighbor!mtime.ATT.COM!mybox!pgbox

|In reality, of course, mtune, which understands domains, will 
|eat both the EDU and the UNIV "meta-machines", treating them 
|however it does now in "theirneighbor@UNIV.EDU".  

The variants I've shown above will work on most or all UUCP/domain hosts,
already.  I think they are cleaner and more elegant (and more intuitive to
the uninitiated!) than what you suggest.

|Okay-- I've proved my ignorance-- rip me apart.

Hardly.  Or at least, I hope not.

|By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM",
|but I *know* I can be reached at "ihnp4!mtung!pgf".
|-- 
|		Paul Fox, AT&T Information Systems, Middletown NJ.
|		  [ihnp4|vax135]!mtung!pgf (201)957-2698

You can probably be reached at:		p.g.fox@mtune.ATT.COM
					pgfox@mtune.ATT.COM
					mtune.ATT.COM!pgfox
					mtung!pgfox
					pgfox@mtung.UUCP

(I notice that mtunE is different from mtunG, which probably causes some
confusion.  I have both in my maps here...)
-- 
Paul A. Vixie, Esq.		   "A viler evil than to throw a man into a
paul%vixie@uunet.uu.net		    sacrificial furnace, is to demand that he
{uunet,ptsfa,hoptoad}!vixie!paul    leap in, of his own free will, and that he
San Francisco, (415) 647-7023	    build the furnace, besides."  (Ayn Rand)

In article <700@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>In article <969@mtung.ATT.COM> pgf@mtung.UUCP (Paul Fox) writes:
>>By the way, I *think* I can be reached at "p.g.fox@mtune!ATT.COM",
>>but I *know* I can be reached at "ihnp4!mtung!pgf".
>>-- 
>You can probably be reached at:	p.g.fox@mtune.ATT.COM
>					pgfox@mtune.ATT.COM
>					mtune.ATT.COM!pgfox
>					mtung!pgfox
>					pgfox@mtung.UUCP

As postmaster on mtune (and mtung) I don't believe that Paul (F) can be
found on the other end of "p.g.fox@mtune!ATT.COM", and I will not
forbear to point out that most mail sites will be unable to reach him
on ihnp4!mtung!pgf either, since that isn't an RFC822 address.

p.g.fox@mtune.att.com will work, (via forwarding to mtung!pgf) but
anything with "pgfox" in it won't. I didn't process all my 22 machines
user's names into smail2.5's fullnames database, and I was lazy
putting them into the aliases database. Someday I'll put a smart
search into smail (unless I get lucky and someone else does it first).
Until then it's exact string matches only.
-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

An Englishman never enjoys himself except for some noble purpose.

In article <1113@mtune.ATT.COM> jhc@mtune.UUCP (Jonathan Clark) writes:
>In article <700@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>>You can probably be reached at:	p.g.fox@mtune.ATT.COM
>>					pgfox@mtune.ATT.COM
>>					mtune.ATT.COM!pgfox
>>					mtung!pgfox
>>					pgfox@mtung.UUCP
>p.g.fox@mtune.att.com will work, (via forwarding to mtung!pgf) but
>anything with "pgfox" in it won't. I didn't process all my 22 machines
>user's names into smail2.5's fullnames database, and I was lazy
>putting them into the aliases database. Someday I'll put a smart
>search into smail (unless I get lucky and someone else does it first).
>Until then it's exact string matches only.

The version of smail that I developed has the concept of a Information Source,
which is currently used for three different types of information:
	HOSTINFO	contains host and domain names (pathalias)
	NEXTINFO	used to look up "adjacent" host names in UUCP paths
	ALIASFILE	to handle "local" names

One possible type of information source is a program, so that the lines:

HOSTINFO SanDiego.NCR.COM nameserver:SanDiego.NCR.COM!%s
DOTMAILER nameserver	# user names with periods processed here
MAILER	nameserver
	ALIAS		postmaster,matt
	ALIASFILE	"cache.rolo",normal,noneok
	ALIASFILE	"/usr/local/bin/rolo -U 8 -11 -p email -n ",prog,cache=cache.rolo
	ABORT		"User %I is not in the user directory"

cause local names with a dot in them and any local names addressed
to our domain name (a virtual machine) to be processed using the
"nameserver" mailer.  The real useful line is the second ALIASFILE
which defines the information source to be a program which does a
database lookup.  The released version of the rolo program does
substring matching with various fudge factors thrown in.  The new
version does a very general closeness matching that allows lots
of leeway in the name.  In particular the name Bob.Raight will
match Robert.Wrights, but with a very high cost.  If the closest
match is better than the next closest by enough margin then the
name is matched, otherwise the lookup fails and the closest 8
matches are listed instead.

-- 
Matt Costello	<matt.costello@SafLqugo.NCR.COM>
+1 619 485 2926	<matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
		{sdcsvax,cbosgd,pyramid,nosc.ARPA,ihnp4}!ncr-sd!matt