[Mailman-Developers] Implementing `bounce_you_are_disabled_warnings_interval` in `Send_Warnings` function.

Aaryan Bhagat writes:

• In the case of Send_Warnings function if the same approach was followed, meaning it would take one by one the Address instances, check tuples in the bounce_info attribute ( see the pr for this ) and see whether to send a warning mail or not to can be a slow method.

• Let's suppose the Addresses list is very long, then an Address instance in the very bottom of the list whose subscription has been disabled and some warning emails send, now waits to receive another mail as the interval is more than bounce_you_are_disabled_warnings_interval.

• If the function is enumerating from the top then in order to take action first it has to reach this Address instance but the interval is already crossed. This can cause slow performance as the warning mail will be sent way late than it actually should have been sent.

I assume that what you mean here is that this process is executed perhaps once per day and probably takes a few minutes at most in processing. Then we have 300s/86400s = 1/288 of a day = probability that during the interval that address's timer expires, and the message is delayed until the process triggers again, hypothetically a full day.

The odds that this happens is quite small unless you have a humongous list. Furthermore, the probability that the mail will go through this time if the account has disabled due to bouncing is presumably way less than 1. So my first-order response is this is a non-problem.

Note that you have basically the same problem if the Address's timer expires a few seconds after the send_warnings process finishes.

My second-order response is if you still care given that this is rarely going to happen, and even more rarely will it generate a message that reaches the user who reactivates the subscription, you can arrange to have an index on the Addresses (or a separate queue) which has the earliest timer first, and then process the Addresses in that order. You'll still have the same problem if the timer expires a few picoseconds after you start processing the particular address. :-) Basically the way to deal with this is to adjust the bounce_you_are_disabled_warnings_interval.

If you do implement the queue, another possibility comes up, which is that you process the queue continuously, with a process (a runner, I guess) that sleeps until it's time to process the next send_warning. This would have the advantage that if there were another "DMARC event" that caused large number of bounces, you wouldn't have a flood of warning messages are a particular time of day.

• Also if I am implementing 2 functions process_bounces and send_warnings what if both of them attempted at the same Address instance?

What about it? This is even more unlikely, and I assume that process_bounces will have a read-write lock that prevents reading (and writing) while it's writing, while send_warnings will have a read lock that prevents writing while it's reading. I think all of the databases we support have such locks.