les@chinet.chi.il.us (Leslie Mikesell) (08/17/90)
There was some discussion of mail server programs for unix machines a while ago but not I can't find the information. I'm interested in something that would provide a simple way to retreive files by sending mail messages to a server program. What are the choices and where can I find them? Thanks in advance. Les Mikesell les@chinet.chi.il.us
venta@i2ack.sublink.org (Paolo Ventafridda) (08/20/90)
In article <1990Aug17.021921.1863@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > There was some discussion of mail server programs for unix machines > a while ago but not I can't find the information. I'm interested > in something that would provide a simple way to retreive files > by sending mail messages to a server program. What are the choices > and where can I find them? > Thanks in advance. > Les Mikesell > les@chinet.chi.il.us [ In this article you will find a description of RNA 2.0, which i think is what you are looking for.. ] I'm the author of a very simple mail server called RNA, posted in sources.misc last year (august 89). Since september 1989 i've been working on the second version of rnalib; sadly, the source grew up since beta testers were asking for improvements, and had now much time to spend on the program. I take the chance to say 'sorry!' to these people, who offered their time to test the program and never received the damn stuff: From: len@netsys.NETSYS.COM (Len Rose) From: Frank G. Fiamingo <ddsw1!riacs!rutgers!hpuxa.ircc.ohio-state.edu!frank> From: ddsw1!riacs!rutgers!quark.wv.tek.com!jeff (Jeff Beadles) From: ddsw1!uunet!aunro.AthabascaU.CA!myrias!cs!lyndon (Lyndon Nerenberg) From: relay.EU.net!mje%olsa99 (Mark J Elkins) From: ddsw1!uunet!ficc!morrison From: Gopal Sridhara <ddsw1!ames!ncar.UCAR.EDU!boulder!uswat!srid> From: tom reingold <ddsw1!bellcore!ctt.bellcore.com!tr> From: Willy Paine <rutgers!fungus.enet.dec.com!paine> .. plus many others. Testers were accepted only within italy, were i live, so i could have a phone contact without spending $$$. RNA 2.0 is "almost-ready" since april 90. I'd wished to release it since june, but i married and my wife doesn't love rna. Hehehe ;-) RNA (also called 'rnalib') is a bourne shell script program, about 60K bytes long, which is able to process commands sent via ordinary e-mail, and send back responses. RNA was made for file-servers onto Sublink Network, which is an independent uucp network in italy (actually under domain .sublink.org). It was written in shell since the first version (which was 9K long) was in shell; i went on using this impossible language, doing the longest shell script i'll hopefully write in my life (never more! never more!) Rnalib is pretty clever, and *portable* (!). Comes configured for: - Xenix 386 - SCO Unix - AT&T 3b2 unix - HP unix (bsd etc.etc) - Interactive unix Should run at the first try on any other existing unix; will not (NOT) run on any 286 xenix systems,due to the limited stack size of shell. I have a copy of 'netlib' from at&t; well, maybe you'll like best rna. Mainly because it's configurable in less than 10 minutes, has all of the features of netlib PLUS many many others.. Futhermore, no need to compile the stupid shell! RNA 2.0 - Quick Overview Capability of: - getting the original path where mail was generated from. - understanding headers, following rfc-822 standard. - security checks - multiple requests per message - handling 'libraries' (indexed directories) - dealing with binary files, using 'uuencode' or 'btoa' when needed. - sending through e-mail, uucp, uusend - dealing with file compression, when needed. - dealing with privileged users' request, asking for 'external' destinations (addresses other than theirs). - handling 'blacklist': unauthorized paths/users/hosts/gateways which cannot forward queries to rna. - accounting at different levels (pathsizing). Credits might be fixed as default number of bytes which a path/user/gateway may ask before being denied. - automatically register new paths/users/gateways, giving a default credit limit. - asking new paths/users/gateways to register before using rna. - going on 'hold'. That is, a controlled out-of-order state, which notifies users that the service is on hold for some time. When service is resumed, all queries are processed. - understanding errors, suggesting a possible solution to the remote user. A friendly approach to unexperienced people. - detecting remote-rejected mail, and discarding the stuff. Here are some rna 2.0 queries: @@ index games @@ send tetris.Z from games @@ send tetris.Z from games via uucp @@ send tetris.doc from games with compress-uucp @@ send tetris.Z from games with btoa via email @@ help to myfriend@host.domain @@ credits @@ please send file.doc using uusend with compress @@ find tetris Easy to install! RNA is a Bourne Shell script: you don't need to compile sources. Easy to learn! RNA configuration comes with 'docs', step-by-step. You learn of RNA while you configure. Easy to maintain! RNA need no help to survive: it will send you a mail as soon as problems appear. It will try to solve them by itself before notifying you about the matter. SHIPPING: Actually, RNA is ready. The docs are not. This is the point. I've planned to send rnalib 2.0 to comp.sources.misc at the beginning of september, and i promised to myself to do it. The at&t 'netlib' program is probably a nice solution to file-servers using email, but i found the docs and the whole installation very difficult.. Beside, i wrote rna keeping in mind netlib's limitations. Maybe there's a new version of netlib around, i dunno. Since both the programs are 'free', one could try netlib as well! Please don't ask for 'beta' versions of rnalib since i already have a *long list to satisfy! In few weeks i'll ship everything around and i'll post a message here . Greets, Paolo -- Paolo Ventafridda - Milano, ITALY | INTERNET: venta@i2ack.SUBLINK.ORG
palowoda@fiver (Bob Palowoda) (08/20/90)
From article <1990Aug17.021921.1863@chinet.chi.il.us>, by les@chinet.chi.il.us (Leslie Mikesell): > There was some discussion of mail server programs for unix machines > a while ago but not I can't find the information. I'm interested > in something that would provide a simple way to retreive files > by sending mail messages to a server program. What are the choices > and where can I find them? I am also interested what is available in this area. Specificly mail servers for 386 UNIX's that work with sendmail/smail. Actually I have one already, a modified version of Micheal DeCorte ftp version to work with smail 3.1 or sendmail. It makes use of the file areas of an XBBS bulletin board I run. It is capable of detecting if the file is binary or text and uuencode if it's binary. It is written in shell script with one small C file. You can get a copy by send mail to: archive-server@fiver Subject: hi there send unix_bbs bpms1.tar.Z ------ Or you can get a copy by downloading directly from the bbs. Data lines should be in the .sig. ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
penneyj@servio.UUCP (D. Jason Penney) (08/20/90)
From article <1990Aug17.021921.1863@chinet.chi.il.us>, by les@chinet.chi.il.us (Leslie Mikesell): > There was some discussion of mail server programs for unix machines > a while ago but not I can't find the information. I'm interested > in something that would provide a simple way to retreive files > by sending mail messages to a server program. What are the choices > and where can I find them? Hi, this went out last Spring, so it's probably time to post again. My SPARCstation-1 has a mail server which is a variant of KISS. It doesn't require root privilege to build or install. The mail server provides copies of perl, rcs, Reactive Keyboard, and other goodies, as well as the necessary software for the mail server, of course. The most popular offering seems to be the public domain software for touch typing. Below is the help file for my mail server. ---- HELP FOR jason-archive, as of 27 Apr 1990 This is a variant of the "kiss" archive server. Requests to this server should be addressed to penneyj@slc.com, and include the phrase, "jason-archive-request" in the subject. To contact a human, make sure that "jason-archive-request" is NOT in your Subject: line. The Subject: line is otherwise ignored. The remainder of the mail message should consist of "kiss" commands, one per line. Lines that do not form a valid command are ignored. You may request multiple files in a single mail message. There is no advantage in splitting the requests into multiple mail messages. The server recognizes six commands. They are: path <path> This lets the requestor override the address that is normally be extracted from the header. If you do not hear from the archiver server within oh, about 2 days, you should consider adding a "path" command to your request. The path describes how to mail a message from slc.com to your address. Overriding the path can also reduce uunet charges (see below). slc.com is directly connected to ogicse and uunet. I strongly prefer that your replies be routed through ogicse. Domain-based addresses are preferred, such as: path luser@baz.foo.bar.edu (These will be automatically routed through ogicse.) An example without domain routing: path ogicse!foo!oof!bar!rab!luser help This message. It equivalent to the command "send help". index This is equivalent to the command "send index". send <whatever> The whatever is mailed to you. Examine the index to see what is currently available. Wildcards are NOT supported -- if you want multiple files, you should ask for them separately, one per line. Filenames are relative to a kiss "data" directory. All files except "index" and "help" are in subdirectories, so you will need to prepend a directory path, Unix style. Filenames are case-sensitive. compress ALL of the files requested in the current mail message will be "compressed" and "xxencoded". "xxencode" is NOT compatible with uuencode, so you will need to acquire misc/Xxencode01 BEFORE using this. xxencode is preferred over uuencode because the latter is useless on some BITNET sites using non-ASCII character sets. This is related to translation problems in some Internet/Bitnet gateways. If your system does not have compress, a public domain version is available in misc/. This is the most economical way to move files, but again, you will need to upload misc/Xxencode01 in a separate message, and possibly misc/NCompress01 and misc/NCompress02 as well. quit Nothing past this point is interpreted. This is provided so that the occasional lost soul whose signature contains a line that looks like a command can still use the server without getting a bogus response. ---- -- D. Jason Penney Ph: (503) 629-8383 Beaverton, OR 97006 uucp: ...uunet!servio!penneyj (penneyj@slc.com) "Talking about music is like dancing about architecture." -- Steve Martin
tneff@bfmny0.BFM.COM (Tom Neff) (08/22/90)
In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >A mail-based archive server is an impolite and destructive way to >distribute large amounts of information, and should be discouraged in >such applications. Almost -- a MBAS is *potentially* destructive if it imposes no bandwidth restrictions, satisfies requests exclusively by mailing files back to the requestor, and makes no allowance for the loading constraints on the delivery path. This gloomy potential need not be realized. * Responsible archive servers will establish and enforce limits on how much bandwidth an individual user can have; how much a given reply path can tolerate; and how much overall activity per day can be supported. * In the most general sense of the term, a mail based archive server is any server that accepts requests via mail. The actions taken to satisfy those requests need not be limited to mailing file contents back along the reply path. - A server might, for instance, satisfy a mailed file request by placing the requested file on the nearest Internet site, and mailing a short notification of FTP availability back to the requesting user. - It might respond to a mailed request by placing the file in an anonymous UUCP download directory, and mailing back L.sys and filename information to the user. - It might log the request, collate it with others for the same file, and eventually perform one single contents mailing to a regional site, followed by a mass mailing to the requesting users in that region notifying them of local availability. * Where mailing the file is unavoidable, the server might identify the message content as such for the management convenience of intervening sites. Exiting headers like Precedence: and Content-Type: could be used. Since the MBAS genie is not going to go quietly back into its bottle, it would be more constructive to suggest responsible strategies for running them -- and provide software to implement those strategies -- than to inveigh against the entire phenomenon. -- The real problem with SDI is %/ Tom Neff that it doesn't kill anybody. /% tneff@bfmny0.BFM.COM
bob@MorningStar.Com (Bob Sutterfield) (08/22/90)
A mail-based archive server is an impolite and destructive way to distribute large amounts of information, and should be discouraged in such applications. When a mail-based archive server (MBAS) sends a requested chunk of stuff (CoS) to the requestor, it has no way to know what transport mechanisms will be used along the route. If the transport mechanisms are all on zero-incremental-cost-per-use networks, all is well. Very often, at least some of the trip will be along edges in a graph of an intermittent-connection, store-and-forward network, usually involving a nonzero incremental cost for transporting each CoS. Most such edges are maintained, and paid for, by the nodes on either end. They voluntarily allow other traffic to pass over their link, usually with the understanding that the volume will be small enough to be of negligible cost. However, if someone starts shipping megabytes of archives across those links, the distribution cost is borne by someone other than the requestor. This is impolite. Eventually, such hospitality abuse can cause the eventual removal of that connection from general "public service", and the two nodes will return to maintaining a private edge for their own use. Traffic will then shift to other edges, increasing their burden and encouraging them to retreat similarly. In the extreme case, the practice of general use and hospitable availability of connections will disappear. Everyone would need to maintain distinct links with every other site with which they wish to exchange traffic. Free, open, cooperative communication as we know it would wither, a nostalgic remnant of a bygone era. But take heart, there's another way! Instead, sites can pay for the connectivity they use for shipping large CoSs. If they're connected to a zero-incremental-cost-per-use network then they pay for the connectivity every month in their leased line bills. This is the case on the IP Internet, the BITnet, SPAN, and others. If a site is not so connected, then they can pay for the transient connectivity when they need it. For example, the Computer Science department at the Ohio State University has for several years maintained just such an archive. Similarly, UUNET Communications Services offers dialup UUCP file transfer service even to sites without pre-established UUNET accounts, through their "900 number" facilities. The connectivity appears in the requestor's next telephone bill because, unlike OSU CIS, UUNET must recover the costs of providing the service. Such archives' contents are freely available to anyone who wants them and is willing to pay the cost to acquire them. No provision is made to assist requestors in freeloading on other sites' generous hospitality, other than in exchanging relatively small mail messages containing instructions and assistance in using the archive. Any number of schemes are possible, usually based around a reliable file transfer protocol. Pay-per-use archives run today using Kermit, UUCP and Fido request protocols, and probably innumerable others. Note that in saying "pay-per-use" I mean paying for connectivity (usually the phone company), not paying for the privilege of access nor for the archive contents themselves. The work involved in maintaining such access to an archive is negligible, compared to the work of maintaining the archive itself. In fact, compared to the work of untangling bounced mail replies from a MBAS, it should be quite attractive to the archivist. Once set up, the access mechanism pretty much runs itself. But MBASs are so popular, and so useful to so many people, I often feel like a voice crying out in the wilderness. Please, at least provide and encourage other, more polite distribution means. I wouldn't want such a good thing as people's desire to share to be a contributing cause to the dismantling of open networks!
les@chinet.chi.il.us (Leslie Mikesell) (08/24/90)
In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >A mail-based archive server is an impolite and destructive way to >distribute large amounts of information, and should be discouraged in >such applications. Your point about mail service possibly involving other people's money is well taken, but if this message is in response to my request for information about mail servers, it doen't really apply. What I want to do is to set up something resembling a library service within our organization to help avoid duplication of effort by various branches. The transport is already established and would be unlikely to send anything beyond our own offices. It seems like this is something that every group with an established electronic mail service would need, so I'm kind of surprised that the current crop of programs seem pretty much oriented towards distributing program sources. >Any number of schemes are possible, usually based around a reliable >file transfer protocol. Pay-per-use archives run today using Kermit, >UUCP and Fido request protocols, and probably innumerable others. >Note that in saying "pay-per-use" I mean paying for connectivity >(usually the phone company), not paying for the privilege of access >nor for the archive contents themselves. How would you like to train a few hundred people to adapt to "any number of schemes"? These are people who aren't particularly interested in knowing anything about computers, but they already know how to use a mail program for other reasons. >But MBASs are so popular, and so useful to so many people, I often >feel like a voice crying out in the wilderness. Please, at least >provide and encourage other, more polite distribution means. I >wouldn't want such a good thing as people's desire to share to be a >contributing cause to the dismantling of open networks! On the other hand, why should an end user need to know anything about more than one transport interface? Virtually every other question of human time vs. computer resources these days is answered with "computer resources are cheap". If mail transport of bulky items is a problem, then perhaps we should fix the problem rather than avoiding it. Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (08/24/90)
In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: > A mail-based archive server is an impolite and destructive way to > distribute large amounts of information, and should be discouraged in > such applications. [goes on to point out that UUCP sites can be victimised that way] So how should a UUNET customer, who's paying for the non-zero-incremental- cost (NZIC) part of the link get data from FTP-able archives? The only way I know is to use a (*shudder*) mail-based archive server (MBIC). Ruling them out is throwing the baby out with the bathwater. Just make sure your mail-based server can recognise a NZIC link (easy, it's got a "!" in it) and refuses to send if it's not terminal. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
bob@MorningStar.Com (Bob Sutterfield) (08/25/90)
In article <15781@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: A mail-based archive server is an impolite and destructive way to distribute large amounts of information, and should be discouraged in such applications. ...a MBAS is *potentially* destructive ... This gloomy potential need not be realized. Let's hope not! A lot of people find them very useful. Responsible archive servers will establish and enforce limits ... how much a given reply path can tolerate... How might the responsible archivist establish those limits? How is the archivist to know how much additional traffic a remote nonzero-incremental-cost mail connection might tolerate? Them's heavy heuristics, son, and requires a lot of communication between the archivist and all the administrators of all the nodes along the path. Perhaps a new Pathalias field, along with link cost, describing how benevolent the site can be to strangers? foobar(NIGHTLY,REAL_NICE) However, if each node must give explicit permission for the use of their piece of the path, I suspect that they won't. If the "public service" traffic isn't explicitly authorized, it passes by the beancounters without such a ripple. * In the most general sense of the term, a mail based archive server is any server that accepts requests via mail. The actions taken to satisfy those requests need not be limited to mailing file contents back along the reply path. Good point, I've played with shell scripts that invoked whois, finger, etc. in response to uux or mail requests. But my use of "mail based" meant that the response's transport mechanism is usually mail. - [A MBAS] might respond to a mailed request by placing the file in an anonymous UUCP download directory, and mailing back L.sys and filename information to the user. This is the best suggestion yet: Let the MBAS initiate the FTP in response to a mailed request, then prepare for the UUCP (or whatever) transfer. Presumably, after the file is copied via whatever other pay-per-use means, its storage would be reaped. But is the FTP traffic then really for an authorized Internet user? If the transfer was automatically initiated on behalf of someone who's not connected, what is the legal status of the resultant traffic? Who wants to ask? Since the MBAS genie is not going to go quietly back into its bottle, it would be more constructive to suggest responsible strategies for running them -- and provide software to implement those strategies -- than to inveigh against the entire phenomenon. Indeed so! And that's the sort of discussion I hoped to start. Let's find a way to help people be responsible with other people's resources. You've suggested a couple of good starters.
bob@MorningStar.Com (Bob Sutterfield) (08/25/90)
In article <1990Aug23.200043.17259@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: In article <BOB.90Aug22102618@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: A mail-based archive server is an impolite and destructive way to distribute large amounts of information, and should be discouraged in such applications. ...if this message is in response to my request for information about mail servers, it doen't really apply. Yours prompted it, but it's really in response to the general trend. What I want to do is to set up something resembling a library service within our organization to help avoid duplication of effort by various branches. The transport is already established and would be unlikely to send anything beyond our own offices. You're right - this is unrelated to the subject of my diatribe (:-) since it doesn't involve other people's money. In fact, it sounds like a pretty good idea! It seems like this is something that every group with an established electronic mail service would need, so I'm kind of surprised that the current crop of programs seem pretty much oriented towards distributing program sources. People just haven't generalized the idea yet. I've toyed with the idea of using RFC822 envelopes to carry, e.g., SQL queries and responses... Any number of schemes are possible, usually based around a reliable file transfer protocol. How would you like to train a few hundred people to adapt to "any number of schemes"? ... they already know how to use a mail program for other reasons. They shouldn't need to adapt to anything they don't already know how to use. I was saying that, no matter what users are already using, a user-compatible scheme could probably be hacked together. Virtually every other question of human time vs. computer resources these days is answered with "computer resources are cheap". They're particularly cheap if someone else is paying for it :-) In fact, Steven Wolff said about NSFnet bandwidth, something along the lines of `crunch all you want, we'll make more'. If mail transport of bulky items is a problem, then perhaps we should fix the problem rather than avoiding it. Telebit Trailblazers and other high-speed modems; advanced compression techniques; the increasing pervasiveness of the Internet, BITnet, SPAN, and friends; and other factors are rapidly bringing transport costs down. But only one of those types of factors provides zero-incremental-cost data transfer. There are still a lot of folks out there who pay Ma Bell (or whomever) for every minute they use slinging bits hither and yon. And if those bits belong to someone else, they are slung out of either ignorance or the goodness of their hearts. In either case, let's not take advantage of the hospitality.
bob@MorningStar.Com (08/25/90)
Date: 23 Aug 90 07:49:00 PDT (Thu) From: hplabs!mrm%Sceard.COM (M.R.Murphy) (Your From: line is confused! I hope your .signature was right...) What do you say to a direct connect (say via dialup UUCP) to a site with a mail to ftp converter? No problem, so long as the converter recognizes its direct connections, or at least has enough smarts to discriminate between zero- and nonzero-incremental cost networks in order to refuse non-directly connected folks' mailed requests. Those smarts are tough, because domainists have worked hard to obscure the differences for mail users. And in the case of remote nonzero-incremental-cost connections, there's no closed-form way for the converter to find out whether the requestor is paying for the connection. So your case of accepting only direct-connect requests is probably safe, but presents somewhat more of an administrative load on the maintainer of the converter site. Then there's the policy question: Is FTP activity in automatic response to a mail request from a non-Internet-connected site permissible traffic on this particular Internet tributary, or the [inter]national backbones? One answer might be "no, because if they were authorized to make independent use of the Internet they'd have their own connection." Does anyone really want to ask?
emv@math.lsa.umich.edu (Edward Vielmetti) (08/25/90)
It appears from this discussion that an RFC on anonymous FTP, mail-based archive servers, and other considerations that internet archivists & researchers face would be in order. That is just to say, I'm taking notes & collecting names.... on a small tangent. Bob Sutterfield asks: But is the FTP traffic then really for an authorized Internet user? If the transfer was automatically initiated on behalf of someone who's not connected, what is the legal status of the resultant traffic? Who wants to ask? RFC 1174 indicates that the simple binary "connected/not connected" status has been recommended by the IAB to disappear, to be replaced by a statement by each network regarding acceptable use and a policy on transit traffic. This is not new policy yet, but it's the right place to look for guidance. (Author is Vint Cerf. You want to ask Vint, be my guest...) --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> moderator, comp.archives
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (08/26/90)
In article <9RE5N-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Just make sure your mail-based server can recognise a NZIC link (easy, it's >got a "!" in it) and refuses to send if it's not terminal. It's not quite that simple, but close...the path must not only have a ! in it, but the first name before the ! must also not be a local, non-measured-service telephone call. The MBAS can have a list of such links, as there won't be many of them. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
david@twg.com (David S. Herron) (08/28/90)
mail based servers of all kinds exist and are proliferating because they serve useful purposes! They are able to reach to places which no other protocol can reach. For instance Bob suggested that people should use UUCP to pay for their own access to archives. That's a good idea .. but what if the archive is on an IBM machine on BITNET? No UUCP access there... I think that this situation will always exist -- that some parts of the network will always be hard-to-reach, but that e-mail will always reach those places. Therefore this trend will continue. Also the archive sites you can dial up to don't necessarily archive whatever it is you're interested in getting. Different archives have different sets of interest. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
bob@MorningStar.Com (Bob Sutterfield) (08/28/90)
In article <9RE5N-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
So how should a UUNET customer get data from FTP-able archives? The
only way I know is to use a (*shudder*) mail-based archive server
Ruling them out is throwing the baby out with the bathwater.
That's an example of a good use for a MBAS. I don't urge abandonment,
only awareness, caution, and responsibility.
Just make sure your mail-based server can recognise a NZIC
[Non-Zero Incremental Cost] link (easy, it's got a "!" in it) and
refuses to send if it's not terminal.
(1) There are many ways to build NZIC networks, and few of them use a
"!" delimiter to mean the same thing as a UUCP-based network does.
(2) Among the other features of the Domain Name System is its
assistance in hiding such transport-level properties from
applications.sds@jazzie.wa.com (Sean Shapira) (08/28/90)
bob@MorningStar.Com (Bob Sutterfield) writes: >If a site is not so connected, then they can pay for the transient >connectivity when they need it. [He then describes the Ohio State and UUNET dialup access facilities.] Sites can arrange such connectivity, but users don't always have such freedom. I wonder to what extent the popularity of mail servers is attributable to users accessing them without intercession by, or the knowledge of, site administrators. -- Sean Shapira "If there were no winters to guard against, then the sds@jazzie.wa.com grasshoppper would not get his come-uppance, nor the (206) 322-4742 ant his shabby victory." --Bernard Suits
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (08/29/90)
In article <BOB.90Aug27182122@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: >In article <9RE5N-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > Just make sure your mail-based server can recognise a NZIC > [Non-Zero Incremental Cost] link (easy, it's got a "!" in it) and > refuses to send if it's not terminal. >(2) Among the other features of the Domain Name System is its >assistance in hiding such transport-level properties from >applications. Most of the DNS is pure win. You've identified one place where it's a problem: it prevents a user from finding out such properties if that's needed. If the application had that information available, then it could make an intelligent decision about whether or not to use such a link. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
peter@ficc.ferranti.com (Peter da Silva) (08/30/90)
In article <9RE5N-9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > Just make sure your mail-based server can recognise a NZIC > [Non-Zero Incremental Cost] link (easy, it's got a "!" in it) and > refuses to send if it's not terminal. In article <BOB.90Aug27182122@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: > (2) Among the other features of the Domain Name System is its > assistance in hiding such transport-level properties from > applications. But in most cases a NZIC link hidden in the DNS is paid for by the owner of that domain. Unless you put third parties in your own domain this is not a problem. And even if you do, you can presumably remonstrate with them about it. The problem with mailservers is when they start routing messages through NZIC links where neither end is accountable for the cost. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
cluther@supernet.haus.com (Clay Luther) (10/19/90)
I am looking for information on archive mail servers to pass on to the users at my site. Please feel free to mail me any information you may have regarding these beasts, as well as the general "flavor" of the archives available at each server. Thanks! -- Clay Luther, Postmaster cluther@supernet.haus.com postmaster@supernet.haus.com clay.luther@supernet.haus.com Harris Adacom Corporation MS 23, PO Box 809022, Dallas, Tx 75380-9022 214/386-2356 Your mileage may vary. Void where prohibited.