[aprssig] New APRSMail (was: APRS<=>E-mail)

Ron Tonneson ron.tonneson at gmail.com
Tue Jan 13 22:57:47 EST 2009


OK, thanks.

Ron - K0QVF

Gregory A. Carter wrote:
> Hi Ron,
>
> I believe it failed because you tried to send a message to yourself... 
> the system doesn't allow self messages to prevent it from acking to 
> itself.  I'll have to work on that... if you send a message to someone 
> else it should work just fine.  I've added an error message for self 
> attempts for now to let people know.
>
> Greg
>
> NV6G
> OpenAPRS.Net
>
> On Tue, Jan 13, 2009 at 7:22 PM, Ron Tonneson <ron.tonneson at gmail.com 
> <mailto:ron.tonneson at gmail.com>> wrote:
>
>     The aprsmail.org <http://aprsmail.org> works fine with Firefox 3.0.5
>
>     I tried to send myself a message but so far it has not shown up on
>     my UI-View system.  I see it in the inbox on
>     aprsmail.org <http://aprsmail.org>.  Wonder if I did it wrong?
>
>     Ron - K0QVF
>
>     Gregory A. Carter wrote:
>     > Hello All,
>     >
>     > For those of you who have followed this thread or are interested
>     in an
>     > APRS->Email gateway I've created a new system that supports it.  If
>     > you'd like more information, point your web browser at
>     www.aprsmail.org <http://www.aprsmail.org>
>     > <http://www.aprsmail.org> and check out the front page, it gives
>     details
>     > of how to use the system, filtering, account access and the two
>     ways of
>     > accessing the gateway.
>     >
>     > The system is still being refined a bit and may still have some
>     > unforseen bugs but it appears to work.  IE6 users may have some
>     > formatting or display issues but the page should still be
>     functional and
>     > unerstandable for use.
>     >
>     > 73,
>     >
>     > Greg
>     >
>     > NV6G
>     > OpenAPRS.Net
>     >
>     > On Mon, Jan 5, 2009 at 2:40 PM, Gregory A. Carter
>     <gcarter at openaprs.net <mailto:gcarter at openaprs.net>
>     > <mailto:gcarter at openaprs.net <mailto:gcarter at openaprs.net>>> wrote:
>     >
>     >     This is one of those moments when I smack myself in the
>     forehead and
>     >     say, "I should have thought of that."
>     >
>     >     So with regard to security to prevent spam, my thoughts were to
>     >     allow the <callsign>@aprsmail.org <http://aprsmail.org>
>     <http://aprsmail.org> user to be
>     >     able to specify a generic password/code to be given in the
>     subject
>     >     line when a person wants to email->aprs them.  This would
>     imply that
>     >     the remote party wishing to contact would have to know the
>     password
>     >     in order to communicate.
>     >
>     >     I suppose this feature could be optional so the more daring can
>     >     leave the door open for anyone to email them assuming they
>     have the
>     >     correct email format.  For now, my thoughts are to force a
>     text or
>     >     html (NO MIME) email that will have the HTML auto stripped
>     (since
>     >     some clients send in html by default this would make life
>     easier for
>     >     the less advanced user) if present which are forced to use a
>     format
>     >     like the following for the system to parse and know the
>     message is
>     >     not spam.
>     >
>     >     --- Body of Message ---
>     >
>     >     SR:<FROM CALLSIGN>|MS:<MESSAGE>
>     >
>     >     --- End of Message ---
>     >
>     >     For those of you who have seen OpenAPRS's DCC interface this
>     is very
>     >     similar to the way DCC parses lines.  The pipe (|) character and
>     >     backslash (\) characters would have to be escaped if to be
>     >     interpreted literally.
>     >
>     >     This format would also leave tons of room for expansion if
>     needed in
>     >     the future.  When parsing this format spaces before and
>     after the
>     >     line would be removed and spaces would be compressed in
>     <MESSAGE>.
>     >
>     >     <MESSAGE> would be restricted to 67 characters or less.
>     >     <FROM CALLSIGN> would be restricted to a standard callsign
>     format 10
>     >     characters or less, no spaces and only letters numbers or -.
>     >
>     >     This format would be unmistakable compared to spam or any other
>     >     accidental email.  <FROM CALLSIGN> would then be used as the
>     source
>     >     in the packet and both the callsign and message would be
>     checked for
>     >     vulgarity.
>     >
>     >     Eventually the system would be expanded to read and  accept MIME
>     >     multipart messages and scan for the "text" body of the message.
>     >
>     >     So as an example, if I wanted to send a message to N6NAR from me
>     >     (NV6G) the email would look like this.
>     >
>     >     ***BEGIN***
>     >     TO: n6nar at aprsmail.org <mailto:n6nar at aprsmail.org>
>     <mailto:n6nar at aprsmail.org <mailto:n6nar at aprsmail.org>>
>     >     FROM: gcarter at openaprs.net <mailto:gcarter at openaprs.net>
>     <mailto:gcarter at openaprs.net <mailto:gcarter at openaprs.net>>
>     >     SUBJECT: <optional password>
>     >     ---
>     >
>     >     SR:NV6G|MS:Hello, how are you today?
>     >     ***END***
>     >
>     >     SR: and MS: could be specified in any order the parser won't
>     care.
>     >
>     >     Thoughts, opinions?
>     >
>     >     Greg
>     >
>     >     NV6G
>     >     OpenAPRS.Net
>     >
>     >
>     >     On Mon, Jan 5, 2009 at 10:48 AM, Lynn W. Deffenbaugh (Mr)
>     >     <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>
>     <mailto:ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>>> wrote:
>     >
>     >         Actually, I would rely on the TCPIP as the path rather than
>     >         trying to
>     >         play catchup or guesswork on what client application
>     they are
>     >         using.  If
>     >         their path is ONLY TCPIP* (excluding the qXX code and gate),
>     >         then assume
>     >         APRS-IS.  Otherwise, it is RF-limited.
>     >
>     >         Lynn (D) - KJ4ERJ
>     >
>     >         Gregory A. Carter wrote:
>     >          > Thanks for looking that up Lynn...
>     >          >
>     >          > So it may be possible to check to see if the user is
>     actually
>     >         online
>     >          > at the time with messaging by looking at the destination
>     >         address they
>     >          > have set which would hopefully reveal what client
>     they are
>     >         using.  Of
>     >          > course this would fail in the case of MIC_E packets
>     but would
>     >          > generally be useful for others.  If we couldn't
>     detect what
>     >         client
>     >          > they were using then we're default to the RF limit.
>     >          >
>     >          > Greg
>     >          >
>     >          > NV6G
>     >          > OpenAPRS.Net
>     >          >
>     >          > On Mon, Jan 5, 2009 at 10:24 AM, Lynn W. Deffenbaugh (Mr)
>     >          > <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>
>     <mailto:ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>>
>     >         <mailto:ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to> <mailto:ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to>>>> wrote:
>     >          >
>     >          >      From the APRS101 spec approved 29 August 2000
>     under the
>     >         NTS Radiogram
>     >          >     section:
>     >          >
>     >          >     Each line may be up 67 characters long, including the
>     >         3-character NTS
>     >          >     format identifier. Lines in excess of 67
>     characters will
>     >         be truncated.
>     >          >
>     >          >     Also from the Messages, Bulletins, and
>     Announcements section:
>     >          >
>     >          >     The message text may be up to 67 characters long,
>     and may
>     >         contain any
>     >          >     printable ASCII characters except |, ~ or {.
>     >          >
>     >          >      From the APRS-IS Specification:
>     >          >
>     >          >     All "packets" sent to APRS-IS must be in the TNC2
>     format
>     >          >     terminated by a
>     >          >     carriage return, line feed sequence. No line may
>     exceed
>     >         512 bytes
>     >          >     including the CR/LF sequence.
>     >          >
>     >          >     And that 512 bytes INCLUDES the TNC2 monitor
>     format "header"
>     >          >     information
>     >          >     (prior to the colon) of SENDER>DEST,PATH:rest of
>     packet.
>     >          If I
>     >          >     remember
>     >          >     correctly, the AX.25 path can handle up to 8 hops
>     and then an
>     >          >     IGate may
>     >          >     add a qXX and it's own callsign, and a
>     callsign-ssid is 9
>     >         characters,
>     >          >     plus the commas means that the header maxes out
>     at 120 bytes
>     >          >     (sender+dest+8*path+qXX+IGate) (actually 114 if
>     we assume
>     >         a 3, not 9,
>     >          >     character qXX code).  That would leave a maximum
>     of 398
>     >         payload
>     >          >     characters per the APRS-IS spec.  Oh, but we have to
>     >         allow for the 9
>     >          >     character message destination and an additional colon
>     >         separator
>     >          >     plus the
>     >          >     ack at the end (assuming the e-mail forwarder is
>     doing the
>     >          >     decaying send
>     >          >     until ack routine).  That'd leave us with 382 (10 for
>     >         dest & colon
>     >          >     and 6
>     >          >     for {msgno per APRS spec).
>     >          >
>     >          >     Seems like 382 is the upper limit of message body for
>     >         TCP/APRS-IS
>     >          >     packets and 67 is the defined spec limit for APRS
>     over RF
>     >         messages.
>     >          >
>     >          >     Lynn (D) - KJ4ERJ - Thankful for Jason's
>     suggestion to
>     >         check the
>     >          >     specs...
>     >          >
>     >          >     Jason KG4WSV wrote:
>     >          >     > On Mon, Jan 5, 2009 at 11:48 AM, Lynn W.
>     Deffenbaugh (Mr)
>     >          >     > <ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to> <mailto:ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to>>
>     >         <mailto:ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to> <mailto:ldeffenb at homeside.to
>     <mailto:ldeffenb at homeside.to>>>> wrote:
>     >          >     >
>     >          >     >> To throw out numbers, I'd say 1K for non-RF users
>     >          >     >>
>     >          >     >
>     >          >     > gack!  Think maybe you should check the APRS-IS
>     design
>     >         first?  I
>     >          >     don't
>     >          >     > know the upper limit on packet size, but it
>     would pay
>     >         to check
>     >          >     it out.
>     >          >     >
>     >          >     > Think "APRS messages", not "small email".
>     >          >     >
>     >          >     > -Jason
>     >          >     > kg4wsv
>     >          >     >
>     >          >     > _______________________________________________
>     >          >     > aprssig mailing list
>     >          >     > aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>
>     >         <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>>
>     >          >     >
>     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>     >          >     >
>     >          >     >
>     >          >
>     >          >
>     >          >     _______________________________________________
>     >          >     aprssig mailing list
>     >          >     aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>
>     >         <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>>
>     >          >     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>     >          >
>     >          >
>     >          >
>     >        
>     ------------------------------------------------------------------------
>     >          >
>     >          > _______________________________________________
>     >          > aprssig mailing list
>     >          > aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>
>     >          > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>     >          >
>     >
>     >
>     >         _______________________________________________
>     >         aprssig mailing list
>     >         aprssig at tapr.org <mailto:aprssig at tapr.org>
>     <mailto:aprssig at tapr.org <mailto:aprssig at tapr.org>>
>     >         https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>     >
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > aprssig mailing list
>     > aprssig at tapr.org <mailto:aprssig at tapr.org>
>     > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto: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
>   





More information about the aprssig mailing list