pbirns@violet.berkeley.edu (12/12/86)
From jade!violet.berkeley.edu!pbirns Thu Dec 11 17:23:30 PST 1986 I am running uniplus+ system V and have sendmail, which I know next to nothing about. What does a sendmail.cf file contain? Can I configure sendmail to understand internet etc. And lastly how can I get sendmail to use pathalias data? thanx in advance for any info, matkins
ted@blia.BLI.COM (Ted Marshall) (01/13/87)
In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes: > decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. > They consider themselves to be only tertiarily on UUCP... This is interesting since my 1-December-1986 Usenet backbone map (published in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting ucbvax, hplabs and decvax. I am a Usenet/UUCP novice user (I've been following this discussion because I'm facinated by this free exchange of information across the world enabled by Usenet and UUCP). Now I understood that to send mail to another UUCP site, I needed to generate a path from my site to a backbone site, then through the backbone to a path given by the recipient. For example, if someone says that their address is "...mcnc!xxx!yyy", I will use the following address: mtxinu!ucbvax!decwrl!decvax!mcnc!xxx!yyy |to-backbone-|-across-backbone--|to-recip Gee, what do you know, I just used decwrl as a UUCP forwarder. This says one of three things to me: (1) that's not how you are supposed to do intra-UUCP mail (in which case, please tell me the correct way) or (2) decwrl shouldn't be listed as on the backbone or (3) decwrl is a little closer to UUCP than Mark indicated. Please do not get me wrong. This is not a flame. My major flame is that despite the mod.newuser postings and available documentation (that I've found), conventions on UUCP are still very hard for a novice to learn. (I guess that shows everyone's UNIX background (1/2 :->)). =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me alone. fortune for today: Justice is incidental to law and order. -- J. Edgar Hoover
avolio@decuac.DEC.COM (Frederick M. Avolio) (01/13/87)
In article <1442@blia.BLI.COM>, ted@blia.BLI.COM (Ted Marshall) writes: > In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes: > > decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. > > They consider themselves to be only tertiarily on UUCP... > > This is interesting since my 1-December-1986 Usenet backbone map (published > in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting > ucbvax, hplabs and decvax. You mistake Usenet with UUCP mail, which is what is being discussed. Usenet connectivity does not necessarily mean UUCP connectivity. As the posting you refer to says: A Usenet "backbone" site is one which exchanges every (non-local) news article it receives with at least two other backbone sites; or which is the main newsfeed for a particular area (e.g., Australia) and exchanges news with at least one other backbone site. ... As I stated in another posting, a site has to make some decisions about "preferred" protocols and go with it. It is easier for a site on the Internet to take any domain for which it itself is not an authority and pass it off to the Internet handler for that domain. Fred
reid@decwrl.DEC.COM (Brian Reid) (01/13/87)
decwrl is a USENET backbone site. USENET does not necessarily have anything at all to do with uucp. We also happen to be a major uucp hub in Silicon Valley, and we have several people who put a lot of work into making sure that decwrl works smoothly for uucp. I suspect that the reason Mark thinks that we think we are not a serious uucp site is that we choose not to perform automatic routing. We refuse to process addresses of the form foo@baz.UUCP. This is a conscious decision on our part, based on our observations that the automatic routing database has a lot of garbage in it, and that it will frequently route messages into hyperspace. The quality of the database is improving, and we are considering making the change to our software to turn on automatic routing. Brian Reid DEC Western Research uucp, DEC E-NET, ARPAnet, CSnet
phil@amdcad.UUCP (Phil Ngai) (01/14/87)
In article <7534@decwrl.DEC.COM> reid@decwrl.UUCP (Brian Reid) writes: > >decwrl is a USENET backbone site. USENET does not necessarily have anything >at all to do with uucp. We also happen to be a major uucp hub in Silicon >Valley, and we have several people who put a lot of work into making sure >that decwrl works smoothly for uucp. {Yes, decwrl is a major uucp hub and things in general work very smoothly. I am grateful for the services that decwrl provides. >I suspect that the reason Mark thinks that we think we are not a serious uucp >site is that we choose not to perform automatic routing. We refuse to >process addresses of the form foo@baz.UUCP. This is a conscious decision on >our part, based on our observations that the automatic routing database has a >lot of garbage in it, and that it will frequently route messages into >hyperspace. I would like to make a plea here. I hope I'm not carrying coal to Newcastle; decwrl is very well run and you probably know these things already. But there are people who don't and I think it's an important topic. Please, don't ever reroute uucp routed addresses of the form a!b!c. Please don't even shorten things like a!b!c to b!c where b is a site you know you connect to directly. This takes away the ability to test uucp links. And in my experience, the testability of a network is essential to keeping it running. It also takes away the ability to explicitly route around something known to have problems. It is appropriate to route domain addresses such as phil@neptune.amd.com. In the first place, you have to. In the second place, such addresses are fair game. Let's try to maintain two classes of addresses, ones which are eligible for routing and ones which should be handled strictly as specified by the sender. By the way, Brian, if you don't route foo@baz.UUCP, what do you do with it? Drop it, bounce it, or something else? -- My left foot is digital, my right foot is analog. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
gds@sri-spam.istc.sri.com (The lost Bostonian) (01/20/87)
Mark Horton posted a useful message on why autorouting should be disabled with smail. If you are doing autorouting and you don't fully understand the dynamics of it, you should reread his message, then go read the code that implements rerouting under smail. I haven't looked at smail but I imagine the algorithms used for smail rerouting are pathalias table driven. A proper network routing algorithm requires near real-time connectivity information so that costs can be computed, links declared up/down, etc. with little interference to any given message. Pathalias table data could be months out of date, not to mention just plain incorrect. The uucp network is far too autonomous for autorouting to be done, period. Whether it is ok to optimize (cutting out intermediaries in the uucp-path) is debatable. I am inclined to say it is, because a site may have specific reasons for using a shorter path (it may be cheaper in $$ to connect to a host further down the path). I am opposed to mailers that rewrite the path entirely. Unfortunately I don't have the time or energy to write a mail router, much as I'd like to. I have a strong interest in communications routers (I've worked with some on the Internet) and would like to approach the problem in our heterogeneous environment. --gregbo
woods@hao.UUCP (02/25/87)
I have finally gotten smail(8) installed (2.3), and running the way we want
it to. To do so, I had to make a couple of modifications to the source. Somehow
I feel that there must be a better way to get it to do what I want than this,
but I could not find it. This question is intended for those who have looked
at the source, as it mentions some specific source mods that I have made.
However, the general discussion may be of interest to anyone running or
considering running smail(8) on a machine that speaks both uucp and SMTP, as
it has to do with gatewaying from uucp to and from a quite extensive SMTP-based
network.
A little background: hao is a backbone host on uucp/Usenet, and as such
we pass a lot of traffic that both comes in and goes out over uucp. We also
serve as a uucp gateway to our SMTP network (some of which is connected
via a local Ethernet, some of which are remote sites connected via a TCP
satellite hookup, and some of which are TCP over a "fuzzball" (I don't know
exactly what a fuzzball is, but I know it connects to a high speed ground based
network). All three of these types look like one big Ethernet with subnets.
As far as the mail system is concerned, they are one fully-connected network.
We pass netnews to a number of these sites by running uucp on top of TCP/IP
using uucpd(8) protocols. Before I hear about NNTP, I should point out that
we did it this way because it required zero time for software installation
beyond netnews itself. We have no time for installing new transport systems
and netnews protocols.
So, here are the problems. First, all mail originating from the hao machine
itself going out over uucp had a From line that looked something like
From hao.UUCP!woods [date] remote from hao
This resulted in mail being returned to hao!hao.UUCP!woods. While this is no
big problem, it's a nuisance, so I changed the code in headers.c after the
"case UUCP:" line, which is where it tacks the host name onto the front
of the user name, to omit doing so if the hostname is "hao.UUCP". This seems
kludgy, especially since I will have to change it again when our domain name
officially changes to UCAR.EDU (which should happen sometime after the next
mod.map posting comes out, which should have UCAR.EDU listed). However, the
kludge does work, because now I get "From woods [date] remote from hao", which
is what I want. Has anyone else seen this problem and/or have a better way
around it?
The second problem is that, since smail takes the place of rmail, any mail
coming in for hao!host!user would never get passed to sendmail. This creates
two problems: a minor one, in that mail coming in as a reply to a netnews
article, which might be addressed to "hao!localhost!user", would get stuffed
into the uucp queue, when in fact an SMTP connection to "localhost" exists.
Since we don't connect to them until after hours, mail was unnecessarily
delayed. A more major problem is that if "localhost" doesn't happen to be
one of those netnews hosts, smail/rmail is unable to deliver it, even with
RETRY, since those local hosts are not in our L.sys file. They do appear
in the pathalias database, but they are "@" networks and rmail does not
seem to get the mail there properly. To fix this, I changed main.c so that
if it is called as "rmail", the -L flag (always call local mailer) is always
set (handle=NONE). This works, because sendmail will route messages to
smtphost!user via SMTP, and uucphost!user ends up getting passed back to
smail (called as "smail" this time instead of "rmail", so that it will
end up calling "uux uucphost!rmail" as it should). This is inefficient,
because it requires a call to sendmail for EVERY message that comes in over
uucp, most of which then require a second call to smail and could have been
delivered by a simple uux call. I first tried defining RETRY to be a call to
sendmail (the default is to call "smail -r" to do auto-routing). This worked
when the address was valid, since uucphost!user would call uux directly,
and etherhost!user would call uux, fail, and then call sendmail which would
deliver it. Unfortunately, addresses like "nosuchhost!user" resulted in
an infinite loop, since uux would fail, sendmail is called for RETRY but can't
deliver it, so it calls smail, uux fails, sendmail is called, etc.
The question then is: how can I set up smail so that it doesn't have to call
sendmail for EVERY message that comes in over uucp, but also avoid infinite
loops?
Any hints and/or discussion is welcome.
--Greg
--
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edugreg@ncr-sd.UUCP (03/06/87)
In article <550@hao.UCAR.EDU> woods@hao.UCAR.EDU (Greg Woods) talks about some problems he had in getting smail to work viably at his site. He runs both UUCP and an SMTP-based subnetwork and he had quite a bit of trouble getting traffic to flow smoothly. At one point, he complains: >I feel that there must be a better way to get it to do what I want than this, >but I could not find it. ..... And finally, he concludes: > Any hints and/or discussion is welcome. I guess that this is by way of a discussion; I really don't have any hints on how to deal with the current smail. The basic problem is that you would like to be able to specify a transport mechanism on a per-outbound-link basis. We had a similar problem, so that's exactly what we did. In the pathalias input for those machines which have a non-standard transport mechanism (i.e., not UUCP), we specify a different mailer. We have modified smail extensivly to handle the this concept and invoke the appropriate mailer (the mailers are specified in a configuration file, along with how to construct the command). (Don't ask us for the modifications. They were really quite major, and the diff listing is larger than the source itself. We have given the changes back to Larry Auton; nag him to find out when they will be available. Or rather, \don't/ nag him; but you might politely let him know that you are interested in such modifications and would like to see them incorporated.) The only assumption that our smail makes is that the initial hop listed in the pathalias data base is bang-routed, but this need not be passed to the mailer in that form -- you can easily construct an @-address to be given to the mailer if you wish. For your example, you would like to say that mail for localhost should be given to sendmail for delivery over SMTP. Your local pathalias input would say hao SMTP:(HIGH) SMTP localhost!(LOCAL) which pathalias would turn into localhost SMTP:localhost!%s so that smail would look in its configuration file for a SMTP mailer to use. This method is very flexible and extensible; for example, something that Fred has asked about several times, decwrl ARPA:(HIGH) ARPA .com!(DEDICATED), .edu!(DEDICATED) would yield .com ARPA:%s .edu ARPA:%s which would cause any traffic for ARPAnet sites to use the ARPA mailer. (Note that due to the address resolution rules, this route would only be used if no better match was found, so domains in the UUCP Zone would be matched elsewhere and presumably be routed over his UUCP links.) But one thing, Greg -- you really do want your domain address in your return path. I agree that the format is not ideal (I would rather have the line say "From greg [date] remote from ncr-sd.SanDiego.NCR.COM") but the format will work compatibly with both old non-domain mailers and new domain mailers. In particular, it will work with the current crop of overly-smart ("smart-ass?") mailers that try to re-route all mail that passes through them. One of those mailers might send ...!hao!woods into hyperspace, but should do something more reasonable with ...!hao.ucar.edu!woods (I hope -- I also think such smart-ass mailers should be ruthlessly eradicated). Our modified smail, of course, caters to the maximum flexibility, and allows the the From line to be constructed any way you wish. Sometimes, I think we made it \too/ flexible...... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
ejnihill@sactoh0.UUCP (Eric J. Nihill) (02/11/89)
I would like to thank all of those who pointed out smail
to me and especially to Larry Wells for writing it and
sending me a generic source that has not been hacked up
by "The-Boys-In-The-Back-Room".
For those unfamiliar with smail, it allows you to use
the bill@foobar type of addresses without the need of you
maintaining large data base maps, if you connect to a site
that does.
If anyone needs a copy (3 parts), drop me a line &
I'll E-mail it to you. It has all the patches applied.
Thanks;
Eric
Now if I could only find a clean, up-to-date Rn....
--
To Hell With The Computer, ...pacbell!sactoh0!ejnihill
Where Are The Women!?!?! Flick Livesejnihill@sactoh0.UUCP (Eric J. Nihill) (02/28/89)
System=AT&T 3B2/310
Issue =SVR3.2
Compiler Issue= 4.2
smail=2.5
patchlevel= 00
I am having the following trouble regarding smail/mail.
When a user tries to use 'mail' and delete a letter after reading it,
they get the following message:
lmail: Cannot open savefile
When trying to delete 1 letter without reading the rest of the
mail using the 'mailx' command, you receive the following:
/usr/mail/:saved/username: No such file of directory
If someone has the patches that will cure this, I would appreciate
it if you could pass them on to me.
Thank-you for your time and assistance;
Eric
--
To Hell With The Computer, ...pacbell!sactoh0!ejnihill
Where Are The Women!?!?! Flick Livesguy@auspex.UUCP (Guy Harris) (03/02/89)
>I am having the following trouble regarding smail/mail.
Neither of the problems you mention have anything whatsoever to do with
"smail". Both the S5R3.1 (and, presumably, the S5R3.2) "mail" and
"mailx" seem to expect there to be a directory "/usr/mail/:saved"; make
sure that directory exists and, if it doesn't exist, create it (it
probably should have the same ownership and modes as "/usr/mail", but I
don't know for sure). eric@sactoh0 (Eric J. Nihill) (07/22/89)
It seems that with the release of 4.2 software generation
utilities, a lot of source will no longer compile. Such
is the story for Smail. When attempting to compile Smail,
I get the following results:
cc -O -c
cc -O -c
cc -O -c
cc -O -c deliver.c
./defs.h: 318: Can't find include file sysexits.h
*** Error code 1
Here is the section that it is refering to:
#ifdef BSD
#include <strings.h>
#include <sysexits.h>
#else
#include <string.h>
#include "sysexits.h"
#define index strchr
#define rindex strrchr
#endif
The system that I am trying to load it on is a AT&T 3B2/310 with:
Advanced C Utilities: Issue 4 Version 1
C Programming Language: Issue 4 Version 2
Extended Software Generation Utilities: Issue 4 Version 1
Software Generation Utilities: Issue 4 Version 2
System Header Files: Release 3.2
Is there a patch for Smail that I have missed, or are we opening
up a new can of worms?
Eric
(NOT a "C" programmer)
(pacbell!sactoh0!eric)
--
When in trouble, worry or doubt, sactoh0!eric
run in circles, scream and shout. Flick (Fletch?) Liveslen@netsys.Netsys.COM (Len Rose) (07/31/89)
We have tried compiling smail 2.5 with the same compiler configuration as Eric mentioned w/o any problems whatsoever. Len