On Thu, Apr 27, 2000 at 04:33:45PM -0400, Bruno Quesnel wrote:
> Then the BBS machine is actually accessible throught the RF link
> from both of the gateways. My question would be how to get the email
> coming from the internet to the users on that BBS machine using any of
> the two machine that has access to the net .
>
> Would MX record solve the problem with one being the backup to the
> other ? Then what would ressemble the sendmail.cf config file and other
> files related to ?
I don't understand yet how to connect BBS mail with SMTP mail; depends
on whether the BBS can already handle SMTP I guess. However my system
is successfully gatewaying SMTP mail to and from local NOS systems now,
and I'm using sendmail to do it. The NOS operators are having to use
some kind of rewrite mechanism for outgoing mail; if an email address
specifies an internet machine, then it rewrites the "to" address into
the form
[EMAIL PROTECTED]
and NOS will then make an SMTP connection to my sendmail. Sendmail
decapsulates the "to" address and ends up with [EMAIL PROTECTED], and forwards
it directly to isp.com. I don't think MX records are involved for this
part because the routing is explicit.
Now from my perspective, if my sendmail receives a mail destined for
an ampr.org address, it doesn't care that it's a packet machine, it
just tries to open up a TCP connection directly to the destination
machine and use SMTP to transfer it. There are some "impedance
mismatches" - for one the NOS implementation of SMTP is different;
it doesn't support ESMTP, and it does support an LZW compressed format
which sendmail does not. And I keep getting these errors about
the MAIL line being missing; somehow it saw the RCPT line before the
MAIL line, and didn't like it. And the whole thing is slow as
molasses in January because it's going across so many hops; pings
take multiple seconds, too. So usually some commands fail, and then it
retries, and eventually the mail gets through.
MX records can help with which system to route mail through. For instance
heber.ampr.org is one machine that is making use of my gateway; here's
its MX records:
heber.ampr.org preference = 30, mail exchanger = 24.1.227.2.ampr.org
heber.ampr.org preference = 10, mail exchanger = heber.ampr.org
heber.ampr.org preference = 20, mail exchanger = electron.kb7pwd.ampr.org
So this tells other systems that to deliver mail there, first try heber
itself; if that fails, try my ampr.org address (in case my machine is
closer, less hops will result in less failures); and if the sender is
on the internet, then both of those will fail and it will fall back on
my Internet IP address. (And he did that wrong didn't he...
forgot to append the trailing dot, so the UCSD robot assumed it
was an ampr.org address. I'll have to tell him about that. Could
explain some errors I've seen in my logs, too. That first line
should say 24.1.227.2. without the ampr.org suffix.)
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.
--
_______ Shawn T. Rutledge / KB7PWD [EMAIL PROTECTED]
(_ | |_) http://www.bigfoot.com/~ecloud [EMAIL PROTECTED]
__) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903
