[nos-bbs] FW: SMTP vs. traditional forwarding via a Gateway

[Michael Fox - N6MEF]

For anyone who didn't want to wade through all of the message below:

 

Is anyone running a network of JNOS systems behind a single machine that
does the forwarding to the rest of the BBS network?

 

If so, how are you handling the forwarding within your network?

 

a)  set up forward.bbs entries for each system in your local network and use
axudp interfaces or telnet?

b)  somehow use SMTP between the local systems.  If so, how?

c)  something else?

 

Thanks much,

Michael

N6MEF

 

 

From: Michael Fox - N6MEF [mailto:n6mef at mefox.org] 
Sent: Saturday, November 03, 2012 7:58 PM
To: TAPR xNOS Mailing List (nos-bbs at tapr.org)
Subject: SMTP vs. traditional forwarding via a Gateway

 

I've got a network of 4 BBSs that all exchange messages using SMTP.  One of
those BBSs is the AMPRnet gateway for the rest of them (well, the gateway is
on linux, but you get my meaning).  That machine also has an RF interface on
the local BBS forwarding network frequency.  So it will also be my gateway
machine to the traditional BBS forwarding network.

 

My question is about the best way to send mail from my non-gateway machines,
through the gateway, to the traditional BBS forwarding network.  Of course,
the return path needs to work as well.

 

Within my network, mail (non-bulletin messages) travels via SMTP.  As soon
as a message is created, it is sent to the destination.  The same is true
when sending messages out to BBSs on amprnet.  

 

But when the gateway machine has a message to send to the traditional BBS
network, the gateway's rewrite rules drop it in a local mailbox and then the
message is forwarded the next time "mbox timer" expires or "at mbox kick" is
used.  So I'm wondering how to configure the non-gateway machines that need
to send messages to the traditional BBS network.

 

One way, I suppose, is to have the non-gateway machines do the same thing
that the gateway machine does.  Specifically, drop mail addressed to the
traditional BBS network into a local mailbox and then, at the next
forwarding interval, forward it to the gateway machine, which will drop it
into a local mailbox and then, at the next forwarding interval, forward it
to the forwarding partner.  That's simple and straight forward.  But it
incurs two delays.  One delay is waiting for the next forwarding interval to
occur between the non-gateway machine and the gateway machine.  Then a
second delay occurs waiting for the next forwarding interval to occur
between the gateway machine and the forwarding partner.

 

(Note:  I realize, of course, that these hop-by-hop delays will occur all
along the forwarding path in the traditional BBS forwarding network.
Therefore, in the general case, one more hop delay is not a big deal.  But
in the case where most of the traffic will be going no more than one
forwarding hop away from the gateway machine, eliminating the second hop
cuts the time in half.  And since the majority of the use of our BBS system
is for ARES/RACES activity, it is desirable to reduce the delay as much as
possible.)

 

So, I'm wondering if a better way is to somehow cause the non-gateway
machines to use SMTP to get the message to the gateway machine, where it
could then be forwarded.  This would cause the mail to be sent right away
from the non-gateway machine to the gateway machine, eliminating one of the
delays.

 

I experimented with rewrite rules like:  user at bbs.#nca.ca.usa.noam
user%bbs.#nca.ca.usa.noam at gatewaybbs

 

This did, indeed, ship the message off to gatewaybbs right away via SMTP.
But it was rejected by the gatewaybbs JNOS machine saying relaying was not
allowed.  

 

So I'm wondering what others do that have this type of local network with a
gateway that can talk to the rest of the traditional BBS network.  Do you
just use the same forwarding method or do you do something more elegant to
get the message to the gateway via SMTP right away?

 

Thanks in advance,

Michael

N6MEF

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20121105/48ab5e6e/attachment.html>