Hi All

If I give "fetchmail -u srikanthns -p pop3 mail.vsnl.com"
and when I give the password at the prompt it reports
an SMTP error in Slack9 and does not flush the mails.

The same procedure in RH9 retrieves the mails without
any problem and stores the mail in /var/spool/mail/srikanth.
That I read thru sylpheed. In both I did not give any other
switches or options.

Why it works in RH9 without any problem but not in Slack9?

Cheeka

["Followup-To:" header set to alt.os.linux.slackware.]
On Sat, 29 Nov 2003 20:07:42 +0500, N S Srikanth <nssrikanth@hotmail.com> wrote:
You're asking the wrong question. The question is "why is my SMTP
server rejecting the mails with a 451 status code?". What is the
output when you run fetchmail in verbose mode?


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

"NSS" == N S Srikanth <nssrikanth@hotmail.com>:
NSS> If I give "fetchmail -u srikanthns -p pop3 mail.vsnl.com"
NSS> and when I give the password at the prompt it reports
NSS> an SMTP error in Slack9 and does not flush the mails.

Does your Slack9 box allow receiving messages via SMTP from localhost?

Run fetchmail in verbose mode and post its output (after sanitizing a
bit perhaps).

-=-
This message was posted via two or more anonymous remailing services.

Anonymous wrote:
The following is the output

