[aprssig] APRS<=>E-mail

[Gregory A. Carter]

That makes sense, though really HTML is an accepted form of email based on
client support so I would tend to think it doesn't need an option just
simply strip out the HTML white-space compress the text and send.   Most
people aren't aware of what an HTML email is, they simply open their email
client and check their messages so to expect everyone to know how to shut
off HTML in order to send to APRS could be a problem.  Although we're
talking about HAMs here who you would imagine have a little more of a handle
on the technical aspect of things.

The length should be truncated however since it could get ugly if someone
tries to send a book worth of text and could have a great potential to kill
APRS-IS or severely overload it.  The only way this system works is to send
the message through APRS-IS and let individual iGates try and gate it back
to RF users.

I envision the ability to accept messages from all as an option, limit
incoming messages to only those in an approved list and enable a blacklist
that will reject anything from certain addresses or IPs.

Greg

NV6G
OpenAPRS.Net

On Mon, Jan 5, 2009 at 9:03 AM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

> Given that we all have different APRS devices, allow the RECIPIENT to
> specify the max length of any single message and whether to truncate or
> split longer messages.  White-space compression can also be done as well
> as HTML-stripping down to the plain text.
>
> Alternatively, allow the RECIPIENT to specify whether HTML-formatted
> messages will be accepted directly, rendered to text, or rejected (plain
> text only).
>
> Also, if it supports restricting from whom e-mail will be accepted,
> please also support a wild-card for those APRS-IS clients that might
> want to receive from anyone and are not bandwidth-limited nor impacting
> an RF hop.
>
> Lynn (D) - KJ4ERJ - Adding my <small monetary amount> to the design
>
> Rusty Hemenway wrote:
> > I think a character count should be also be developed.  We don't want
> people
> > sending 30 line email messages over APRS.
> >
> > -----Original Message-----
> > From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On
> Behalf
> > Of Ben Jackson
> > Sent: Monday, January 05, 2009 8:11 AM
> > To: aprssig at tapr.org; TAPR APRS Mailing List
> > Subject: Re: [aprssig] APRS<=>E-mail
> >
> >
> > On 1/5/2009, "Gregory A. Carter" <gcarter at openaprs.net> wrote:
> >
> >
> >
> >> If there is interest in this I'll whip something up and impliment it,
> let
> >>
> > me
> >
> >> know on or off list...
> >>
> >
> > Since you asked... You're pretty much right on the money. Coming from an
> > infosec standpoint, I think there should be a two-stage authentication
> > for incoming e-mail:
> >
> > * User specifies what e-mail addresses can send him mail.
> > * Authorized users need to enter a "password" in the subject line for
> > each message.
> >
> > This way this snuffs any kind of "accidental" leakage of spam-ish
> > material onto the APRS network.
> >
> > ~Ben
> >
> > _______________________________________________
> > 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
> >
> >
>
>
> _______________________________________________
> 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://www.tapr.org/pipermail/aprssig/attachments/20090105/f20d9262/attachment.htm