launchpad-dev team mailing list archive

[Barry Warsaw <barry@xxxxxxxxxxxxx>]

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.

>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.

>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.

>> 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".

-Barry

Attachment: signature.asc
Description: PGP signature