Date: Thu, 4 Mar 93 04:30:08 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #60
To: tcp-group-digest
TCP-Group Digest Thu, 4 Mar 93 Volume 93 : Issue 60
Today's Topics:
$5000 TNC -> $2500 -> $1250 -> $625 -> $312 -> $156 TNC
AX.25 Driver for NeXT system? (2 msgs)
Defining the link bits
GRI 2.0m and multiple FTP drives (2 msgs)
Link Layer replacement (6 msgs)
Nos/Net for VMS??
physical layer and FEC engineering (3 msgs)
SCC Cards and Open Squelch DCD
Uncle Phil uses a philter
USING POP
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 3 Mar 1993 09:11:20 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: $5000 TNC -> $2500 -> $1250 -> $625 -> $312 -> $156 TNC
To: tcp-group@ucsd.edu
The subject line is admittedly extreme, but in arguing against designing
systems around expensive hardware, Jay Maynard makes one of the strongest
points in favor of such designs.
CPU power and memory will continue to get cheaper over time. When we
design systems for large-scale implementation later this year, we can use
today's cost of hardware and not be too far off. However, when we're
designing systems for large-scale implementation in 2-6 years, equivalent
CPU power and memory will be available for 1/2 to 1/8 the price. So
today's $2500 TNC that requires a 386-DX 25 MHz will be $312 when amateurs
are buying it in large quantities.
The biggest mistake we can make is not taking future hardware prices into
account when we're designing systems for the long haul.
73, Bob, ke9yq
------------------------------
Date: Tue Mar 02 18:31:22 1993
From: rbates@inquire.pixar.com (Rick Bates)
Subject: AX.25 Driver for NeXT system?
To: tcp-group@ucsd.edu
Greetings.
I know that this may get flames because it may not be the correct area to ask
but...
There is a NeXT computer nearby that has access to the Internet. It is owned
by a ham who has been very helpful in letting a few of us get mail to/from this
group. We can (by phone) do PPP, SLIP, FTP, SMTP, rlogin and uucp mail to his
system. We would like to return the favor and get him on the local tcp/ip net
on two meters (or higher/faster).
The NeXT runs a variant of Unix. So...
Does someone know of an AX.25 driver for a NeXT computer that will allow
a ppp connect or similar to get the NeXT on the air? We are hoping to have
full service (as much as he will allow of course), but a minimum of FTP and
SMTP would be a start and would simplify some of his activities.
I am hopeful that a driver already exists and that it is all that will be
needed to get him talking packet. Anyone with a NeXT on packet TCP/IP?
Thanks for the bandwidth. 73,
Rick
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: Rick Bates Internet : rbates@inquire.pixar.com :
: WA6NHC amprnet : wa6nhc@petaluma.ampr.org :
: packetnet : wa6nhc @ wx3k :
: Petaluma, California CompuServe: 70370,523 :
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: The trouble in trusting the common sense of your fellow man is that you :
: will find that it is not very common at all. :
: Mark Twain :
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
------------------------------
Date: Wed, 3 Mar 93 08:47:23 -0500
From: Jim De Arras <jmd@cube.handheld.com>
Subject: AX.25 Driver for NeXT system?
To: rbates@inquire.pixar.com (Rick Bates)
>
> Greetings.
>
> I know that this may get flames because it may not be the correct area to ask
> but...
>
> There is a NeXT computer nearby that has access to the Internet. It is owned
> by a ham who has been very helpful in letting a few of us get mail to/from
this
> group. We can (by phone) do PPP, SLIP, FTP, SMTP, rlogin and uucp mail to
his
> system. We would like to return the favor and get him on the local tcp/ip
net
> on two meters (or higher/faster).
>
> The NeXT runs a variant of Unix. So...
>
> Does someone know of an AX.25 driver for a NeXT computer that will allow
> a ppp connect or similar to get the NeXT on the air? We are hoping to have
> full service (as much as he will allow of course), but a minimum of FTP and
> SMTP would be a start and would simplify some of his activities.
>
> I am hopeful that a driver already exists and that it is all that will be
> needed to get him talking packet. Anyone with a NeXT on packet TCP/IP?
>
> Thanks for the bandwidth. 73,
>
> Rick
>
>
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> : Rick Bates Internet : rbates@inquire.pixar.com :
> : WA6NHC amprnet : wa6nhc@petaluma.ampr.org :
> : packetnet : wa6nhc @ wx3k :
> : Petaluma, California CompuServe: 70370,523 :
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> : The trouble in trusting the common sense of your fellow man is that you :
> : will find that it is not very common at all. :
> : Mark Twain :
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
I have a number of NeXTs, and a gateway, here. I have a PC running NOS on the
air, but the NeXTs are accessable through that PC just as well as if the NeXTs
were directly on the air. That approach will have the most support, i.e.,
there is more work going on for PC versions of NOS than any other platform.
Jim
WA4ONG@wa4ong.ampr.org
------------------------------
Date: Tue, 2 Mar 1993 21:22:47 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Defining the link bits
To: TCP-Group@UCSD.Edu
Chris Cox says about what Steve Sampson says:
>> I don't know if I like all that callsign stuff in there. It's basically a
>> rider that only has to be sent on initial connect. Why send it over and
>> over?
>
> Just because that is the case in the good ole US of A, don't assume that
> it is the case in every other country on Earth.
Well I really don't care what other countries do. We're talking about the FCC
and the death of AX.25 and what is to replace it. If the other countries want
to stick with AX.25 - have a ball. As far as the US is concerned, the 10 min
ID will probably be around for our lifetime, so a simple header transmission
will suffice:
FEC preamble: 8 Octets calculated
Destination: 8 Octets Broadcast Address
Source: 8 Octets Your number
Packet Type: 2 Octets 250 or whatever
Packet Data: n Octets eg, N5OWK/352008N/0972819W/25Watts/Omni, etc.
Or something like that. Make it useful for routing. In the above example a
router with a beam in the right direction would have a greater value than an
omni. Same for power. Nothing new here except the removal of 8 digipeater
callsigns, and the source and destination callsigns. ie, Datagram. Then we
can rob from the ethernet router designs to finish it off. Here's an idea
for a static address design:
State: 1 Octet Assigned as they entered Union
County: 1 Octet Assigned Alphabetically
City: 2 Octets Assigned Alphabetically
Network ID: 2 Octets |
Subnet ID: 1 Octet | Class B
Host ID: 1 Octet |
That way when someone routes via HF you can mask off the state to see if you're
close or have a good propogation path to that state. I would hope a modem
designed for HF was used rather than straight FSK.
---
Steve, N5OWK
------------------------------
Date: 02 Mar 1993 22:16:15 +0800
From: RON MURRAY <NMURRAYR@cc.curtin.edu.au>
Subject: GRI 2.0m and multiple FTP drives
To: JT@zfja-gate.fuw.edu.pl
In a previous message, I was discussing the /ftpusers file, and said:
>> and take the mailbox permissions from the first permissions field.
>> It's quite possible that the code already does this; I must admit that I
JT replied:
> As I remember my code does it. The extra permission fields are used for
> file accesses only.
Fair enough. I still haven't looked. Good to see we both agree on the right
way to do it :-).
> And first matching directory is used, since cannot
> set different permission for subdirectory of primary directory, e.g.
> I use directory guest for anonymous login and want it to be read-only,
> I cannot put read/write subdirectory guest/incoming in it, use ../in.
> (if permcheck would look for longest match instead first, it would be
> possible, but I had no time for coding it).
I have a look into it myself if I get the time. I'm currently peering at
Phil's new code with a view to incorporating some of the old GRI stuff into
them (unless, of course, someone else has already done it!). So far I've
managed to un-RCS everything, and it compiles and runs ok, so that's a start!
> I don't see reason to make floppies accessible for FTP. If they weren't
> specified in ftpusers, NOS wouldn't try to access them. 73's, JT
For anonymous ftp, no, it probably isn't a good idea to make the floppies
accessible. However, I have a 286 (the packet machine) and a 486 (the
development machine) in the same room here, about two metres apart and
connected by an ethernet link. There have been occasions when ftp to/from
floppies could be useful (notably once when I had a flakey disk: the 486's
drive wouldn't touch it, but the 286's drive read it fine). It's a feature
we might as well leave in, I suppose; I was more curious about the effect I
got when I tried ftp'ing to an empty floppy drive!
.....Ron
------------------------------
Date: Tue, 2 Mar 93 20:41:55 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: GRI 2.0m and multiple FTP drives
To: RON MURRAY <NMURRAYR@cc.curtin.edu.au>
> Date: 02 Mar 1993 22:16:15 +0800
> Message-id: <01GVCJN4Z04I9ODK2M@cc.curtin.edu.au>
> > And first matching directory is used, since cannot
> I have a look into it myself if I get the time. I'm currently peering at
> Phil's new code with a view to incorporating some of the old GRI stuff into
This is permcheck function in FTPSERV.C, I made many changes to it. 73's
------------------------------
Date: Mon, 1 Mar 93 14:50:31 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: Link Layer replacement
To: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
> This is cool at the MAC/Physical layer, but for upper layers it makes
> processing the packet a bit harder (i.e having to find how long and
> what type the addresses are).
>
Upper layers? They would be using the network-layer packet -- that is,
IP. This is the TCP-Group, isn't it?
> This just means that the Link Layer Control has to convert from one
> to the other (in the same whay that 802.3 packets have to be converted
> to Token Ring or CSMA/CD format).
>
Unclean, unclean! (It sounds like you are of the multimedia bridging
faith.)
The only case that the link-layer address needs to be known is in ARP.
And in that case, there is no "conversion". You just remember the
actual address.
Passing around link-layer addresses is a real problem anywhere. No
guarantee of format or uniqueness.
That's why we have separate link-layer and network-layer addressing.
It's not just historical accident, it's by design.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Wed, 3 Mar 93 12:50:47 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Link Layer replacement
To: bsimpson@morningstar.com, wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
In atricle by "William Allen Simpson":
>
[ I suggested that the MAC layer could `compress' link layer
addresses to conserve bandwidth. Bill disagreed with this
idea, or was unsure as to what I was proposing ]
> > This just means that the Link Layer Control has to convert from one
> > to the other (in the same whay that 802.3 packets have to be converted
> > to Token Ring or CSMA/CD format).
> >
> Unclean, unclean! (It sounds like you are of the multimedia bridging
> faith.)
Compressed SLIP and PPP both `compress' network layer addresses. I can't
see why this sort of thing can't be done at the MAC layer. The only
requirement of the Link Layer Control is that:
+ the sender gives it a packet with link layer source and
destination addresses, and data.
+ the same packet is received (or lost) as the destination.
The LLC or the MAC is in a position to remove redundancies in the packet
_if_ there is a need to conserve bandwidth. Obviously if there is no need
then don't do it.
However, we've got to ensure a consistent packet format between the LLC
and the network layers above it. And when we're designing a set of
protocols that should work across:
+ HF at 300/1200 bps
+ VHF/UHF at 1200/4800/9600 bps
+ UHF/microwave at 19200+ bps
then we're going to need different Medium Access methods with different
error correction/detection methods as well. If we can save bandwidth at
300bps and make it transparent, then why not do it?
An analogy is the fact that Ethernet (802.3) and FDDI packets are both
different on the wire/fibre, although the packets are the same at the
Link Layer Control.
Cheers,
Warren
------------------------------
Date: Wed, 03 Mar 1993 15:49:59 -0500
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Link Layer replacement
To: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
> Compressed SLIP and PPP both `compress' network layer addresses. I can't
> see why this sort of thing can't be done at the MAC layer.
If you are referring to VJ TCP header compression, this only works if
the (point-to-point) link is relatively error-free.
> However, we've got to ensure a consistent packet format between the LLC
> and the network layers above it. And when we're designing a set of
> protocols that should work across:
>
> + HF at 300/1200 bps
>
> + VHF/UHF at 1200/4800/9600 bps
>
> + UHF/microwave at 19200+ bps
I guess that I have to wonder why we're working so hard to come up
with a single encapsulation method. Design and use what'a appropriate
for the medium. That's why on the Inteternet you see a whole pile 'o
different encapsulations (SLIP and PPP on point-to-point serial, DIX
"Ethernet" encapsulation on Ethernet, IEEE 802.3 on Ethernet and FDDI,
stuff for HSSI, X.25, etc.
You need only a common network protocol end-to-end.
> then we're going to need different Medium Access methods with different
> error correction/detection methods as well. If we can save bandwidth at
> 300bps and make it transparent, then why not do it?
I guess that I considered medium access to be more a hardware sort of
thing (CSMA/CD or token passing) rather than so much of a link level
protocol.
> An analogy is the fact that Ethernet (802.3) and FDDI packets are both
> different on the wire/fibre, although the packets are the same at the
> Link Layer Control.
Except that the MAC addresses are backwards...
Louis A. Mamakos
wa3ymh
------------------------------
Date: 3 Mar 93 18:13:00 PST
From: "39A::MUSCHINSKE" <MUSCHINSKE%39A.decnet@scfb.chinalake.navy.mil>
Subject: Link Layer replacement
To: "TCP-GROUP" <TCP-GROUP@UCSD.EDU>
Warren writes:
>[wkt%csadfa.cs.adfa.OZ.AU@seismo.css.gov (Warren Toomey)]
>[<9303030150.AA27713@csadfa.cs.adfa.oz.au>]
>
-------Stuff deleted...
>However, we've got to ensure a consistent packet format between the LLC
>and the network layers above it. And when we're designing a set of
>protocols that should work across:
>
> + HF at 300/1200 bps
>
> + VHF/UHF at 1200/4800/9600 bps
>
> + UHF/microwave at 19200+ bps
>
>then we're going to need different Medium Access methods with different
>error correction/detection methods as well. If we can save bandwidth at
>300bps and make it transparent, then why not do it?
>
-------Stuff deleted...
Warren gets to a point in this thread that has been nibbling around the
edges of my thoughts. Because we face so many different RF environments
in getting the RF bits from point A to B, maybe we need 3 or 4 different
protocols at the lowest level. Then a standard interface to the higher
levels.
The way I see it, from the RF bits level, ('cause I'm a RF kinda guy) the
following protocols are needed:
1. A protocol designed strictly for HF propigation. Can deal with
fading, multipath, interference and high noise levels. Should be
adaptive to maximize throughput based on channel conditions. Band
widths up to 6 kHz (max width for AM signal).
2. A protocol for multiple access. This one has to be designed
with the hidden transmitter problem in mind. It also has to allow
for stuffing into the ROM on a TNC2. While we can change the
protocol, the large user community will not yet throw away their
TNCs (remember P.O.T.S.). Rates are 1200 and up at VHF/UHF.
3. A protocol for high speed point-to-point links. These will
be at UHF and microwave. Should handle from 19.2k up past 1M bps.
Overhead should not be a problem, but should be efficient at
routing.
4. (Maybe) A broadcast protocol for bulletin distribution.
It might also be useful to be able to stuff this one into
the TNC2 ROM. It could help ease the pressure on our crowded
VHF channels.
I'm interested in your thoughts.
73, Erich KA6AMD @ WA6YBN.#SOCA.CA.USA.NA
Internet: muschinske%39a.decnet@scfb.chinalake.navy.mil
------------------------------
Date: Thu, 4 Mar 93 15:11:28 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Link Layer replacement
To: "Louis A. Mamakos" <louie@NI.umd.edu>,
> > However, we've got to ensure a consistent packet format between the LLC
> > and the network layers above it. And when we're designing a set of
^^^
>
> I guess that I have to wonder why we're working so hard to come up
> with a single encapsulation method. Design and use what'a appropriate
> for the medium.
Exactly. That's why I'm proposing a single link layer interface that
you use to pass packets between the network software (IP), and the
link layer. But we need to design _different_ methods of
a) bit representation on the physical medium
b) medium access
c) error correction and detection
d) link address
Therefore while we need ONE link layer interface, we need a SET of
Physical and MAC layers.
Cheers!
Warren
------------------------------
Date: Thu, 4 Mar 1993 14:47:42 +1000
From: makinc@hhcs.gov.au
Subject: Link Layer replacement
To: tcp-group@ucsd.edu
Bill writes;
> Upper layers? They would be using the network-layer packet -- that is,
> IP. This is the TCP-Group, isn't it?
Not necessarily. Why should we tie it to IP? In fact one idea that Phil
had was to add in a sub-networking layer to make the local radio network
appear to be a fully connected network to IP.
Carl.
--
Carl Makin (VK1KCM) Systems Programmer
Internet: makinc@hhcs.gov.au
Amprnet: vk1kcm@vk1kcm.act.aus.oc
Work Phone: +61 6 289-9443
------------------------------
Date: Wed, 03 Mar 93 14:13:15 UTC
From: g6phf@wg7j.ECE.ORST.EDU
Subject: Nos/Net for VMS??
To: tcp-group@ucsd.edu
A friend of mina e has been asking if a version of nos or net exists for
VMS?? If so where can it be ftpd frp om and what version of nos or net is it?
Thanks in advance,
Mike (whos backspace dont work!)
------------------------------
Date: Wed, 3 Mar 93 10:07:10 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: physical layer and FEC engineering
To: crompton@NADC.NAVY.MIL, sbrown@charon.dseg.ti.com
Yes I mean 386sx-25MHZ motherboards for in the area of $100 - 33Mhz for
$125. The 386sx-25's were available for $125 as long ago as last April
at the annual Trenton computer fest in NJ.
This stuff is dirt cheap! You can put together a nice system for $300-500
depending on the hard disk. Updating and existing system could be done
for the price of a Motherboard and some RAM at $30/meg.
I know it is hard to believe but unlike any other products in the world
electronics gives more for less as time goes on. Adjusted for inflation
it is ridiculously low. I keep a cutout from a magazine about 1987
vintage under my desk glass - 286/8mhz motherboard for $1200 and a
40 Meg hard drive for $800.
In terms of performance - try this test - if it would work - compile
NOS from scratch on a 4.77Mhz XT, then do the same on a 486/33, I
think you will find that the difference approaches 100X. Add the use
of the co-processor in other applications and the difference even becomes
more dramatic. Of course some of this increase is I/O improvement - the
ability to use more RAM for disk spoolers/ramdisks etc. which are not
available on the earlier machines.
I get a kick out of these people who are at the cutting edge of technology
and using pre-historic computers, especially in light of the affordability
of today's technology.
Doug
------------------------------
Date: Wed, 3 Mar 93 18:50:33 -0800
From: brian (Brian Kantor)
Subject: physical layer and FEC engineering
To: tcp-group
It would seem to me that the upcoming TAPR meeting (in Tucson this
weekend) would be a fine opportunity to brainstorm some of these ideas,
waving arms and hands around. Home of packet and all that.
I'll be there. If I can get a hotel room.
- Brian
------------------------------
Date: Thu, 4 Mar 93 02:23:39 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: physical layer and FEC engineering
To: brian@UCSD.EDU, tcp-group@UCSD.EDU
I'll be there too. Friday night, at least (they were booked up for Saturday,
gotta find alternative plans).
Phil
------------------------------
Date: Wed, 03 Mar 93 15:19:00 MET
From: GW6HVA%PI8VNW@pa2aga.ampr.org
Subject: SCC Cards and Open Squelch DCD
To: TCPAGA@pa2aga.ampr.org
Barry - VE3JF, asks about SCC cards and open squelch DCD.
Several people have already suggested that he try the TAPR "State ROM" approach
This is preferable as the circuit can be cloned quite reliably with little or
no setting up involved. I have played with PLL's linked to the SCC DPLL output
and also external stand alone PLL's - but have not improved upon the efficiency
of the TAPR design.
I have developed a single Eurocard sized open squelch card which carries 6
independant circuits which I use on my 6 1200 baud ports on an Atari ST running
8 SCC ports running under PE1CHL NET.
Using the software DCD, I start to see overruns on the SCC's (slowing the 2
9600 full duplex ports as well). So, unless you have CPU time to spare, the
TAPR solution is about the best.
Martin, GW6HVA @ GB7OSP (BBS NET) gw6hva@gw6hva or gw6hva@gb7os
PLEASE reply to the list, NOT to the From: address
because this mail is sent through a one-way gateway!
------------------------------
Date: Tue, 2 Mar 1993 10:38:45 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Uncle Phil uses a philter
To: prg@mgweed.att.com
A while back, Phil KA9Q mentioned that he has a filter divert all mail
that contains the address "tcp-group" to a file that he reads less often
than his personal mail. Thus, if you want to get his attention, don't copy
the mail to "tcp-group".
Bruce
------------------------------
Date: Tue, 2 Mar 93 13:45:24 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: USING POP
To: tcp-group@ucsd.edu
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Newsgroups: mail.tcp-group
Subject: USING POP
Message-ID: <37525@ucsd.Edu>
Date: 16 Jul 91 16:09:54 GMT
It seems that some group members missed an earlier message I sent out
on POP. I am repeating it here for there benefit. Hope this answers
most questions on the usage of POP.
Since Doug put this out in 1991 POP3 has become the protocol to
use and is part of almost all current nos. As it turns out the
method to set up as a POP USER has changed with POP3 and I will
add that information to Doug's for a complete statement on using
POP.
How to use POP in NOS
---------------------
The HOST should establish a 'POPUSERS.' file in root with the following
format:
username:password:
username:password:
etc.
There should be an entry for each user of your POP system. We generally
use call letters for both entries. I.E. wa3dsp:wa3dsp:
The HOST must also start the pop server 'start pop' which should go in
your NOS autoexec.
*******************If your NOT using POP3 ************************
Each USER must add the following lines to there autoexec:
'pop mailbox CALL'
Where CALL is the name of the mailbox on the host
to retrieve mail from. The /spool/mail/CALL.txt file.
Usually the users call.
'pop mailhost hostname'
This specifies what host to pop from.
I.E. 'pop mailhost wa3dsp.ampr.org'
'pop userdata user password'
This data should match the data in the
hosts /popuser file.
I.E. 'pop userdata wa3dsp wa3dsp'
'pop timer 3600'
For stations that are on for extended periods
and receive there mail via pop from a mailhost
this timer must be set to interrogate the host
on a regular basis. Alternatively they could
do a 'pop kick' to check for mail. Time should
be set to probably no less than 1/2 hour on a
radio circuit.
'pop kick'
This should be entered at the end of your
autoexec to check for mail from your mailhost
at startup.
So the autoexec entries would look like this for USER w3iwi...
pop mailbox w3iwi
pop mailhost wa3dsp.ampr.org
pop userdata w3iwi w3iwi
pop timer 3600
pop kick
and HOST wa3dsp's autoexec...
start pop
HOST wa3dsp's popusers. in root....
w3iwi:w3iwi:
******************** If you ARE using POP3 *************
Verify that your using POP3 this way; At the nos prompt type 'pop
add' and if your using POP3 you will see:
net> pop add
net> Usage: popmail addserver <mailserver> [<seconds>] [hh:mm-
hh:mm] <protocol> <mailbox> <username> <password>
net>
Now the way to set up as a USER is to put in autoexec.nos a line
that gives nos all the required info. Using the example above:
<mailserver> = wa3dsp
[<seconds>] = 3600 = 1 hour between pop requests
<protocal> = POP3
<mailbox> = w3iwi.txt (what to call the file from the Host)
<username> = w3iwi
<password> = w3iwi
So the line you will type in autoexec.nos will be:
pop add wa3dsp 3600 POP3 w3iwi.txt w3iwi w3iwi
Different than what earlier pop used but still simple.
A few other points...
If a pop users wants mail to be delivered to the host for them to pick
up via POP they should enter a 'reply to' field in BM.RC to direct
mail to the host and not back to them.
POP is a very good service for Amateur Radio. It is especially good
when a flood of messages are sent out to all users. This is a condition
that often causes crashes on memory marginal systems using SMTP. Also
alot of unnecessary traffic is sent out to stations that are not on the
air. With POP the user asks for and gets mail. This is naturally a random
operation. Lowering channel congestion and NOS memory usage.
Mail that is POP'ed from the host is deleted from the /spool/mail
directory upon successful transfer. The USER is notified that new
mail has arrived at the completion of the entire transfer.
One drawback that I notice with POP is that the messages (many could
build up) for a user are sent as a group. If the circuit fails with
a hard error halfway thru a POP xfer of a message group, no messages
are saved at the user end, even though some got thru. It is an all
or none with POP. This reminds me of the stupidity of BBS's in this
regard. Hopefully users will not let messages build up. I have some
users who let the mail build up to 30 or 40K over a few weeks.
Doug
Karl
____________________________
| Internet IP 155.148.6.2 |
| Fido 1:305/111 |
| k5di@k5di.nm.usa.na |
| Ham IP 44.30.2.5 |
| (505) 678-3145 weekdays |
|__________________________|
------------------------------
End of TCP-Group Digest V93 #60
******************************
******************************