<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <font size="4">A while ago, I suggested that I might implement the
      "nuclear option". Well this is it.<br>
      <br>
      The "simple" answer is to compare the incoming spot with the
      contents of the routing table. <br>
      <br>
      If the user or the node is not in the routing / user tables, then
      the spot is *likely* fake. <br>
      <br>
      Now, there are a number of circumstances where this assumption is
      not true. They include:<br>
    </font>
    <ul>
      <li><font size="4">When a node restarts, it will have an empty
          routing table which will not be fully informed for at least
          three hours - by which time it will have received PC92 C
          records from all the nodes then connected. Obviously PC92 A
          and records will have been received in "real time" for all the
          users that have come and gone in the interim. Therefore, until
          the enforcement wait time expires (default three hours), all
          spots will be treated as "valid".<br>
        </font></li>
      <li><font size="4">It's a spot coming from a source that does not
          (reliably) send PC92 [ADC] or PC16/17 records. That means
          anything behind a gateway into the AR-Cluster network (e.g.
          K1TTT). The gateway itself does supply this information to a
          directly connected node, but it won't be passed on because of
          the problems deduping PC16/17 and the fact that they are
          likely to be isolated nodes. If we don't pass these on, then I
          suspect the wailing and gnash of teeth will be too great. <br>
        </font></li>
    </ul>
    <p><font size="4">So what I propose to do is to test every spot
        coming in and depending and after three hours (configurable) the
        node will grade a spot and, depending on the value of
        $<a class="moz-txt-link-freetext" href="DXProt::senderverify">DXProt::senderverify</a>, will do one of these things if a spot
        fails the test above:</font></p>
    <p><font size="4">For users: </font></p>
    <p><font size="4">If set to 1, add a '?' to the one or more
        callsign(s) e.g.:</font></p>
    <p><font size="4" face="monospace">DX de II9IAKE:    7113.0  IQ9AAP
              15.55 IQ\'S DISTRICTS ARMI VESPUCCI AWARD <br>
      </font></p>
    <p><font size="4">becomes <br>
      </font></p>
    <p></p>
    <p><font size="4" face="monospace">DX de II9IAKE<font
          color="#ff0000"><b>?</b></font>:    7113.0  IQ9AAP<font
          color="#ff0000"><b>?</b></font>       15.55 IQ\'S DISTRICTS
        ARMI VESPUCCI AWARD <br>
      </font></p>
    <p><font size="4">It may be adequate to just add it to the spotter
        call... <br>
      </font></p>
    <p><font size="4">If it is set to 2 then users won't see it at all.<br>
      </font></p>
    <p><font size="4">For nodes:</font></p>
    <p><font size="4">If set to 1, pass it onward to other nodes. If set
        to 2 and it's a PC61 then dump it. If set to 3 then just dump
        it. <br>
      </font></p>
    <font size="4">Confession time: This variable already exists. You
      can set it to 1 (warning) or 2 (dump). But to see the sort of
      effect it can have,  just do a "set/debug suspicious" and start a
      "watchdbg suspicious" in another window.  You can unset/debug it
      and normal service will be resumed. This version does not affect
      what users see if set to 1.<br>
    </font>
    <p><font size="4">73 Dirk G1TLH</font></p>
    <br>
  </body>
</html>