home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   MYSTIC      Mystic support echo      16,010 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 14,036 of 16,010   
   Paul Hayton to g00r00   
   Re: rate limiting   
   13 Nov 21 10:07:20   
   
   TID: Mystic BBS 1.12 A47   
   MSGID: 3:770/100 11f282ec   
   REPLY: 1:129/215 3083e4c4   
   TZUTC: 1300   
   On 08 Nov 2021 at 08:10a, g00r00 pondered and said...   
       
    g0> How did these messages come in?  Where they connecting to you every   
    g0> minute to send a new message or did it come in clumps every so often?  I   
    g0> think having a clearer picture might help me think it through a little   
    g0> better.   
      
   Have just dug back into the HUB logs and emailed you some files. Essentially   
   it looks like one packet being processed by MUTIL and it contained approx 5   
   messages for the echomail area within it. The next packet arrived and was   
   processed around 2 mins later and so on.   
      
    g0> I am open to trying to build something like this, but I am not really   
    g0> sure how well it would work.  If a node spams connections to you that   
      
   Thanks for looking / considering it. If it proves overly problematic and does   
   not lead to something you want to add I'm understanding of that too.   
      
    g0> can be covered by the BINKP auto blocking, but I realize that doesn't   
    g0> really address this specific issue.   
      
   No, in this case it's the tossing frequency rather than the mailer frequency.   
      
    g0> When talking about importing a packet it would be tough to determine   
    g0> when its a flood if the message content is different each time.  If we   
    g0> put a threshold in for messages then it could backfire in situations   
    g0> where people are trying to do rescans or maybe even for systems who only   
    g0> poll daily or whenever they feel like reading (so they tend to get mail   
    g0> in larger clumps)...   
      
   Agreed, as in the examples above, it's nodes wanting to toss a large amount of   
   packets and messages within a short space of time, such as a rescan etc.   
      
    g0> I suppose in the case of a hub though, there wouldn't be many instances   
    g0> of a rescan coming into the hub, so maybe the threshold could work but   
    g0> just be disabled by default?  Or set to something really high.   
      
   Yes I agree. From the HUB POV it's about the node sending something in such   
   that the quantity of messages posted over a defined short period of time is   
   leading to issues for others connected to the HUB and it's echos.   
      
    g0> The tracking would be a bit difficult or at the very least annoying to   
    g0> do and it would probably slow down tossing speed a bit since it would   
    g0> have to compare every single message being tossed and it would have to   
    g0> save this sort of data for every node between MUTIL execution.   
      
   Instead of inspecting message content could a frequency counter be implemented   
   such that if x messages from a node were being tossed over x period then an   
   issue could be flagged and an action(s) taken?   
      
   As I sit and ponder this it's really about the number of incoming messages to   
   be tossed to a given echo or echos from a node over a short time period.   
      
   If you did end up adding something I'm not sure if such a HUB setting should   
   be set at a high level to apply to all nodes and/or if it could/should be set   
   at a echomail area level? Gotta ponder that.   
      
   --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)   
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)   
   SEEN-BY: 1/123 90/1 105/81 114/705 120/340 123/120 131 129/305 154/10   
   SEEN-BY: 218/840 220/70 226/17 30 100 227/114 702 229/101 424 426   
   SEEN-BY: 229/428 452 550 664 700 981 240/5832 249/206 307 317 400   
   SEEN-BY: 250/5 8 267/800 282/1038 292/854 298/25 301/1 305/2 3 317/3   
   SEEN-BY: 322/757 340/1000 342/200 633/280 712/848 770/1 3 100 340   
   SEEN-BY: 772/210 220 230   
   PATH: 770/100 1 317/3 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca