On Jul 11, 2011, at 11:01 AM, Barry Warsaw wrote: > On Jul 11, 2011, at 10:42 AM, Gary Poster wrote: > >> On Jul 8, 2011, at 5:46 PM, Barry Warsaw wrote: >> >>> On Jul 08, 2011, at 05:14 PM, Gary Poster wrote: >>> >>>> * If a preferred email bounces "too much" for our heuristics (as informed >>>> by >>>> * Barry's Mailman experience), then we send out emails to the email address >>>> * once a week for (adjustable N) 4 weeks telling them of the problem, and >>>> * inviting them to tell us to retry the address once they have fixed the >>>> * problem. In addition... >>> >>> Small correction. >> >> I'm not sure what you corrected. :-) > > The way I read your text was that the address doesn't get disabled until after > the probes are sent. I could have misread that though, but I wanted to make > it clear that Mailman disables the address once the bounce score reaches the > threshold, and the probes are sent after this occurs.
Ah OK. Yeah, clear in my head, but not clear in my email. Thanks. > >> So in other words, whether we get the bounce back or not is actually >> irrelevant, right? > > Almost, but not quite. You could use probe bounces to give higher confidence > that delivery to the address is even more fail-y. > > I just checked, and this is not the case, but it might actually not be a bad > idea: bounce probes should not set Precedence: bulk. The theory is that the > probe messages are not bulk or list traffic, so it's conceivable possible they > could get through where list traffic wouldn't. The one downside is that > well-behaved vacation programs will respond to non-Precedence traffic. I just > filed bug 808821 to think about this for MM3. Hm. OK. For now, I think I'd be happy with Mailman's current behavior, but I'll document the possible extension. > >> If we get the bounce back, ok, they are definitely still hosed. If we >> *don't* get the bounce back, we don't know what happened, so it doesn't prove >> anything, so we should not re-enable them. Right? So therefore... > > Right, with the additional possibility of doing something even more if you get > probe bounces. But perhaps there's nothing much more that would be > appropriate for Launchpad to do. Nuke user from orbit! Well, OK, no... >>> If the user got the probe, it will contain some >>> additional details about why they were disabled, and instructions for how >>> they >>> can re-enable their email. >> >> ...those instructions for the user are the key, AIUI. If they re-enable >> their email, we set the bounce score back to zero and try everything again. >> Yeah? > > Yep. > >> Yeah. If we were going that way, I'd prefer to have the banner on *all* >> pages. We have a shared main template so that *might* work OK. > > Good point. Once they're logged in authenticated, you always know if they > have disabled addresses. Just give them a big fat link to get to their > +editemails page, and give them a way to say "yes, this address is really > defunct so stop bugging me about it". Yeah, +1. This will be one of the core parts of my revised proposal, I think. It addresses some of Martin's questions as well. Thanks! Gary _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