srikanth@darkstar:~$ fetchmail -v -u srikanthns -p pop3 mail.vsnl.com
Enter password for srikanthns@mail.vsnl.com:
fetchmail: 6.2.4 querying mail.vsnl.com (protocol POP3) at Sun Nov 30
09:17:58 2003: poll started
fetchmail: POP3< +OK Messaging Multiplexor (iPlanet Messaging Server 5.2
HotFix 1.16 (built May 14 2003))
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR invalid command
fetchmail: invalid command
fetchmail: Repoll immediately on srikanthns@mail.vsnl.com
fetchmail: POP3< +OK Messaging Multiplexor (iPlanet Messaging Server 5.2
HotFix 1.16 (built May 14 2003))
fetchmail: POP3> USER srikanthns
fetchmail: POP3< +OK password required for user srikanthns@vsnl.com
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Maildrop ready
fetchmail: POP3> STAT
fetchmail: POP3< +OK 7 16463
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
7 messages for srikanthns at mail.vsnl.com (16463 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK scan listing follows
fetchmail: POP3< 1 2595
fetchmail: POP3< 2 2420
fetchmail: POP3< 3 2126
fetchmail: POP3< 4 3094
fetchmail: POP3< 5 2167
fetchmail: POP3< 6 1670
fetchmail: POP3< 7 2391
fetchmail: POP3< .
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK
reading message srikanthns@mail.vsnl.com:1 of 7 (2595 octets)
fetchmail: SMTP< 220 darkstar.example.net ESMTP Sendmail 8.12.10/8.12.10;
Sun, 30 Nov 2003 09:18:04 +0530
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-darkstar.example.net Hello localhost [127.0.0.1],
pleased to meet you
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-DSN
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-DELIVERBY
fetchmail: SMTP< 250 HELP
fetchmail: SMTP> MAIL FROM:<ozdewwwqkxyski@hongkong.com> SIZE=2595
fetchmail: SMTP< 451 4.1.8 Domain of sender address
ozdewwwqkxyski@hongkong.com does not resolve
fetchmail: SMTP error: 451 4.1.8 Domain of sender address
ozdewwwqkxyski@hongkong.com does not resolve
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 2.0.0 Reset state
.. not flushed
fetchmail: POP3> TOP 2 99999999
fetchmail: POP3< +OK
reading message srikanthns@mail.vsnl.com:2 of 7 (2420 octets)
fetchmail: SMTP> MAIL FROM:<mike@hotmail.com> SIZE=2420
fetchmail: SMTP< 451 4.1.8 Domain of sender address mike@hotmail.com does
not resolve
fetchmail: SMTP error: 451 4.1.8 Domain of sender address mike@hotmail.com
does not resolve
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 2.0.0 Reset state
.. not flushed

|| This same error message for message 3 to 7 repeats||

fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.2.4 querying mail.vsnl.com (protocol POP3) at Sun Nov 30
09:18:08 2003: poll completed
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 darkstar.example.net closing connection
fetchmail: normal termination, status 0

Again, I repeat, the same command on line1 in RH9 fetches all mails and
stores it in
/var/spool/mail/srikanth

The following is the output of fetchmail in RH9 (another partition, same
m/c)
[srikanth@localhost srikanth]$ fetchmail -v -u srikanthns -p pop3
mail.vsnl.com
Enter password for srikanthns@mail.vsnl.com:
fetchmail: 6.2.0 querying mail.vsnl.com (protocol POP3) at Sun 30 Nov 2003
09:59
:25 AM IST: poll started
fetchmail: POP3< +OK Messaging Multiplexor (iPlanet Messaging Server 5.2
HotFix
1.16 (built May 14 2003))
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR invalid command
fetchmail: invalid command
fetchmail: Repoll immediately on srikanthns@mail.vsnl.com
fetchmail: POP3< +OK Messaging Multiplexor (iPlanet Messaging Server 5.2
HotFix
1.16 (built May 14 2003))
fetchmail: POP3> USER srikanthns
fetchmail: POP3< +OK password required for user srikanthns@vsnl.com
fetchmail: POP3> PASS
fetchmail: POP3< +OK Maildrop ready
fetchmail: POP3> STAT
fetchmail: POP3< +OK 12 44545
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
12 messages for srikanthns at mail.vsnl.com (44545 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK scan listing follows
fetchmail: POP3< 1 2595
fetchmail: POP3< 2 2420
fetchmail: POP3< 3 2126
fetchmail: POP3< 4 3094
fetchmail: POP3< 5 2167
fetchmail: POP3< 6 1670
fetchmail: POP3< 7 2391
fetchmail: POP3< 8 11489
fetchmail: POP3< 9 2496
fetchmail: POP3< 10 2238
fetchmail: POP3< 11 6208
fetchmail: POP3< 12 5651
fetchmail: POP3< .
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK
reading message srikanthns@mail.vsnl.com:1 of 12 (2595 octets)
fetchmail: SMTP< 220 localhost.localdomain ESMTP Sendmail 8.12.8/8.12.8;
Sun, 30
Nov 2003 09:59:31 +0530
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-localhost.localdomain Hello localhost.localdomain
[127.0.0.
1], pleased to meet you
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-DSN
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-DELIVERBY
fetchmail: SMTP< 250 HELP
fetchmail: SMTP> MAIL FROM:<ozdewwwqkxyski@hongkong.com> SIZE=2595
fetchmail: SMTP< 250 2.1.0 <ozdewwwqkxyski@hongkong.com>... Sender ok
fetchmail: SMTP> RCPT TO:<srikanth@localhost>
fetchmail: SMTP< 250 2.1.5 <srikanth@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
#************************.*****************fetchma il: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 hAU4TVTG002437 Message accepted for delivery
flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK message deleted
fetchmail: POP3> TOP 2 99999999
fetchmail: POP3< +OK
reading message srikanthns@mail.vsnl.com:2 of 12 (2420 octets)
fetchmail: SMTP> MAIL FROM:<mike@hotmail.com> SIZE=2420
fetchmail: SMTP< 250 2.1.0 <mike@hotmail.com>... Sender ok
fetchmail: SMTP> RCPT TO:<srikanth@localhost>
fetchmail: SMTP< 250 2.1.5 <srikanth@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
#********************.******fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 hAU4TVTH002437 Message accepted for delivery
flushed
fetchmail: POP3> DELE 2
fetchmail: POP3< +OK message deleted

|| same thing continues for message 3 to 12|| then

fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.2.0 querying mail.vsnl.com (protocol POP3) at Sun 30 Nov 2003
09:59 :46 AM IST: poll completed
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 localhost.localdomain closing connection
fetchmail: normal termination, status 0

I am unable to understand the difference. Can you please guide me?


Cheeka

["Followup-To:" header set to alt.os.linux.slackware.]
On Sun, 30 Nov 2003 10:22:24 +0530, SRIKANTH NS <nssrikanth@hotmail.com> wrote:
Your Slackware setup has DNS problem. Have you defined the DNS servers
in /etc/resolv.conf?


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

"SN" == SRIKANTH NS <nssrikanth@hotmail.com>:
SN> fetchmail: SMTP> MAIL FROM:<ozdewwwqkxyski@hongkong.com> SIZE=2595
SN> fetchmail: SMTP< 451 4.1.8 Domain of sender address
SN> ozdewwwqkxyski@hongkong.com does not resolve
SN> fetchmail: SMTP error: 451 4.1.8 Domain of sender address
SN> ozdewwwqkxyski@hongkong.com does not resolve
SM> ...
SN> I am unable to understand the difference. Can you please guide me?

The sendmail security settings are different on the two systems.

There are two different ways to attack the problem:
- convince the sendmail SMTP daemon that anything sent from localhost
should be accepted and delivered
- use SMTP authentication and tell fetchmail to authenticate itself
when talking to the local sendmail SMTP daemon before attempting
delivery

I would go for the second solution. Read the sendmail documentation
(easier said than done) or the sendmail+authentication howto's, which
provide step-by-step instructions.

-=-
This message was posted via two or more anonymous remailing services.

"SRIKANTH NS" <nssrikanth@hotmail.com> wrote:
Here is one problem, which probably affects what is happening in some
negative way, though I'm not sure just what. You need to give your
machine a unique name rather than use the example configuration that
Slackware provides. See the installation docs for Slackware.

The one caveat, and I don't know if Slack 9.0 has it fixed or not,
but it is simply *wrong* to do something like this in your /etc/hosts
file:

127.0.0.1 host.domain.com localhost

The idea is that you must have your "host.domain.com" set up so
that it will resolve... but you do not want 127.0.0.1 to
resolve to *anything* other than "localhost". The easy way to
accomplish that on a system with no permanent network connection
when it boots, is to take advantage of the fact that the
127.x.x.x address block is masked off so that *any* of those
will go to the "lo" device. You can use something like,

127.0.0.1 localhost
127.0.0.2 host.domain.com host

and all will be hunky dory.

There are other ways to do it. One other is to use a "dummy"
network interface, which acts just like a loopback and can be
given any IP address and name that you'd like. But the above is
the simplest and easiest.

....

The above lines point at *two* configuration problems. One with
the system and one with fetchmail. Fix the system problem
first, or fetchmail is going to delete *every* message it sees!

First, sendmail is not able to resolve a valid IP address. That
is what "SMTP error: 451 4.1.8 Domain of sender address xxxx
does not resolve" means. That is exactly what you want to have
happen if xxxx is a bogus FQDN (host.domain.something that does
not have a real IP address). Your sendmail can't resolve valid
FQDN's because Domain Name Service (DNS) is not working, and
therefore sendmail is rejecting everything.

The second problem is configuring fetchmail to delete messages
that are (correctly) rejected by sendmail if the DNS cannot
resolve the name.

I can't tell what you might have in the way of a network setup,
so I can't suggest where to start for a fix on the DNS problem.
If you have one form or another of a ppp connection, there is
some way to query the ISP when you connect so that you are
provided with the IP address of one or more DNS servers. Read
the documentation on whatever you use to connect. (If it is
pppd and a dialup, there are several ways to do it, and if
you post what you've got there will be half a dozen people
give you different ways to make it work.)

The way to test whether it works is easy enough though!

dig hongkong.com

should get a page full of info that among other things says this

;; ANSWER SECTION:
hongkong.com. 2928 IN A 202.84.15.28

If instead you get something that says there was no server or no
response, follow up on whatever dig tells you caused it to fail.
When dig works, sendmail will too.

Once you have sendmail accepting emails from valid addresses, you
want fetchmail to delete any message that sendmail refuses to accept.
Read the man page for fetchmail, where the item you are interested in
is,

-Z <nnn>, --antispam <nnn[, nnn]...>
(Keyword: antispam) Specifies the list of numeric SMTP
errors that are to be interpreted as a spam-block response
from the listener. A value of -1 disables this option.
For the command-line option, the list values should be
comma-separated.

The problem is that fetchmail has a list of error codes from sendmail
that it knows about, but 451 is not one of them. Do a search through
the man page on "spam" and you'll find interesting reading. But the
fix for your problem is to add something to your .fetchmailrc file to
tell it about 451. For each server section, put in this line:

antispam 451 571 550 501 554

Also, you said nothing about having or knowing about a ~/.fetchmailrc
file. Look to see if there is one. If not, make one (and look on
the RH system where you might be able to just copy whatever is there).

But what you *must* do is read the man page for fetchmail one
line at a time, and add or delete things in your ~/.fetchmailrc
file as needed. Here is an example, which happens to be the
file I use. (I've changed things like user names, password, and
server name. Note also that in my case fetchmail is run from a
script that cron invokes.)

set postmaster root
set no bouncemail
set logfile /var/log/fetchmail

poll mail.server.com
proto POP3
preauth password
timeout 200
user user1 is user1 here
pass password
fetchall
nokeep
antispam 451 571 550 501 554
expunge 30

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

Anonymous wrote:
They don't solve the problem. Sendmail's default configuration will
still reject domains that don't resolve.

Since hongkong.com exists, Simon's suggestion of a DNS problem should be
investigated.

Paul

["Followup-To:" header set to alt.os.linux.slackware.]
On Sun, 30 Nov 2003 00:22:08 -0900, Floyd Davidson <floyd@barrow.com> wrote:
It's fixed in Slackware 9.1 (generated by netconfig):

127.0.0.1 localhost
192.168.0.5 dogbert.no-dns-yet.org.uk dogbert

s/(IP address)/MX record or \1/. Sendmail (and Exim can as well) looks
up the MX records for the sender's domain. If the sender's domain does
not have an MX record, it looks for an A record (IP address). One of
those queries must return a positive answer and it must be
authoritative.

I'd normally do it in this way:

$ host -t ns hongkong.com
hongkong.com name server ns2.hongkong.com.
hongkong.com name server ns3.hongkong.com.
hongkong.com name server ns2.china.com.
$ dig @ns2.hongkong.com hongkong.com mx
[...]
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
^^
[...]
;; ANSWER SECTION:
hongkong.com. 3600 IN MX 20 mx1.hongkong.com.

If the 'aa' above isn't present, the answer isn't authoritative. For
example, my server doesn't pretend that it's authoritative for
hongkong.com:

$ dig @localhost hongkong.com mx
[...]
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
[...]
;; ANSWER SECTION:
hongkong.com. 3351 IN MX 20 mx1.hongkong.com.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

Simon <usenet@no-dns-yet.org.uk> wrote:
And ignored, of course.

What happens if you *don't* have an ethernet card installed?

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

["Followup-To:" header set to alt.os.linux.slackware.]

Floyd Davidson <floyd@barrow.com> is thought to have
typed the following text on 2003-11-30:

network connections, and without any of them there's no use for
fetchmail, and very limited use for sendmail.

- --
Bartosz Oudekerk

Play Rogue, visit exotic locations, meet strange creatures
and kill them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/yeBO256ZyNYAOpkRAuGxAJ9hgI3Zu2RFdsu/7oB4vwsn4rT41gCfRVai
oJUHrbzpUImFfQFGJOub8d8=
=6/rb
-----END PGP SIGNATURE-----

On Sun, 30 Nov 2003 02:21:05 -0900, Floyd Davidson <floyd@barrow.com> wrote:
I don't have such a machine to test with, but /etc/hosts does say this:

# By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that 127.0.0.1
# should NEVER be named with the name of the machine. It causes problems
# for some (stupid) programs, irc and reputedly talk. :^)

I assume, therefore, that it would only insert this line in /etc/hosts:

127.0.0.1 localhost

I could, of course, be wrong.


--
Simon <simon@no-dns-yet.org.uk> **** GPG: F4A23C69
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams

Simon <usenet@no-dns-yet.org.uk> wrote:
I think Pat has had that, or something like it, in there since
maybe Slackware 8.0 or so. Or, at least it says something like
that in the sources, though I seem to recall that was different
than what was on the installation CD. I also seem to recall
that it only actually used the lo device temporarily while the
system was being installed, and then (once everything was in
place) did something to change it.

What I don't remember is what it did then (and what I never did
know what Slackware 9.0 does) if there is otherwise no interface
to assign an FQDN to for that particular machine.

I don't think a by-the-book installation of Slackware is going to
end up with anything like the abomination that RedHat has foisted
off on the unknowing.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

In comp.os.linux.misc Floyd Davidson <floyd@barrow.com> wrote:
SInce 2.0, you mean. And he's right.


Peter

In article <87r7zqky7z.fld@barrow.com>, Floyd Davidson wrote:

A lot of good advice; accurate, as always. But consider that the OP saw
all those messages from fetchmail without understanding them. A user at
that level has much learning to do. In the meantime he'll need to
receive mail. So I'd start him here:

but instead point him to this section:
-m <command> | --mda <command>
(Keyword: mda) You can force mail to be passed to
an MDA directly (rather than forwarded to port 25)
with the --mda or -m option. To avoid losing mail,
use this option only with MDAs like procmail ...

.... so he won't have to struggle with sendmail nor DNS (other than to
resolve the name of the pop3 server, which apparently works) right now.

