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

Wed Jan 14 03:22:44 UTC 2009

The 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.  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> 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>> 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> 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>
>     FROM: 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>> 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>>> 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>>> 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>>
>          >     > 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