Shawn, here's the problem with heber currently. The prefered MX record
(the one with the LOWEST preference (10) *is* heber.ampr.org ... which is not
directly connected to the internet, so naturally an smtp transport must
time out on it. The next highest preference is your
machine,electron.kb7pwd.ampr.org (20) which also is unavailable from the
internet.
The ampr.org dns needs to be updated to reflect an mx record that can
be attached to by the internet world (for incoming email destined for
heber) with an ip address that *can* be attached to (on port 25 of course).
If electron.kb7pwd.ampr.org has an address on the side that is connected to an
ISP then you need to update the mx record for heber.ampr.org to point to
that address. I can supply more info on how to do that if needed.
Here's some potentially useful info.
On a box that has nslookup and is directly connected to the internet ...
$ nslookup
> set q=ns
>ampr.org
Server: rudolph.scinetinc.com
Address: 12.9.6.2
Non-authoritative answer:
ampr.org nameserver = haig.cs.ucl.ac.uk
ampr.org nameserver = munnari.OZ.AU
ampr.org nameserver = dns.iarc.org
ampr.org nameserver = hamradio.ucsd.edu
ampr.org nameserver = ns1.nosc.mil
Authoritative answers can be found from:
haig.cs.ucl.ac.uk internet address = 128.16.6.8
munnari.OZ.AU internet address = 128.250.1.21
dns.iarc.org internet address = 194.90.246.5
hamradio.ucsd.edu internet address = 132.239.1.144
ns1.nosc.mil internet address = 128.49.16.7
>server ns1.nosc.mil
Default Server: ns1.nosc.mil
Address: 128.49.16.7
>ls ampr.org > ampr.txt
> ls ampr.org > ampr.txt
[ns1.nosc.mil]
################################################################################
################################################################################
...
Cntrl-d out of nslookup, then edit ampr.org to look the domain info over.
Look at the various MX records for other gateways. You'll see that many of them
point to machines on the internet that are part of other domains. Those are
the gateways. The MX record needs to be set up in the same fashion for
internet email to be routed to a gateway machine that knows how to get to
heber via a radio path. And it must have the lowest preference.
Outgoimg email is as ve7hex described. Please contact me directly if
you have more questions ... as you probably already know I have
personal reasons for getting an email gateway for heber back up ;)
73
At 10:39 PM 4/30/00 -0700, you wrote:
>On Thu, Apr 27, 2000 at 03:09:54PM -0700, Shawn T. Rutledge wrote:
>> What MX records don't help with very much, is what happens if some
>> arbitrary ampr.org system in rural New Jersey tries to send a message to
>> heber. The NJ system would try to connect directly, which is pretty
>> fruitless on plain packet, since we don't really have a nationwide
>> network here. Maybe there would be a useful gateway that could help
>> out, so maybe it would work; but most likely not. Now maybe there's a
>> big fancy gateway somewhere in New York. The operator there probably
>> knows about his New Jersey neighbor and there are probably MX records
>> going both ways so that the NJ system can get stuff to and from the
>> Internet via the New York system. But those don't help one iota to
>> get mail to heber. In order for the Internet to help, short of just
>> providing a handy IPIP wormhole, heber would have to have listed an
>> MX record for itself, specifying that the ny.ampr.org is a possible
>> mail exchanger. Now why would he do that? It makes about as much
>> sense to have an MX record for a system in Timbuktoo. If every possible
>> mail exchanger worldwide got listed, it'd take forever for mail to
>> get delivered as sendmail tries them in sequence, with no way to even
>> take a guess as to which one is likely to work. Seems to me the whole
>> MX scheme doesn't scale well on this kind of network. There should
>> be much more store-and-forward going on; but the Internet protocols
>> usually assume that an end-to-end real-time conversation is possible,
>> and it just isn't. I don't know what the solution to this problem
>> is, or if it's even in the scope of SMTP as we know it.
>>
>
>Not sure I really understand your problem here ... just forward outgoing
>mail to a friendly relay host on the internet, and assume that other ampr.org
>hosts will designate a relatively local MX exchange host for themselves.
>Mail goes from your system to the internet, through it to the destination
>MX exchanger, then on to the final destination host when conditions allow.
>For an all amateur route for those hosts that you know can be connected to,
>specific routes can be setup in a mailertable.
>
>What I'm still working on is getting ETRN to work better ... seems like
>I can establish a connection to my MX host, request a dump of the queue
>for me, and it still seems to wait for the queue reprocessing timeout
>before sending it on. Also would be nice to avoid fruitless retrys when
>the link is down by _only_ sending on a ETRN request, any tips appreciated.
>
> ... Niall (VE7HEX)
>
>
--
-= Brad Fisher =- (PPSEL) I'm just
internet: [EMAIL PROTECTED] a
packet: [EMAIL PROTECTED] wanna be
http://www.scinetinc.com/~bradf/ UNIX guru!
