[aprssig] New APRSMail (was: APRS<=>E-mail)
Gregory A. Carter
gcarter at openaprs.net
Tue Jan 13 22:53:26 EST 2009
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>wrote:
> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090113/eafbf80c/attachment.html>
More information about the aprssig
mailing list