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