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)