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)
