emv@mailrus.cc.umich.edu (Edward Vielmetti) (10/05/88)
In article <2521@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >In article <248@acheron.UUCP> clarke@acheron.UUCP (Ed Clarke) writes: >>. I have a feeling that most map entries for uunet are >>technically WRONG - and should be of the form "uunet.uu.net(DEMAND)" >>rather than "uunet(DEMAND)". >No, they are not wrong. For purposes of UUCP mail, uunet without >qualification means uunet.uu.net; the map entries are right. right. And if you have both an asynchronous uucp connection to uunet and can reach it over the internet, they may be very different. i.e. from umix, mail to uunet!host!user will go via dial-up, but mail to uunet.uu.net!host!user will go over tcp/smtp. --Ed
zeeff@b-tech.UUCP (Jon Zeeff) (10/05/88)
In article <734@mailrus.cc.umich.edu> emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: >uunet and can reach it over the internet, they may be very different. >i.e. from umix, mail to uunet!host!user will go via dial-up, >but mail to uunet.uu.net!host!user will go over tcp/smtp. > This is unfortunate. We have the naming scheme determining the transport mechanism when it should be using the most efficient one. The pathalias data can be used to get uunet.uu.net from uunet. -- Jon Zeeff Branch Technology, umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
emv@mailrus.cc.umich.edu (Edward Vielmetti) (10/06/88)
In article <4788@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >In article <734@mailrus.cc.umich.edu> emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: >>uunet and can reach it over the internet, they may be very different. >>i.e. from umix, mail to uunet!host!user will go via dial-up, >>but mail to uunet.uu.net!host!user will go over tcp/smtp. >This is unfortunate. We have the naming scheme determining the >transport mechanism when it should be using the most efficient one. >The pathalias data can be used to get uunet.uu.net from uunet. no, it's not. When the internet melts down, we can still get to uunet - and for three days last week that was the case. Who is to say what is "most efficient" ? I've had a number of questions about this one, asking why we spend real money to connect to uunet when we could send things for "free" over the internet, which I've answered at least once by mail. The short answer is our dial-up connection to uunet is relatively cheap, extremely reliable, and introduces delays of up to 4 hours, while the internet connection to uunet is "free", moderately reliable, and has delays of anywhere from 45 seconds at best to 3 days bounce at worst. Some time in the next 6 months to 2 years the internet/NSFnet will probably become completely unusable for a relatively long period of time. We'll still be able to get through to uunet. Besides, Jon, if you don't like it, just address your mail differently..... --Ed
zeeff@b-tech.UUCP (Jon Zeeff) (10/06/88)
In article <736@mailrus.cc.umich.edu> emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: >>>i.e. from umix, mail to uunet!host!user will go via dial-up, >>>but mail to uunet.uu.net!host!user will go over tcp/smtp. >>This is unfortunate. We have the naming scheme determining the >>transport mechanism when it should be using the most efficient one. >>The pathalias data can be used to get uunet.uu.net from uunet. > >no, it's not. When the internet melts down, we can still get >to uunet - and for three days last week that was the case. >Who is to say what is "most efficient" ? You should decide which is most efficient, not have it decided for you by the practically random use of uunet.uu.net vs. uunet. Probably something like trying smtp first and then uucp if that fails would be most "efficient" in your case. Of course you need the right software to do this, the lack of which I suspect is the real reason why things are done as they are. -- Jon Zeeff Branch Technology, umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
roberts@edsews.EDS.COM (Ted Roberts) (10/11/88)
In article <734@mailrus.cc.umich.edu>, emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: > right. And if you have both an asynchronous uucp connection to > uunet and can reach it over the internet, they may be very different. > i.e. from umix, mail to uunet!host!user will go via dial-up, > but mail to uunet.uu.net!host!user will go over tcp/smtp. Being a uucp only site, I'm a little unsure as to how the overall tcp/smtp vs dial-up would work. Ed implies here they have both capabilities with respect to uunet and I would assume also with a number of other sites. Is this to give mail capability to specific sites when the internet connection between the sites is down? If so, why not put logic into sendmail (or whatever mailer you use) to check if the connection can be made through the internet first? You would have to know whether each dial-up connection could be reached that way. There would have to be some type of reference file to match single name dial-up entries with fully resolved domain names which could be a pain if you connect to a lot of sites (as mailrus does). If this is not the reason for having both capabilities or is just one of the reasons, what other reasons are there? -- Ted Roberts | My opinions are not necessarily those EDS Technical Services Division | of my employer. Does that mean I'm UUCP: roberts@edsews.EDS.COM | wrong?
david@ms.uky.edu (David Herron -- One of the vertebrae) (10/12/88)
In article <4790@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >You should decide which is most efficient, not have it decided for you >by the practically random use of uunet.uu.net vs. uunet. > >Probably something like trying smtp first and then uucp if that fails >would be most "efficient" in your case. Of course you need the right >software to do this, the lack of which I suspect is the real reason >why things are done as they are. On the surface this sounds nice and wonderful. But I don't know any mail system which can do something like that. In MMDF (since that's what I know) once a channel has been selected for the mail message it's in that channel and there's not much that can be done about it. At least from the level of the software. At the channel selection level there is a choice possible, but currently only by means of 'authorized'. That is, channel selection goes as follows. For each channel in the system, in order, the channel selector looks to see if the host is reachable through the channel, and if it is if the sending-host and/or sending user is authorized to send mail to that host/channel. If it passes that filter then the mail is entered into the channel and delivery attempts begin. I could imagine code being put in to have the channel selector look somewhere in the system to decide if the host is 'unreachable', and have that be an added filtering. But the details of what 'unreachable' means vary so much from network to network, and are usually very difficult to find out, that I don't begin to know how to put that idea into software. -- <-- David Herron; an MMDF guy <david@ms.uky.edu> <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- <-- "Smarter than the average pagan god ... "
emv@a.cc.umich.edu (Ed Vielmetti) (10/13/88)
Look at David Herron's article for context.
The only reasonable way I can think of to deal with switching from
using SMTP to using UUCP in reaching uunet (or uunet.uu.net) is
to change the sendmail.cf file once a day and flush out all of
the undelivered SMTP stuff via UUCP. Once you've committed to
UUCP delivery you're stuck, but if there's stuff queued up for
uunet.uu.net and it's undeliverable, just pop in a new config
file.
I'd save that for dire circumstances, and it's a non-trivial
change.
Oh, but here's another way of dealing with the problem: if there's
a list of 5 MX sites for a host, let's say, then you could have the
MX 0 point to the host, the MX 10 attempt to reach the machine
via SMTP, the MX 20 try to reach the destination via UUCP, and
MX 30 and 40 just attempt delivery. That might be a reasonable
setup if the network looks like this:
===fast internet==== -G- -slow line- -G- ===fast internet===
40 30 20 10 0
\---dial-up uucp------------/
If the network is up, the MX records will attempt direct delivery;
if the network is down, people on the "outside" will deliver to
the MX 20 host which will bypass the routing outage.
This won't handle the 'uunet' problem, though it's possible
at least in theory to do. I'd imagine it's more likely to
be used for corporate setups where there's a slow slip line
in and a friendly host on the other side.
--Ed
(isn't routing fun? it's easy if you can run just pathalias,
or just use MX records, but on the edges it gets trickier.)