informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
master
textfiles/internet/FAQ/amiuucp1.faq
T
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

663 lines
28 KiB
Plaintext
Raw Permalink Blame History

X-NEWS: ids alt.sys.amiga.uucp: 909
Path: paperboy.ids.net!uunet!tymix.Tymnet.COM!tardis!olivea!spool.mu.edu!howland.reston.ans.net!xlink.net!fauern!imp.ch!alphanet.ch!uucpfaq
From: uucpfaq@satcom.alphanet.ch (UUCP Faq Handler)
Newsgroups: alt.sys.amiga.uucp,alt.answers,news.answers
Subject: alt.sys.amiga.uucp Frequently Asked Questions (FAQ 1/2) - AmigaUUCP general information
Summary: AmigaUUCP installation, utilities and common problems.
Message-ID: <CH7J0A.vn@satcom.alphanet.ch>
Date: 28 Nov 93 15:00:09 GMT
Expires: Wed, 5 Jan 1994 08:00:00 GMT
Sender: UUCP-Faq@alphanet.ch (UUCP-Faq handler)
Reply-To: UUCP-Faq@alphanet.ch
Followup-To: alt.sys.amiga.uucp
Organization: ALPHANET NF, Colombier (NE) - Switzerland
Lines: 644
Approved: news-answers-request@MIT.Edu
Comment: This is an automated monthly posting, part 1 of 2.
Xref: paperboy.ids.net alt.sys.amiga.uucp:909 alt.answers:657 news.answers:4235
Archive-name: amiga/AmigaUUCP-FAQ/part1
AMIGA-UUCP-FAQ version 2.A.2 [Posting 18]
MONTHLY POSTING, last update 02 August 1993
This FAQ is posted monthly (28th of month)
author: Marc SCHAEFER, <schaefer@alphanet.ch>
Bugs, typos, ideas to <UUCP-Faq@alphanet.ch>
("ch" stands for Switzerland)
NOTE: The primary goal for this FAQ is to prevent questions from
looping over and over. If you have new and interesting material, post
it to alt.sys.amiga.uucp with "Addition to FAQ" somewhere in the
subject. I will add it for the next "release". You may also send any
ideas, changes, flames, typos to the address UUCP-Faq@alphanet.ch.
They will be incorporated in the next release with your name in the
CHANGES section as a reward :-)
NOTE TO UUCP-BEGINNERS: Please take some of your time and READ the UUCP
documentation. Most of the questions posted on a.s.a.u are related to
manual pages. This FAQ contains also some information on common problems
and utilities. Don't forget to get the FAQS from news.announce.newusers.
You may also read UUMAN:Standards (for UUCP internals) and UUMAN:how2usenet.
CHANGES FROM ORIGINAL MATT DILLON'S FAQ ARE NOTED WITH A (*).
To skip to a topic, search for the roman numeral surrounded by
parenthesis. For example, (I).
FAQ.1 (this file)
(*) 0. Changes from last posting
(*) I. Introduction to alt.sys.amiga.uucp[.patches]
II. Introduction to AmigaUUCP
(*) III. Principal utilities
IV. Constructing mail addresses
V. Using DCRON
VI. US domain clarification
FAQ.2 (a different post)
(*) VII. Common problems (new, please submit things to go in here).
VIII. Using SENDMAIL directly.
(*) IX. Other UUCP utilities.
(*) X. How to get UUCP stuff ?
(*) XI. BBS software supporting UUCP.
(*) XII. Other UUCP implementations for AmigaOS.
(*) XIII. Unresolved topics.
(0) RECENT CHANGES TO THIS FILE
Changes since 28-October-93 are listed below [Last posting was posting 17]
None
(I) INTRODUCTION TO ALT.SYS.AMIGA.UUCP[.PATCHES]
(1) Configuration
ALT.SYS.AMIGA.UUCP and ALT.SYS.AMIGA.UUCP.PATCHES are two newsgroups
dedicated to the UUCP system for the Amiga microcomputer, AmigaUUCP.
Both news groups are gatewayed to two mailing lists containing
additional recipients who would otherwise not have access to the ALT
groups. That is, posting to an alt group will automatically relay to
the appropriate mailing list, and mailing to the mailing will
automatically relay to the alt group.
If you do not have ALT group access and are not on the mailing list,
and would like to be on the mailing list, send your request to:
amiga-uucp-request@idiom.berkeley.ca.us and/or
amiga-uucp-patches-request@idiom.berkeley.ca.us
To get off the mailing list, you can send your request to either
address. Matt Dillon manually reads this alias. Note that you must provide a
proper return address as part of your signature if you are a UUCP node
so he can properly format your return address. If you are on the
internet (i.e. have a fully domained address), it isn't a problem.
TO POST ARTICLES VIA THE MAILING LIST, send email containing your
posting to either of the following two addresses:
amiga-uucp@idiom.berkeley.ca.us
amiga-uucp-patches@idiom.berkeley.ca.us
Sending email to either address causes it to be automatically posted to
the alt.sys.amiga.uucp[.patches] newsgroup. You do not have to be on
the mailing list to be able to post via the list.
Report any problems to:
amiga-uucp-owner@idiom.berkeley.ca.us
amiga-uucp-patches-owner@idiom.berkeley.ca.us
(2) Usage Of
[Note: Original author is Matt Dillon. See next comment]
The purpose of alt.sys.amiga.uucp is to convey the bulk of any
discussion relating to AmigaUUCP. Discussion, bug reports, questions,
etc...
The purpose of alt.sys.amiga.uucp.patches is for the posting of any
source code, scripts, or binaries relating to AmigaUUCP. Full
distributions will NEVER be sent over alt.sys.amiga.uucp.patches.
Anybody may post to alt.sys.amiga.uucp.patches and, in fact, it is best
that any code you wish to submit to be merged into the master
distribution that Matt Dillon keep be submitted to this newsgroup instead of to
me personally.
This will allow anybody to pick off the code and immediately implement
it on their own system without waiting for the next master distribution.
Matt Dillon will also use alt.sys.amiga.uucp.patches to post updates to the
current master distribution, generally small to medium sized SHAR
or uuencoded LHARC files. Matt Dillon personally would like to get a system
together so multiple-source postings can be archived in a text form
instead of a uuencoded form because all netnews is compressed anyway,
and compressing uuencoded lharc files generally makes the result larger
than the original instead of smaller.
(3) BUG / ENHANCEMENT REPORTS
[Note that the following text author is considered to be the
current UUCP source maintainer which seems to be Michael B. Smith,
mbs@adastra.cvl.va.us]
The alt.sys.amiga.uucp and alt.sys.amiga.uucp.patches groups are fed
through a filter when they reach my machine, and any bug or enhancement
reports of a specific format will be automatically extracted and
appended to my TODO file.
To issue a bug report or enhancement request, use the following format:
##B unique-id
<bug report goes here>
##
Note that there are TWO '#'s. ##B stands for a bug report, ##E stands
for an enhancement request. WARNING! The ##'s must begin a line, you
CANNOT PRECEDE ## WITH WHITESPACE. Doing so will result in the filter
passing the report by. For example, the ##B/## lines in the example
above, not being flush with the left margin, will be ignored by my
filter program.
The unique-id should be a unique identifier for your bug report, for
example, I might use '##B dillon.23'. Do NOT encode the date in
the unique ID because my filter program will automatically extract
the Date: and From: fields from the news message header. Matt Dillon will
use the ID when refering to previous bug reports rather than posting
the whole bug report.
(4) This FAQ sheet
If you have information you think would be useful on this FAQ sheet,
please submit it to UUCP-Faq@alphanet.ch.
(II) INTRODUCTION TO AmigaUUCP
This section consists of a brief introduction to AmigaUUCP. It is not
meant to describe installation of the distribution. Installation of
the distribution is more involved and best served by the instructions
that come with the distribution.
AmigaUUCP was originally derived from GNU-UUCP and UUPC (was UUPC
derived from GNU? I dunno). This was several years ago. It
eventually fell into William Loftus's hands who molded it into a
workable system for the Amiga. From there, about a year later, it fell
into my hands and has since remained.
What little GNU/UUPC code remains is in uucico, and even that is
rapidly disappearing. AmigaUUCP is now almost entirely made up of code
written after the original port to the Amiga. At this point, there is
no comparison at all between the older GNU/UUPC stuff and the state of
the art AmigaUUCP distribution.
AmigaUUCP is a public domain project, though not properly in the public
domain because all authors involved have maintained copyrights on the
code. legally, this may not mean much, but it does give us a sense of
security and more control over what is done with the code. Be that as
it may, the entire distribution, source and all, is available to
anybody who wants it. There are about a dozen principal authors and a
few dozen contributors, not to mention the hundreds of people who have
sent in helpful suggestions and bug reportrs.
What is AmigaUUCP? Well, if you are reading this article then you have
some idea how EMAIL and NETNEWS works ... AmigaUUCP is a set of
utilities and documentation to implement an EMAIL/NETNEWS link directly
on your amiga. All you need to do is find what is known as a 'feed'
site who is willing to give you a UUCP connection, and, of course, a
modem with which to communicate with that feed.
(III) PRINCIPAL UTILITIES
AmigaUUCP is made up of a plethora of utilities. Many of the utilities
mimic their UNIX counterparts but it should be noted that none are
really based on actual UNIX C code except for those sections still
existing from the original GNU/UUPC port.
Only the major utilities are listed below:
UUCico
UUCico is the workhorse of the system. It calls your feed site
via the modem and transfers both outgoing and incoming mail and
news. This mail and news will have been previously stored by
you or your feed site.
It has been updated a lot, mainly for reliability reasons. Last
version is uucico_sd3.lha.
Getty
Getty handles incoming calls. It allows remote login (interactive
and uucico logins).
Sendmail/RMail
Sendmail/RMail is the workhorse of the MAIL subsystem. The two
utilities are actually the same executable just renamed and I
will refer to them collectively as 'sendmail' from now on.
Sendmail handles incoming mail, breaking it apart and sending it
to the appropriate mailbox, or re-queueing it if it is simply
passing through your system to another system down the line.
Sendmail deals with any aliases you might have defined and also
with any domains you have defined for routing email.
Sendmail also handles, under the aegis of 'rmail', all incoming
mail.
RNews
RNews handles all incoming news, including local news you send
out. It breaks apart compressed batches and creates an individual
file for each article in the UUNEWS: directory. It also creates
a directory for each newsgroup. A lot of patches have been made
to increase reliability, and speed.
BatchNews
Batchnews compresses and batches any news you have sent posted into
a single batch file, making its transfer to your feed that much
more efficient. Read the Newssetup.doc in the distribution for
more information on how to set up news.
DMail
DMail is the amiga's mail shell. It scans your mail box and
presents mail in an orderly fashion, allowing you to reply to
the mail and do other operations.
DNews
DNews is the amiga's news reader. It is not quite as sophisticated
as RN but is getting there. It sports an intuition windowing
system to make it easy to scan through news.
UUcp
UUcp (the command) can be used to copy files from your local system
to some of your neighbours. Note that the way it is implemented on
the AmigaUUCP system is a little different than in Unix. In Unix, as
soon as the uucp command has been executed, a copy of the implied file
is done in a data file in the spool directory. Then uucico copies it
to the other unix system that extracts the file from the data file.
In AmigaUUCP, if sending the file is only read while UUCico is online,
and that explains why if you UUCP a file which path is NOT authorized in
the UULIB:Security file, there will be an error while online. This prevents
the ability to forward the file to another host. However most of the time
in UNIX, uucp is very restricted. AmigaUUCP does not allow directory-deep
file send.
For sending to a far site, BMS is more convenient.
(IV) CONSTRUCTING MAIL ADDRESSES
(1) GENERAL
Unfortunately, the internet mail system is made up of a huge number
of nearly incompatible networks. Mail addresses are constructed
with various types of punctuation that mean various things .. indeed,
some punctuation means one thing in one domain and another in another
domain. I have found that the absolute best way to construct a mail
address is either with the '@' format or with a '!' path.
If your feed is a 'smart' host, any fully domained mail address can
be replied to with simply:
user@fubar.subdomain.subdomain....domain
dillon@overload.Berkeley.CA.US
Any address with dots in it is called a fully domained address.
Unfortunately, there are a few exceptions... any address ending
with .UUCP is *NOT* I repeat, *NOT* a domained address... it's
a hack that some sendmails will add to properly route the mail
internally. This hack generally extends to the From: field of
an email message, and AmigaUUCP will do this, but not being a
domain, you cannot SPECIFY a .UUCP trailer in the To: address.
For example, my UUCP address is:
uunet.uu.net!overload
Note that there is NO .UUCP specification tacked on to overload.
Note also that when you specify your UUCP address in your
signature you should start with a fully domained machine name,
*not* one ending with .UUCP.
On other fronts, some unexperienced administrators will give their
machines a full domain name without properly registering it. If
you have not registered your domain with the proper authorities,
DO NOT GIVE YOUR MACHINE A FULL DOMAIN.
For example, when I first connected to my feed, which is uunet, I did
not have a .US domain and so my machine name was simply 'overload'.
After I registered in the .US domain I changed my machine name to its
registered equivalent, 'overload.Berkeley.CA.US'.
(2) BANG PATHS
Nearly all the systems on the internet accept what are known as
bang paths. There are only a few exceptions. One of the design
decisions for AmigaUUCP was to convert all addresses into bang
paths before sending them out. There have been one or two sites
(so far) that have been unable to run AmigaUUCP because the feed
they picked was running news software so old it did not recognize
bang paths. To those sites I say: find a different feed, AmigaUUCP
would become extremely messy were I to implement UNIX sendmail style
address parsing.
A bang path work by specifying the exact path your mail is to go along,
in the following format:
first_machine!machine!machine!users_machine!user
Any machine name in the path may be a fully domained name. If you have
a smart feed it will be able to optimize the path accordingly. For
example, the bang path to me would normally be:
uunet.uu.net!overload!dillon
If your feed has a STUPID mailer, it may be necessary to use a bang
path to get *past* your feed to a nearby site that has a SMART
mailer. For example, lets say your feed is named 'fubar' and has
a dumb mailer. Let us also say that the feed has a UUCP connection
to 'harvard' which just happens to have a smart mailer. To get your
message to me you might use:
fubar!harvard!uunet.uu.net!overload!dillon
your feed may or may not accept harvard's fully domained name, which is
harvard.harvard.edu, it depends on how stupid your feed's mail system
is. If it does, it makes more sense to use:
fubar!harvard.harvard.edu!uunet.uu.net!overload!dillon
(3) INTERNET DOMAINS VERSES UUCP MAP ENTRIES
The internet domain system is based on domain servers, real time
servers residing on known machines that know all the machines in a
particular domain and how to get to them. When you send mail through
an internet machine, like this (assuming you have a UUCP connection
to UUNET):
uunet!caps.ibm.com!user
uunet (actually uunet.uu.net) will talk to the domain server for the
.COM domain to find caps.ibm.com (a name I made up).
UUCP works differently. While the internet is a real time network,
UUCP is a batch network. UUCP has what is known as a MAP entry for
every UUCP site that submits one. If you are a new UUCP site just
connected to your feed, you should send a MAP entry to the appropriate
administrator. A MAP entry is *NOT* a domain entry.
The UUCP MAPS are used by machines on the USENET to find other machines
on the USENET without the aid of domains. Not all machines on the
USENET use MAPS to find some destination. uunet.uu.net does, so here
is an example. I can send email from overload to (again, a made up
name):
uunet.uu.net!fubar!user
Even if uunet does not talk directly to fubar.. assuming fubar has
a MAP entry. uunet will search its maps to find the best path to
reach fubar, and then route the mail accordingly. The actual route
that uunet constructs might be: mcsun!gab!fubar!user
If your feed is a machine that does NOT use maps, then you must
specify an explicit bang path to get past your feed to a site
that does. For example, lets say your feed is named 'char00'
and has a dumb mailer, but connects to harvard.harvard.edu via
UUCP. You want to email me. you can do it in two ways:
char00!harvard!uunet.uu.net!overload!dillon.
or
char00!harvard!overload.Berkeley.CA.US!dillon
But, since your mailer is dumb, you would not be able to use:
char00!overload.Berkeley.CA.US!dillon
If, on the otherhand, char00 is a SMART USENET mailer that uses the
USENET MAPS (but still isn't on the internet itself), you can use:
char00!overload!dillon
Finally, if char00 is on the INTERNET, you can use:
char00!overload.Berkeley.CA.US!dillon
(4) WHEN ALL ELSE FAILS - BOUNCED EMAIL
email will bounce for a variety of reasons. The fact that the
global email system is made up of so many different types of mail
systems causes lots of havoc... in many cases a system will munge
the path you attempt to send email through by misinterpreting it
or by attempting to 'optimize' it.
When all else fails, and your attempt to reply to a piece of email
bounces, you may have to construct the return address by hand. Several
possibilities come to mind. You want to use the 'h' command from dmail
to look at the actual mail headers (use dmail's help command to get
full info on the header command).
You want to look at both the original message that was sent to you,
and the headers of your BOUNCED reply.
-------- SAMPLE OF ORIGINAL MESSAGE -------
From uunet!SASK.USask.CA!telepro!oliphant Fri, 28 Dec 90 13:04:57 PST
Received: by overload.Berkeley.CA.US (V1.07/Amiga)
id AA00000; Fri, 28 Dec 90 13:04:57 PST
Received: from sask.usask.ca by uunet.UU.NET (5.61/1.14) with SMTP
id AA22874; Fri, 28 Dec 90 01:30:48 -0500
Received: from herald.USask.Ca by SASK.USask.CA with PMDF#10255; Fri, 28 Dec
1990 00:30 CST
Received: by herald.USask.Ca (5.57/GLH-1.0); Fri, 28 Dec 90 00:30:06 -0600 id
AA01058 for amiga-uucp-patches-request@overload.berkeley.ca.us
Received: by telepro.UUCP (1.05D/Amiga) id AA04612; Thu, 27 Dec 90 21:25:00 CST
Date: Thu, 27 Dec 90 21:25:00 CST
Message-Id: <9012280325.AA04612@telepro.UUCP>
X-Envelope-To: amiga-uucp-patches-request@overload.berkeley.ca.us
From: uunet!SASK.USask.CA!telepro!oliphant (Mike Oliphant)
To: amyuucp@sask.usask.ca
Subject: Mailing list
Please add me to amiga-uucp-patches.
Thanks.
--
Mike Oliphant UUCP: alberta!herald!telepro!oliphant
Internet: oliphant@telepro.uucp
-------- ADDRESS I SENT MY RESPONSE TO ------
uunet!SASK.USask.CA!telepro!oliphant
-------- SAMPLE OF BOUNCE THAT CAME BACK TO ME -------
From uunet!sask.usask.ca!postmaster Mon, 31 Dec 90 01:02:30 PST
Received: by overload.Berkeley.CA.US (V1.07/Amiga)
id AA00000; Mon, 31 Dec 90 01:02:30 PST
Received: from sask.usask.ca by uunet.UU.NET (5.61/1.14) with SMTP
id AA13985; Sat, 29 Dec 90 17:18:48 -0500
Date: Sat, 29 Dec 1990 16:18 CST
Message-Id: <B13C1C282040350C@SASK.USask.CA>
X-Envelope-To: overload!dillon@uunet.UU.NET
From: PMDF Mail Server <uunet!sask.usask.ca!Postmaster>
To: overload!dillon
Subject: Undeliverable mail: local delivery failure
The message could not be delivered to:
Addressee: telepro!oliphant
Reason:
%MAIL-E-LOGLINK, error creating network link to node TELEPRO
-SYSTEM-F-NOSUCHNODE, remote node is unknown
-------- END OF SAMPLE HEADERS --------------------
So, why did my response fail? First, I have to tell you something
about mail headers: Except for Received: headers, intervening
systems can and will turn the standard headers into mush. That is,
the 'From ' encapsulation, the From: header, the To: header, even
the Reply-To: header might be modified by an intervening system.
There are only two things that are not mushed. They are the Received:
headers and the mail message itself - which might contain the sender's
signature at the end. This is a good reason to always put your email
address in your signature, and always base it at a known internet node
so anybody can figure out how to get back to you.
A Received: header is PREPENDED by *EVERY* site a piece of email goes
through, and is NEVER modified by any other site. These headers tell
you *exactly* how the mail was routed.
If you look at the original message, you will note that one of
the machines, probably SASK.USask.CA, modified the From: line in
an attempt to optimize it:
From: uunet!SASK.USask.CA!telepro!oliphant (Mike Oliphant)
Note that, by the From: line, SASK.USask.CA talks directly to
telepro. The 'From ' encapsulation was also modified, and there is
no Reply-To: header.
When I sent my reply to SASK using From:, the mail bounced because
SASK was unable to find telepro ... if you look at the Received:
lines you can see why ... because telepro talked to Herald before
getting to Sask. It is amusing because SASK is probably the node
that ripped out Herald's name in the From: and 'From ' lines in
the first place.
Also, take a look at Mike's signature line:
Mike Oliphant UUCP: alberta!herald!telepro!oliphant
Internet: oliphant@telepro.uucp
Interesting, eh? The Internet: address is actually wrong (sorry Mike!)
using .UUCP is not legal because it is not a proper domain. However,
if you forward through an internet host that also uses the UUCP MAPS,
and assuming mike is in the maps, the address *will* work.
It's the first address that confirms our fears... mike shows telepro
talking to herald. This combined with the knowledge we gained from
the Received: lines tells us that the path:
SASK.USask.CA!herald!telepro!oliphant
Will work as a return address. When in doubt, trace the Received:
headers to determine the return path.
Sometimes a UUCP MAP entry will be incorrect, in which case using
the Received: headers will be the ONLY way to reply to a message.
There are some situations which are impossible to reply to ... if
a message goes through a broken node that allows it to be propogated
one way but not the other, even using the headers will not work.
Also, some sites will attempt to optimize the path you specified. If
SASK.USask.CA were to optimize the path:
SASK.USask.CA!herald!telepro!oliphant
To
SASK.USask.CA!telepro!oliphant
Before processing, the mail could fail due to SASK.USask.CA breaking
itself. There are many nodes, especially gateways between networks,
that are broken in this manner and there will be times when you will
not be able to reply at all.
(V) USING DCRON
Many AmigaUUCP users leave their machines on 24 hours a day. With the
advent of 2.0, and assuming the serial.device gets fixed, you can
conceivably run your Amiga 24 hours a day under a heavy load for weeks
without a crash.
DCron is a program that runs in the background and executes other
programs at intervals defined in S:CRONTAB. It is quite flexible..
you can run a program or script at specific times of day, every X
minutes, only on certain days of the week, or even only in certain
months! I will not discuss the actual format, that can be looked
up in UUMAN:DCron.
There are two reasons to run DCron:
(1) Maintenance.
(2) Automatic polling. If you call a system on a regular basis and
want to automate the process, you can run UUCico from DCron at
specific times of the day.
First maintenance. Programs like UUCico, Getty, DCron itself, and
sendmail generate log files which, if left alone, would eventually fill
up your disk. Also, if you are receiving NEWS, you need to delete
expired articles. Due to the volume of news, not deleting old articles
can fill up your HD very quickly.
The TRIMFILES utility trims log files to a specified number of lines,
default 100. I normally run TRIMFILES on the various log files
once a day early in the morning. The S:CRONTAB entry I use is:
# trim log files at 3:01 A.M.
1 3 * * * uucp:c/trimfile tmp:dcron.log uu:spool/logfile getty:logfile
Note that the file paths will be somewhat different for your system.
Second, keeping your UUNEWS: directory reasonable. The TRIMNEWS
utility will handle this. TRIMNEWS scans your UULIB:Newsgroups file
for the list of newsgroups, then scans each news group deleting
articles over N days old, where N is specified in the Newsgroups file.
A sample NewsGroups file might be:
comp.sys.amiga 7
comp.sys.amiga.tech 7
comp.sys.amiga.programmer 7
comp.sys.amiga.announce 7
alt.sys.amiga.uucp 14
alt.sys.amiga.uucp.patches 30
Which essentially tells TRIMNEWS to delete all articles in
comp.sys.amiga.* over 7 days old (7 days from reception), to delete all
articles in alt.sys.amiga.uucp over 14 days old, and to delete all
articles in alt.sys.amiga.uucp.patches over 30 days old.
I normally run TRIMNEWS in the morning too, my S:CRONTAB file has:
# run TRIMNEWS at 3:06 A.M.
6 3 * * * uucp:c/trimnews
---
DCRON is also useful to control the modem configuration. You can run
the Getty utility from DCron to turn off the modem speaker while you
are asleep. I use DCRON for other things as well, such as to
automatically revise UUNET's amiga-uucp[-patchces] mailing list
whenever I make a local change, and to backup my hard disk. I also use
it to post this sheet once a month.
(VI) .US DOMAIN CLARIFICATION
This is a clarification to the information on registering in a
.US domain. It turns out that you can register in the .US
domain even if your 'feed' node is NOT on the internet. What
you need to do is find some node that IS on the internet that
is willing to be an MX FORWARDER to your machine (via a path).
This might prove difficult, but it is possible.
END OF FAQ PART 1.
Reference in New Issue View Git Blame Copy Permalink