<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Absolutely, spam prevention is something a person has to solve
    before even beginning on a project like this.<br>
    <br>
    Actually, my opinion is that with SMTP, you cannot completely solve
    the problem, so you have to engineer it out of existence as much as
    possible.  The Winlink APRSLink people did that by:<br>
    <ul>
      <li>Requiring the APRS-side user to pre-authorize all email
        addresses allowed to send them messages</li>
      <li>Permitting messages formatted in a special and uncommon way to
        be sent to the APRS-side user even if that user hadn't
        pre-authorized them.</li>
    </ul>
    Their first approach could still be vulnerable to spammers that are
    impersonating a particular user (such as if the user's computer is
    compromised by a bot and is sending out malicious material).<br>
    <br>
    My plan with XMPP is to follow their first approach.  I do not see a
    particular need to permit bypassing the whitelist with XMPP.  XMPP
    has much stronger peer validation than does SMTP, and in fact to the
    extent that spam is even possible with XMPP, it is usually trivially
    controlled by permitting messages only from existing people on your
    roster - something that is much more commonly done in IM than in
    email.  The only remaining spam avenue would be "invite spam", but
    by requiring invites to originate on APRS, that can be completely
    engineered away as well.<br>
    <br>
    It would be folly to claim it's 100% foolproof, but I think it is
    actually better than some of the other systems that are out there,
    which are already pretty good.<br>
    <br>
    -- John<br>
    KR0L<br>
    <br>
    On 04/08/2012 03:25 PM, Arnie Shore wrote:
    <blockquote
cite="mid:CAMN8bj=eejTzRt1-COUK-uzOhyaVFDM_PXuoz9v-BtsMqfo-xg@mail.gmail.com"
      type="cite">
      <pre wrap="">From an interested lurker:

WRT SPAM detection, the protocol isn't the issue here.  It's the logic
that's necessarily gone into smtp clients, and, presumably wd be
needed by an XMPP client .   AS

On 4/8/12, John Goerzen <a class="moz-txt-link-rfc2396E" href="mailto:jgoerzen@complete.org"><jgoerzen@complete.org></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi Lynn,

On the one hand, you raise good points; on the other hand, what I'm
proposing is nothing particularly new.  We already have:

    * PC keyboard to RF bidirectional messaging (Xastir, whatever is out
      there for Windows)
    * Bidirectional email to APRS messaging (APRSLink, other gateways)

So I guess I don't understand why XMPP is a concern whereas the others
aren't.  Honestly I think it's LESS of a concern than email, as XMPP is
more strongly authenticated than SMTP is, etc.  What does the iGate
operator do about someone on Winlink sending messages that they shouldn't?

-- John
KR0L
</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>

</pre>
    </blockquote>
  </body>
</html>