launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

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