On 6/16/23 20:04, Mike Wertheim wrote:
Thanks for the response.
A while back I experimented with enabling verp-probes. The users on the list were confused by the probe emails and sent me a lot of messages asking about them, so I disabled it.
But at least their delivery wasn't being disabled because the probes weren't being bounced.
Further, the first sentence in the body of the probe is
"This is a probe message. You can ignore this message."
If you think the probe could be more explanatory, you can always set a list:user:notice:probe template to say what you want.
There is zero spam on the list. Ill try reducing "bounce info stale after" to "2d". (Actually, would "1d" be even better?)
Suppose you set it to 1d. This means that in order for a true bouncing user to have delivery disabled with threshold = 5 There have to be posts every day for 5 consecutive days. If it's set to 2d, there can only be one day out of 6 with no posts for a true bouncing user's delivery to be disabled. If you can't guarantee that condition, you might as well just set Process Bounces to No.
I would ensure Notify owner on bounce increment and Notify owner on disable are set to Yes. Then, assuming Mailman core >= 3.3.5, when users scores are incremented the owner will get a notice containing the bounce DSN. With that information, you can figure out why these valid addresses are bouncing the mail. Or, if the bounces occur during your outgoing SMTP, your MTA logs will have the reason. Given that information, you may be able to fix whatever is causing the delivery issue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan