[aprssig] New APRSMail (was: APRS<=>E-mail)
Ron Tonneson
ron.tonneson at gmail.com
Tue Jan 13 22:22:44 EST 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
More information about the aprssig
mailing list