Text 38309, 124 rader
Skriven 2006-09-04 19:22:00 av Michiel van der Vlist (2:280/5555.1)
  Kommentar till text 36622 av Matt Bedynek (1:106/1)
Ärende: ^apathline (was: Nodenumber?)
=====================================
Hello Matt.

12 Aug 06 10:43, you wrote to me:

 MB> I also reviewed my code and discovered that my check is less strict
 MB> than I remembered.

 MB> Here are a few checks I use with exemptions (if needed), in case your
 MB> curious.

 MB> As someone technical, I figured you might be.

I am. I got tangled up in a few other things though. Hence my late reaction..

 MB> 1.  Last hop of message in packet matches packet's from address
 MB> (security).

Makes sense.

 MB>   Only one node out of the ~50 something nodes that link do
 MB> I disable this check.

I wonder why the failure to match.

 MB> 2.  First hop of message shares the same network as origin.  This is
 MB> the check that mark is giving me grief over.  This is less strict
 MB> than I remembered.  I actually only compare the net only.  e.g. as
 MB> long as the first hop and origin reside in the same net this check
 MB> will not match rather than being node specific.

To check on the origin net only makes little sense to me. I'd say either do a
full check or do not check at all.

 MB>   Falses occasionally. Nodes require exclusion.

That would be the nodes that do not follow the PATH specs.

 MB> 3.  My aka present in messages (cpd).  Never falses.

No comment ;-)

 MB> 4.  Looping path detection.  Falses occassionally.  I disabled this
 MB> one a while ago because it did trap a few legitimate messages that
 MB> were part of loops far down in topology trees.  But I might enable it
 MB> again but send warnings rather than trap.

A loop is always an error isn't it?

 MB> 5.  Force path option allows me to define static topologies.  e.g. I
 MB> can set it such that if 123/500 does not appear as the last hop
 MB> (directly connected) to trap.  This is 100% effective in finding
 MB> broken links in echoes for which there are clearly defined toploogies.
 MB> It also picks up many dupes that might slip past other detection
 MB> methods (date, dupe history, ect.)  This never falses because I only
 MB> set it where it needs to be set.  I do have a few exclusions (echo
 MB> specific).

Hmmm....

 MB> 6.  TTL > 15.  I admit that 15 is arbirary but I have never seen 15
 MB> hops on a message that was legit. This is a catch all for all other
 MB> path checks that might not engage.  Never falses.

I have seen longer path's here in the past. Today the links are usually quit
short.

 MB> 7.  Rescan kludge.  Never falses.  rescan kludge should never be
 MB> present in authentic echomail.

Check.

 MB> 8.  Msgs older than 60 days or newer than 7 days.   My dupe history
 MB> can be significantly large but I found that some msgsids do repeat for
 MB> broken software.  A dupe history, for example, of 1 yr trapped
 MB> legitimate on occassion.  This 60 days allows me to catch anything
 MB> that my dupe history will not.

I am not sure I understand the newer tha 7 days trap...

 MB> 9.  Link state checking.  This is currently disabled because Im
 MB> recoding my checks but I built a nifty link state database that
 MB> monitored the weighted average of traffic from nodes.  It would trap
 MB> all messages from a node if it exceeded its weighted average over a
 MB> period of time.  For example, a node would first have to be connected
 MB> for a period time for the database to "learn" what was normal.  Then
 MB> after that set threshold passed would trap messages if the node
 MB> exceeded what was "normal".  This was used for 6 months but I found
 MB> that most other checks caught problems anyway.

I have to give it to you: you have really put effort into this and given it
serious thought. Chapeau.

 MB> It is cool to be able to detect these problems no matter where in the
 MB> toplogy they lie.  Years ago, several in Z1 were proactive in
 MB> detecting and notifying nodes of topology issues, misconfigurations,
 MB> and ect.

Same here.

 MB>   But now, it seems I am the only one catching these problems. :-(

I am not aware of anyone doing that this side of the pond. Of course I do not
know everything..

 MB> Most seem to run their system like a leaky house passing any and
 MB> everything unchecked.  I don't believe people should run a system
 MB> like Souvestre that would trap a message if you sneezed while typing
 MB> the message but I believe some minimal checks should be performed.

 MvdV>> Granted. The FTSC is a bit behind in documenting this
 MvdV>> particular part of "standard practise". I will make mental note
 MvdV>> of that and bring it up when FTS-4 comes up for review.

 MB> Much better response than "I'll generate messages 'out of the norm'
 MB> just to get them trapped by your system".

;-)

Cheers,

Michiel

--- GoldED/W32 3.0.1
 * Origin: Michiel's laptop, on the move somewhere.... (2:280/5555.1)