bandy@amdcad.AMD.COM (Andy Beals) (04/20/87)
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. Be sure
that you know how to route though! (Otherwise mail won't get though
when people reply back)
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. (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...)
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.
--
Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683gnu@hoptoad.uucp (John Gilmore) (04/20/87)
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
mojo@micropro.UUCP (Morris Jones) (04/21/87)
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!paul@vixie.UUCP (Paul Vixie Esq) (04/21/87)
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-7013avolio@decuac.dec.com (Frederick M. Avolio) (04/21/87)
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
mark@cbosgd.UUCP (04/22/87)
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
joe@auspyr.UUCP (Joe Angelo) (04/23/87)
in article <1320@decuac.DEC.COM>, avolio@decuac.dec.com (Frederick M. Avolio) says: > Xref: auspyr comp.mail.misc:202 comp.mail.uucp:487 > > 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. But, yes, I'm going to tell you... Well, something else instead. *WE* convert user@domain to the UUCP format of domain_or_system!user so that SYSV mailx can reply to it. IF smail is installed on a site, it will figure things out when sending mail to this sort of reply (isn't that what it was made for!?) IF smail isn't installed, then the local mailer will figure it out as well. NO conflict of interest, NO reported problems. S14 R$+<@$=E> $1 user@etherhost -> user R$*<@$+>$* $@$1<@$2>$3 already ok #R$+<@$+.$j>$* $1<@$j>$3 hide anydom.$j under $j #R$+ $@$1<@$j> add our full address (orig) R$+ $@$w!$1 add our full address -- "No matter Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA. where you go, ARPA: aussjo!joe@lll-tis-b.arpa PHONE: [408] 279-5533 there you UUCP: {sdencore,cbosgd,amdahl,ptsfa,dana}!aussjo!joe are ..." UUCP: {styx,imagen,dlb,jmr,sci,altnet}!auspyr!joe
paul@vixie.UUCP (04/23/87)
In article <4271@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: >in article <1320@decuac.DEC.COM>, > avolio@decuac.dec.com (Frederick M. Avolio) says: >> In article <364@micropro.UUCP> mojo@micropro.UUCP (Morris Jones) writes: >>>Yeah, but smail doesn't (can't?) prepend myhost! on the From: line. >> Smail has nothing to do with it. [...] But, no, I'm not going to tell you. >But, yes, I'm going to tell you... Well, something else instead. >*WE* convert user@domain to the UUCP format of domain_or_system!user so that >SYSV mailx can reply to it. If SysV mailx doesn't have the ability to reply using From_ instead of From:, it loses. The From: line is not supposed to be in UUCP form -- bangs have NO official standing there. 'From: foo!bar', taken literally, means that you have received mail from a user on your own machine, who logs in as 'foo!bar'. >NO conflict of interest, NO reported problems. You stated that SMAIL would be able to figure it out. Well, that depends on how you configured it. If you told it to be as agressive as possible, it will start from the right instead of the left side of a path, looking for a host is recognizes -- given a!b!c!d!e, it looks for d, then c, etc. This can sometimes improve the route.... Unless it knows how to talk to a c that is a different machine (in a different state or country) than the one b and d talk to -- in which case, the mail gets screwed. So usually, the agressive behaviour is turned off, and smail starts from the left side. If there is a better way to get to 'd' than the way this letter got here, or -- more likely -- if there is an a1 or b1 that was part of the path the letter took, but did not prepend its host name as the message passed through -- the mail will either take a long time to get there, or it won't get there at all. Moral: Use the From_ line for replies if your mailer doesn't understand u@h.d Moral: don't touch those From: lines -- don't prepend your host name, don't rewrite from u@h to h!u (Sun, are you listening?) -- just leave them alone. >S14 >R$+<@$=E> $1 user@etherhost -> user >R$*<@$+>$* $@$1<@$2>$3 already ok >#R$+<@$+.$j>$* $1<@$j>$3 hide anydom.$j under $j >#R$+ $@$1<@$j> add our full address (orig) #>R$+ $@$w!$1 add our full address (angelo) R$+ $@$1<@$w> add our full address (vixie) Use the (vixie) version in the smail .cf file until you get registered. This will let you have autorouting without sticking .UUCP onto your host name, which breaks many mailers. -- 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
joe@auspyr.UUCP (04/24/87)
> If SysV mailx doesn't have the ability to reply using From_ instead of From:, > it loses... Mailx doesn't lose anything as it sits back and smiles -- you are forgetting that SOMEONE is losing! ... Did you ever use Mailx and try to reply to From: user@domain with a To: and Cc: line??! I've seen core dumps and infinite loops leading to stray pointers. It's really a serious problem. So what now? Install ELM? Buy an AT&T source licence just to fix Mailx? Maybe AT&T can "give away" the Mailx source along with a patch or twenty; and it's a shame cause Mailx has alot of features UCB/Mail doesn't. Actually, I haven't noticed ANY problems by modifying the header line as host!user. But then again, ain't bliss just great? ... As an experiment, I have created a mail-alias command for bounceback@auspyr. It's a useless script that will send the incomming mail message back to the person specified in the From: line. Give it a try and when you get the mail back, try to reply to it and see what happens. So you know, aliases are: bounceback: "| /usr/local/uubin/bounceback" owner-bounceback: joe /usr/local/uubin/bounceback reads: # looks from From: from stdin and reply back to person; reply # contains orginal message tmpfile=/tmp/bnc$$ cat > $tmpfile # get second arg on From: line # From: {host!user || user@domain} [ <Real Name> ] # awk is the easiest way for lazy people name=`grep '^From: ' $tmpfile | awk '{ print $2 }'` ( echo ' Bounce-back, Bounce-back, rolly polly Bounce Backs. Original Text Follows: ' ; sed 's/^/> /' < $tmpfile ) | /usr/ucb/Mail -s 'Mail Bounce Back' $name I know I could of created a mailer-error, but this is a bit more graceful. (Like I said, it's useless) -- "No matter Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA. where you go, ARPA: aussjo!joe@lll-tis-b.arpa PHONE: [408] 279-5533 there you UUCP: {sdencore,cbosgd,amdahl,ptsfa,dana}!aussjo!joe are ..." UUCP: {styx,imagen,dlb,jmr,sci,altnet}!auspyr!joe
paul@vixie.UUCP (Paul Vixie Esq) (04/25/87)
In article <4323@auspyr.UUCP> joe@auspyr.UUCP (Joe Angelo) writes: >> If SysV mailx doesn't have the ability to reply using From_ instead of From:, >> it loses... > >Mailx doesn't lose anything as it sits back and smiles -- you are forgetting >that SOMEONE is losing! ... Sorry, I was using an "in" term. In the hacker's dictionary, a program (or other entity) "loses" or "is losing" if it has *really obvious* deficiencies. > Did you ever use Mailx and try to reply to >From: user@domain with a To: and Cc: line??! I've seen core dumps and >infinite loops leading to stray pointers. It's really a serious problem. I agree. If a company ships a product that dumps core under ANY circumstances, rather than always catching itself and printing error messages, that company should fix that product and ship out bug fixes. Commercialism in action. >[...] Mailx has alot of features UCB/Mail doesn't. Like dumping core on invalid addresses :-) ? Seriously, though, I agree with you. Sun uses Mailx instead of Mail in their product. ATT (or whomever) did a nice job on Mailx... >Actually, I haven't noticed ANY problems by modifying the header line >as host!user. But then again, ain't bliss just great? ... If you want to do that in the sender-rewrite rule for your local mailer, go ahead. If you forward or reply in the user agent, it will leave your system with a h!u or u@h header -- either way, only two components, and accurate (if the other site knows how to parse h!u in the From: line, as seems probable). But don't do this to mail "passing through" your site -- it's rude. > # From: {host!user || user@domain} [ <Real Name> ] Tech note: this won't always work. The From: line has several alternative formats. If there are <>'s in the line, they surround the address and the rest of the line are comments: From: Paul A. Vixie <paul@vixie.UUCP> or From: <paul@vixie.UUCP> Paul A. Vixie If there are no <>'s, then stuff in ()'s is comment and what remains is address: From: paul@vixie.UUCP (Paul A. Vixie) Note that there is no guarantee that the comment part will be there, and if it is it can be anywhere in the line -- i.e., before OR after the real address. The continuing moral (unrelated to above, just want to keep this on track): Don't modify the From: line! If you want the path the message took to get to you, use the From_ line! -- 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
zben@umd5.umd.edu (Ben Cranston) (04/27/87)
In article <606@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: > Tech note: this won't always work. The From: line has several alternative > formats. If there are <>'s in the line, they surround the address and the > rest of the line are comments: > From: Paul A. Vixie <paul@vixie.UUCP> >or From: <paul@vixie.UUCP> Paul A. Vixie The second format is ***NOT*** standard. The 822 standard explicitly states: phrase < [route] address > There is *NO* mirror rule: < [route] address > phrase ; this rule does not exist Is the problem that the documents are not generally available, or more like a general illiteracy in BNF? -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
kre@munnari.oz (Robert Elz) (04/27/87)
In article <606@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: > From: Paul A. Vixie <paul@vixie.UUCP> >or From: <paul@vixie.UUCP> Paul A. Vixie In article <1573@umd5.umd.edu>, zben@umd5.umd.edu (Ben Cranston) writes: > The second format is ***NOT*** standard. The 822 standard explicitly states: > phrase < [route] address > The first isn't standard either, since a phrase can't contain an unquoted '.'. kre
paul@vixie.UUCP (Paul Vixie Esq) (04/28/87)
In article <1573@umd5.umd.edu> zben@umd5.umd.edu.UUCP (Ben Cranston) writes: >In article <606@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >> From: Paul A. Vixie <paul@vixie.UUCP> >>or From: <paul@vixie.UUCP> Paul A. Vixie >The second format is ***NOT*** standard. The 822 standard explicitly states: > phrase < [route] address > >There is *NO* mirror rule: > < [route] address > phrase ; this rule does not exist >Is the problem that the documents are not generally available, or more >like a general illiteracy in BNF? BNF? Eh? I didn't say it was standard -- I said it comes out that way. I've edited a few massive "I'll post a summary to the net" articles in the past, and when looking at 120 responses from all over the planet, I've seen *all kinds* of wierd stuff. This comment on my part was a side note -- a script that reflects mail (which the comment was directed to) needs to concern itself with the mail that WILL arrive, not the mail that OUGHT TO arrive. Pfa. Now someone will say that ALL MAILERS should do that also -- which is the general case, rather than the specific one I was addressing. Be cool. -- 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
jsdy@hadron.UUCP (04/28/87)
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
kre@munnari.oz (Robert Elz) (04/28/87)
And address that is in a legal rfc822 format should obviously not have myhost! added to it anywhere. But those addresses are always "user@host...domain" where domain is one of the legal top level domains, and most certainly "UUCP" isn't one of them. For addresses in "host!host!...!user" form, in the From_ or From: line, you *must* add your own hostname, as that's all that makes the address sensible. That is, uucp hostnames are ambiguous, to disambiguate them its essential to know the name of a host the one in question is connected to, and to disambiguate that you need to know the name of a host that one is connected to (other than the first), and that has to continue all the way to your own host, which is the only uucp name that you can be certain of by itself. I know that lots of hosts don't do this, they're largely ones who have mailers that have simply never heard of rfc822 or From: lines, or ones who have been misguided by those who believe (rightly) that domains are the only way this mess can survive, but who have gotten ahead of themselves and assumed that anything can be made a domain at random. So, if you find a legal domain name, leave it alone. If you don't then the address should be kept in old style uucp format, and the local host name should be added. At least people who route their mail through rational hosts will have it work. Robert Elz
mojo@micropro.UUCP (04/29/87)
In article <1596@munnari.oz> kre@munnari.oz (Robert Elz) writes: >But those addresses are always "user@host...domain" where domain is one >of the legal top level domains, and most certainly "UUCP" isn't one >of them. Does that mean if I find the money and buy a domain listing every year, you all promise to stop modifying my From: lines? :-) -- 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!
page@ulowell.cs.ulowell.edu (Bob Page) (04/29/87)
kre@munnari.oz (Robert Elz) wrote in article <1596@munnari.oz>: >And [sic] address that is in a legal rfc822 format should obviously not >have myhost! added to it anywhere. Clear enough. >For addresses in "host!host!...!user" form, in the From_ or From: line, >you *must* add your own hostname ...to the From_ line. Leave the From: line alone. Yes, this might break some user agent someplace. Then again, adding your own hostname will break somebody else's user agent. UUCP-only, non-domain sites should be using the From_ line, since the From: line isn't meant for them. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
paul@vixie.UUCP (Paul Vixie Esq) (04/30/87)
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
paul@vixie.UUCP (Paul Vixie Esq) (04/30/87)
In article <1596@munnari.oz> kre@munnari.oz (Robert Elz) writes: >But those addresses are always "user@host...domain" where domain is one >of the legal top level domains, and most certainly "UUCP" isn't one >of them. Worse, .UUCP is used inside a lot of sendmail.cf as the "mock domain" for UUCP traffic. .UUX is the newer method, but many .UUCP .cf's still exist. Beware! (Said paul@vixie.UUCP... ugh...) >For addresses in "host!host!...!user" form, in the From_ or From: line, >you *must* add your own hostname, as that's all that makes the >address sensible. Wait, wait. If I get mail with a From: line whose content is "a!b!c", then (according to the RFCs) the mail came from a user ON MY MACHINE who likes to log in as "a!b!c". Assuming that it came from "a" who talks to "b" who in turn has a user who logs in as "c" is charitable, though often also self- serving. I begin to wonder if it wouldn't be better to rewrite into c@b ? No, that won't work -- unless "b" is a known domain name. Anything you do with "a!b!c" is optional, non-standard, and likely to work spasmodically -- if at all. As I said in another article, the path may be "a!b!d!e" and be WRONG because "c" did the right thing. Now, the From_ line, on the other hand, Usually Has The Right Path In It. This is because it's Supposed To Have A Path In It, Not An Address Like The From: Line. If your mail user-agent insists on using From:, either make your transport agent able to understand domains, or change your user agent to make it reply to From_ addresses. If you don't have source, get smail, or write some simple shell scripts, or complain to your vendor, or don't use reply (type the address yourself). >[...] your own host, >which is the only uucp name that you can be certain of by itself. To be fair, I can usually be certain of my immediate UUCP neighbors also. >[...] ones who have been misguided by those who believe (rightly) that >domains are the only way this mess can survive, but who have gotten >ahead of themselves and assumed that anything can be made a domain >at random. Several interpretations here: if "anything" means a forwarding host, then you have a valid complaint. Suddenly assuming that all addresses will be in domain-format is foolish -- like I said, though, the From_ line is there.. If by "anything" you mean some ADDRESS being processed, you still have a valid complaint. Rewriting addresses is evil, even if you are correcting a bang-path to look like a domain. Better to send it back undeliverable... >So, if you find a legal domain name, leave it alone. I agree. >If you don't then the address should be kept in old style uucp format, >and the local host name should be added. I disagree -- send it back, undeliverable. >At least people who route their >mail through rational hosts will have it work. This puts quite a load on the word "rational". I'd say that with the coming onslaught of X.400 (when all the HP and IBM and other computers in the world suddenly join the Internet), we'd better get cracking on making domains work. We don't have 15 years to get thing into shape -- we have about two. Maybe three. -- 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
diamant@hpfclp.HP.COM (John Diamant) (05/01/87)
> / hpfclp:comp.mail.misc / jsdy@hadron.UUCP (Joseph S. D. Yao) / 6:52 am Apr 28, 1987 / > 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! Well, you may be right that this is not stated in exactly that form. However, it can easily be concluded from other statements in RFCs. Both RFC-822 and RFC-976 are quite clear on @ precedence (822 because it doesn't recognize anything else -- 976 because it says so explicitly). Given that the only possible intent of tacking on myhost! to a From: line is to keep the address replyable, and @ precedence in the From: line guarantees that the address won't be replyable, adding myhost! to a From: line that already has a @ is clearly wrong. I believe the BNF in RFC-822 clearly requires one and only one @ in the address, so this makes prepending myhost! always wrong. Put another way, there are three possible situations with From: lines: 1) One exists with a domain address 2) One exists with a UUCP address 3) One doesn't exist yet In case 1, it is clearly wrong to prepend myhost! as stated above. Case 2 is common but violates RFC-822 because there is no @. Case 3 requires that the address be constructed with an @ in the From: line (only the From_ line may have the myhost! in it). So, in no case is it legal (by extrapolation from the RFCs) to prepend myhost! to a From: line. John Diamant SCO UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
mouse@mcgill-vision.UUCP (der Mouse) (05/01/87)
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
mouse@mcgill-vision.UUCP (der Mouse) (05/01/87)
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)
david@ms.uky.csnet (David Herron, Resident E-mail Hack) (05/02/87)
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" /*
jtkung@mit-caf.UUCP (Joseph Kung) (05/04/87)
Hi folks, I'm the of a IBM PC-AT compatible (T3100). I'm looking for the names and numbers of bulletin boards in the Boston area. Any pointers to users groups for the T3100 or just the PC-AT would be appreciated. Please respond to: chien@xx.lcs.mit.edu.arpa -------
schaefer@bgsuvax.UUCP (05/06/87)
Hey! We can all follow RFC822, and for those folks who need route information, we add our host name like this: <@myhost.mydomain:original@address> or <@myhost.mydomain,@host.in.path,@other.host.in.path:original@address> I'm going to change my netnews software tonight, and I'm sure you all will too! What a great world! :-)-- Stephen P. Schaefer Systems Programmer schaefer@research1.bgsu.edu ...!cbatt!osu-eddie!bgsuvax!schaefer
jbs@eddie.MIT.EDU (Jeff Siegal) (05/09/87)
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
kyle@xanth.UUCP (kyle jones) (05/10/87)
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
paul@vixie.UUCP (Paul Vixie Esq) (05/10/87)
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
mouse@mcgill-vision.UUCP (der Mouse) (05/31/87)
>>> 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)
kyle@xanth.UUCP (Kyle Jones) (06/10/87)
> > 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
dhesi@bsu-cs.UUCP (Rahul Dhesi) (06/11/87)
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
peter@sugar.UUCP (Peter DaSilva) (06/13/87)
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.
sob@academ.UUCP (Stan Barber) (06/14/87)
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.