28 Oct 16 11:30, you wrote to me:
ml>> in most cases, the system ""above"" you that sends the dupes to you
ml>> should catch them... it may not be able to do so if its dupe database
ml>> gets flushed of dupe data real quickly because of the amount of
ml>> traffic it handles... that's if that system even has dupe detection
ml>> enabled... they may not have it enabled if they elect to send all
ml>> mail on to their connections and let them determine if it is a dupe
ml>> or not... they may decide to do that so as to avoid false positives
ml>> being stopped and not propogating...
RN> But that system's dupe detector worked well for years and years until
RN> lately. No, I believe the problem lies in a misconfiguration somewhere
RN> eles.
ok... i see what you are saying now... it is no misconfiguration, though... it
is a change in the landscape... previously there were fewer dupes to deal
with... they were part of a system that had only two others in the fully
connected polygon... today, there are many more systems in numerous polygons,
fully connected and not so fully connected... today's game is about redundancy
and there is no cost to transport dupes like there was in the old POTS dialup
days of yor... with more dupes flying around, old school slash old style dupe
databases can get overrun pretty quickly... this is especially true in older 16
and 32 bit code... 16bit moreso, of course... there is a limit to the sheer
number of values they can store and there is also a filesize limitation... the
filesize limitation used to be OS dependant but older software on new OSes will
find their index counters to be the limitation on file sizes...
we're not even touching on some of the new ""slightly"" buggy software that is
available today, either...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... On Nytol: Warning: may cause drowsiness.
---
* Origin: (1:3634/12.73)
|