The requisite .fetchmailrc line is this:
mda "/usr/bin/procmail -t -d $USER"
(probably substituting the local username for $USER; I am not sure.)
With this you don't get into the complexities of MTA spam filtering, but
you're still free to play with procmail filtering at your leisure.

Such difficulties as these in a user's early GNU/Linux days often lead
to frustration and burnout.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 <rob0@gmx.co.uk> wrote:
Too me, that looks more complex. :-)

He *has* to fix his DNS so that sendmail will work. That is
screwing up a lot more than sendmail. It appears that otherwise
sendmail is just fine, and with the addtion of a fairly simple
~/.fetchmailrc file, so is fetchmail.

Different strokes for different folks though.


--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

ptb@oboe.it.uc3m.es (P.T. Breuer) wrote:
Probably was. I use Slackware, but I've never used the default
networking configuration files. I've been writing my own since
SLS.

I think that I'd never looked at the default /etc/hosts file or
the /etc/rc.d/rc.inet* files until a couple years ago when
somebody said something to the effect that Slackware did (or
didn't) use the same stupid setup that RedHat and followers do,
and I went an looked at the source distribution and saw that.

Whatever, sometimes it's hard to convince people that 127.0.0.1
shouldn't have *anything* other than localhost associated with it.
But I'm always afraid to tell anyone with a RedHat system to do
it right, because I have no idea what RH munged to make that
work without problems.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

One other nitpick / question:

In article <87r7zqky7z.fld@barrow.com>, Floyd Davidson wrote:
IIUC a dummy interface is like a /dev/null for network packets. Packets
come in, but they don't go out. In contrast a loopback returns them.
They are analogous to celestial black holes and mirrors, respectively.
Is this understanding correct? It appears so:
#v+
/* dummy.c: a dummy net driver

The purpose of this driver is to provide a device to point a
route through, but not to actually transmit packets.
#v-
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

On Sun, 30 Nov 2003 08:54:42 -0800, /dev/rob0 <rob0@gmx.co.uk> wrote:
in my ~/.fetchmailrc it's:

and wants mda "/usr/bin/formail -ds /usr/bin/procmail"

You can specify a procmailrc by just listing it ...../bin/procmail filename"

AC

/dev/rob0 <rob0@gmx.co.uk> wrote:
But, as with any other network interface, if you use it as a loopback,
the actual packets go through the lo device. So while a dummy device
is only something to point a route at, if you do that you can use
it as a loopback.

/home/floyd/ >ifconfig dummy0
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
...

/home/floyd/ >telnet 192.168.3.1
Trying 192.168.3.1...
Connected to 192.168.3.1.
Escape character is '^]'.

tanana login: floyd
Password:
Last login: Sun Nov 30 13:29:06 -0900 2003 on pts/16 from dummylink.ukpeagvik.net.
~ >exit
logout
Connection closed by foreign host.

/home/floyd/ >grep dummy /etc/hosts
192.168.3.1 dummylink.ukpeagvik.net dummylink


All of the activity counts on the dummy0 device (snipped above for
brevity) remain at 0, and activity such as the above increases the
counts on the lo device.

It can be a fairly useful device to play with now and then.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com