launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

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

> What Mailman does when an address bounces "too much" is to
> first disable it, so normal traffic will not be sent to it.  But then it sends
> out some number of probes, say once a week for a month.  These probes are
> VERPd so we can unambiguously determine who we sent them to, and because we'll
> see their bounces.  If we don't see a probe bounce, we cannot know what
> happened to the message.  

So in other words, whether we get the bounce back or not is actually irrelevant, right?  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...

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

>> if there is another email address registered for that user that either has
>> not previously bounced or has been reenabled by the user since then, then
>> we automatically change the preferred email to another one for a
>> user. [Alternative: we ignore the other email addresses; skip to the next
>> bullet point.]
> 
> Of course, you would only fallback to other registered and *validated* emails.

Yes, good clarification, thank you.

>> else if there are no other non-bounced email addresses registered for that
>> user, then we mark the user as disabled, and give them a smooth, custom
>> process to fix the situation when they log back in: they are taken to a
>> list of their email addresses, and asked to add a new email address and/or
>> mark existing email addresses as not disabled. This re-enables their
>> account. [Alternative extreme: we simply stop delivering emails to this
>> person (other than the bounce processor emails described above), and
>> continue normally if they log in.  They can see the problem if they go to
>> the email page.]
> 
> Or you can put up a big red banner on all their ~ pages.

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.

> 
>> When a user views their registered email addresses, they can see what
>> addresses have been disabled due to bounces, and reenable them, in addition
>> to setting preferred email and adding and removing addresses, as they can
>> do now.
> 
> +1

Thanks for the feedback!

Gary