21st Century and SMTP ??
Pretty wrong, so I think you don't know anything about H-Addressing.
First off, SMTP (email) is just like someones home phone number. If you
dial the wrong phone number, you either get the wrong house, or you get
none at all. Same with email. If you don't have the 100% correct email
address, the message doesn't get through at all, or winds up in the wrong
persons in-box.
With H-Addressing, YOU DON'T HAVE TO KNOW THE EXACT ADDRESS!
That's one of the many beautiful things about packet messaging forwarding.
Let me explain.... My packet address looks like this
KG6BAJ(a)KG6BAJ.#NCA.CA.USA.NOAM.
The ".#NCA.CA.USA.NOAM" is the Hierarchical part of the address. The
".#NCA"denotes SUBSECTION of the state (in this case Northern CAlifornia),
then the state "CAlifornia (.CA)", then the Country (.USA), then the
continent of North America (.NOAM).
With HAddressing, Someone really doesn't need to know the precise address
like you do with phone & email (The SMTP you refer too). Someone wants to
send me packet mail, they really only need just a part of my address, which
they could guess by running my callsign through something like QRZ. Someone
could send me a packet mail addressed to "KG6BAJ@.#USA.NOAM" (notice the
huge difference from KG6BAJ(a)KG6BAJ.#NCA.CA.USA.NOAM).
Properly configured NOS/FBB/Misc full service BBS's then can at least
determine that the message is intended for USA, in North America, and
forward the message along.
Since my BBS is in fact located within USA, in North America, then I'll get
the message, and drop it in the correct mailbox.
Try doing that with an SMTP (email) message. Just won't work.
To those who don't fully understand the brilliants of Hierarchical I
suppose it would seem antiquated. But nothing else gets that message
through like packet radio and H-Addressing.
And one another note, you state all NOS stations run SMTP. Also not true.
It depends on if the sysop has built it in at time of compiling it features.
And..... not all Full-Service BBS's run NOS.
Bill Lewis,
KG6BAJ
At 05:51 PM 7/10/2015, you wrote:
>Jerry, Are you talking about the BBS Hierarchical Addressing Protocol that
>is common with people running NOS BBS'es?
>ftp://ftp.tapr.org/bbssig/recommendations/hierarchical
>In all honesty from what I remember it's a lot of manual configuration,
>that really seems quaint to me since all the NOS programs also speak SMTP,
>the standard today.
>
>It would seem the same could be accomplished using SMTP standards by
>setting up some mail aliases. I'm going to recommend the TAPR NOS-BBS list
>for (Hierarchical forwarding) things of the non 21st century:
Jerry,
Are you talking about the BBS Hierarchical Addressing Protocol that is
common with people running NOS BBS'es?
ftp://ftp.tapr.org/bbssig/recommendations/hierarchical
In all honesty from what I remember it's a lot of manual
configuration, that really seems quaint to me since all the NOS
programs also speak SMTP, the standard today.
It would seem the same could be accomplished using SMTP standards by
setting up some mail aliases.
I'm going to recommend the TAPR NOS-BBS list for (Hierarchical
forwarding) things of the non 21st century:
https://www.tapr.org/mailman/listinfo/nos-bbs
---- Quote ----
Is there anything written on the operation of amper.org mail forwarding? We
routinely run h-address packet mail forwarding and I see some ampr.org mail
bulletins coming in from all over the world. I’m interested in the
addressing, routing, and just how does this mail forward. I run Ubuntu Linux
JNOS latest version.
Jerry, N0MR
Is there anything written on the operation of amper.org mail forwarding? We
routinely run h-address packet mail forwarding and I see some ampr.org mail
bulletins coming in from all over the world. I’m interested in the
addressing, routing, and just how does this mail forward. I run Ubuntu Linux
JNOS latest version.
Jerry, N0MR
"Loss of communications can only mean one thing... INVASION."
Sorry guys, someone had to say it ;-)
Assi kk7kx
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Paul
Lewis
Sent: Tuesday, July 07, 2015 9:11 AM
To: AMPRNet working group
Subject: Re: [44net] Is the Portal down
(Please trim inclusions from previous messages)
_______________________________________________
Hi Brian
Thanks for the confirmation that the services are down.
73 de Paul G4APL GB7CIP
--
paul(a)skywaves.demon.co.uk
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> Subject:
> [44net] Gateway filtering?
> From:
> Steve L <kb9mwr(a)gmail.com>
> Date:
> 07/03/2015 09:05 PM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> A few hosts behind my gateway want to accept general inbound internet
> connections.
>
> As discussed earlier there is a lot of crap and the gateway I run is
> off a residential internet connection. Combine that with some limited
> bandwidth radio links.
>
> I have been thinking about applying some IP blacklists using the ipset tool.
>
> ex:https://github.com/trick77/ipset-blacklist
>
> I am not super savvy on the more advanced functions of tcpip in the
> Linux networking stack.
>
> Since those in all the inbound packets from the internet are
> encapsulated at UCSD, how can I apply blacklisting? Can I apply them
> to the eth1 (wireless lan) output interface somehow?
>
> Examples are especially helpful.
>
> Thanks
>
> Steve, kb9mwr
>
I use this a lot in the Dutch gateway. First, I have an ipset that is loaded with the
list of allocated addresses within 44.137.0.0/16. You don't need to do that when you
are behind the UCSD gateway, but we have a BGP-advertised /16 so we get a lot of
crap for addresses that are not allocated.
Then, there is an ipset that is loaded with addresses of persistent abusers like shodan.io.
Finally, I have an ipset with those addresses for which the user has indicated that they
want to receive inbound connections from outside 44.0.0.0/8. This works in combination
with an iptables -m state --state ESTABLISHED,RELATED entry that passes the traffic
related to outgoing connections.
As a lot of hams are not interested in providing connectivity to the large internet, this filter
removes a lot of incoming traffic that would otherwise be blocked further down the path.
(at their incoming firewall)
The use of these ipset filters in the firewall is quite simple:
# Drop traffic from abusers
$ipt -A amprifwd -m set --match-set Hackers src -j DROP
# Drop traffic for addresses not registered in DNS
$ipt -A amprifwd -m set ! --match-set PAnet dst -j DROP
# Allow related traffic
$ipt -A amprifwd -m state --state ESTABLISHED,RELATED -j ACCEPT
# Drop traffic to stations that don't want incoming from internet to HAMnet
$ipt -A amprifwd ! -s 44.0.0.0/8 -m set ! --match-set HAMnet dst -j DROP
# Drop invalid traffic (not related to existing connections) except TCP close-down traffic
$ipt -A amprifwd -p tcp --tcp-flags ACK,FIN ACK,FIN -j ACCEPT
$ipt -A amprifwd -p tcp --tcp-flags RST RST -j ACCEPT
$ipt -A amprifwd -m state --state INVALID -j DROP
# Accept remaining traffic
$ipt -A amprifwd -j ACCEPT
Of course you need to apply this filter to the FORWARD chain for traffic incoming on your
tunnel interface and being forwarded to your radio interface.
You can write such a filter (without the ESTABLISHED,RELATED part) for traffic forwarded
outbound as well. E.g. to block traffic from nonregistered addresses.
When loading the ipsets, it is important to note that you cannot delete a set that is in use in
iptables. So I use this method (in a script that reloads the sets e.g. after an address update):
ipset create HAMnet bitmap:ip range 44.137.0.0/16 2>/dev/null
ipset create HAMnet_new bitmap:ip range 44.137.0.0/16
ipset flush HAMnet_new
grep '^44\.137\.' hamnet | cut -f1 | while read ip
do
ipset add HAMnet_new $ip || echo "Failed to insert $ip in HAMnet_new"
done
ipset swap HAMnet_new HAMnet
ipset destroy HAMnet_new 2>/dev/null
This creates a new set, loads it with the data, then swaps it with the currently used set and
destroys that one. This operation is allowed while the set is in use, and of course is preferred
over just flushing the set and loading it, as during that brief time the filter could drop traffic.
Rob
A few hosts behind my gateway want to accept general inbound internet
connections.
As discussed earlier there is a lot of crap and the gateway I run is
off a residential internet connection. Combine that with some limited
bandwidth radio links.
I have been thinking about applying some IP blacklists using the ipset tool.
ex: https://github.com/trick77/ipset-blacklist
I am not super savvy on the more advanced functions of tcpip in the
Linux networking stack.
Since those in all the inbound packets from the internet are
encapsulated at UCSD, how can I apply blacklisting? Can I apply them
to the eth1 (wireless lan) output interface somehow?
Examples are especially helpful.
Thanks
Steve, kb9mwr
I am trying to register amprnet gate at IP 147.229.242.130 (ok0nmg.ddns.net)
at portal.ampr.org but there is no offer to put a subnet (here
44.177.10.254/32).
I ahve already registered 2 gateways before succesfully with their
subnets but
this a/m one its not possible to put a subnet.
(The ampr-ripd system is running well on ok0nmg.ddns.net.)
I need some help please.
Best 73
Libor OK2PEN (PY2ZEN) sysop of gates ok2koj.ampr.org, ok2pen.ampr.org
and ok0nmg.ampr.org
All,
I've added a new tool that I'd like you to test. This web application
should provide the registration code required by APRS software suites.
In order to use it, you must browse to:
http://kb3vwg-010.ampr.org/tools/aprscode
or
http://44.60.44.10/tools/aprscode
If you're on AMPRNet, you should be able to enter the callsign and look
up the registration code. If you access it from outside of AMPRNet, you
will be prompted for an access code (1234).
Please let me know how it works
73,
KB3VWG