[aprssig] APRS message-handling algorithms / libraries

[Gregg Wonderly]

Back in 2001-2003, I worked on a Java APRS application framework called JeAPRS.   The project is out on http://jeaprs.dev.java.net.  There is a packet parsing and formatting framework there, as well as an application base, that I did not get to finish before I got pulled off to do some other things and just didn't get back to it.  I used to run it in my car/truck on an iOpener PC that I had running linux.  John Gorkos chose to go ahead and roll his own, and he is working on it, so you might get better results using what he's put together.

I tried, early on, to get the HAM community interested in cross platform portability available in Java.  I just could not get any traction at that time, and I lost interest.

Gregg Wonderly
W5GGW

On Apr 8, 2012, at 4:30 PM, John Goerzen wrote:

> Absolutely, spam prevention is something a person has to solve before even beginning on a project like this.
> 
> Actually, my opinion is that with SMTP, you cannot completely solve the problem, so you have to engineer it out of existence as much as possible.  The Winlink APRSLink people did that by:
> 	• Requiring the APRS-side user to pre-authorize all email addresses allowed to send them messages
> 	• Permitting messages formatted in a special and uncommon way to be sent to the APRS-side user even if that user hadn't pre-authorized them.
> Their first approach could still be vulnerable to spammers that are impersonating a particular user (such as if the user's computer is compromised by a bot and is sending out malicious material).
> 
> My plan with XMPP is to follow their first approach.  I do not see a particular need to permit bypassing the whitelist with XMPP.  XMPP has much stronger peer validation than does SMTP, and in fact to the extent that spam is even possible with XMPP, it is usually trivially controlled by permitting messages only from existing people on your roster - something that is much more commonly done in IM than in email.  The only remaining spam avenue would be "invite spam", but by requiring invites to originate on APRS, that can be completely engineered away as well.
> 
> It would be folly to claim it's 100% foolproof, but I think it is actually better than some of the other systems that are out there, which are already pretty good.
> 
> -- John
> KR0L
> 
> On 04/08/2012 03:25 PM, Arnie Shore wrote:
>> From an interested lurker:
>> 
>> WRT SPAM detection, the protocol isn't the issue here.  It's the logic
>> that's necessarily gone into smtp clients, and, presumably wd be
>> needed by an XMPP client .   AS
>> 
>> On 4/8/12, John Goerzen 
>> <jgoerzen at complete.org>
>>  wrote:
>> 
>>> Hi Lynn,
>>> 
>>> On the one hand, you raise good points; on the other hand, what I'm
>>> proposing is nothing particularly new.  We already have:
>>> 
>>>     * PC keyboard to RF bidirectional messaging (Xastir, whatever is out
>>>       there for Windows)
>>>     * Bidirectional email to APRS messaging (APRSLink, other gateways)
>>> 
>>> So I guess I don't understand why XMPP is a concern whereas the others
>>> aren't.  Honestly I think it's LESS of a concern than email, as XMPP is
>>> more strongly authenticated than SMTP is, etc.  What does the iGate
>>> operator do about someone on Winlink sending messages that they shouldn't?
>>> 
>>> -- John
>>> KR0L
>>> 
>> _______________________________________________
>> aprssig mailing list
>> 
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> 
>> 
>> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig