Subj : Re: rate limiting
To   : g00r00
From : Paul Hayton
Date : Sat Nov 13 2021 10:07 am

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)

.