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.
---