[Mailman-Developers] Bounce processing in MM3

[Adam McGreggor]

On Fri, Jan 07, 2011 at 07:30:51PM -0500, Barry Warsaw wrote:
> There are a couple of interesting things in MM3 that makes it different from
> MM2.  In MM3, users and addresses are global to the system, while membership
> is specific to a mailing list.  This means if we register a bounce on an
> address, we can have that score affect the address's subscription to all
> relevant mailing list.  

This makes me feel slightly uncomfortable, particularly for large
(multi-site, multi-client) installations -- Hosting Co, &c.

> We can also do things like automatically roll over to
> another registered and validated email address for that user, if there is one,
> or at least send notifications to the other address.

Hum. If the auto-rollover knew "oh, it's a different MX" there might
be a point. However, just trying adam at amyl.org.uk, instead of
adam-mailman at amyl.org.uk, or adam+tarpit at amyl.org.uk, would not be
very useful, I'd imagine. Maybe an option to specify "this is my
recovery address, send bounce-notifications here, please" might be
useful? (for end users). It would obviously need to spell out, quite
clearly for which address it releated to, as finding an envelope-to:
header seems to be tricky for users.

> There's also the question about how all the bounce scores are managed, and the
> knobs you as a list administrator can tweak to control how and when things
> happen based on the score.  Reporting and logging are also part of the plan.

I'm perhaps a little cavalier in my approach; I generally let Mailman
handle the bounces, so I can do something useful. About the most I
delve, when I don't need to investigate "why aren't I getting mail" is
a monthly report of numbers of subscribers, changes to that figure
from previous month, and "reasons" why people left, pulled from
subscribe.log, at the moment.

> Because MM3 uses a relational database underneath the hood, my plan is to have
> a single table that only appends new bounce events.  That way, Mailman will
> have a permanent record of every bounce that occurred.  

What may be useful is to supplement this with a pertinent dates table,
too, something like start-date/end-date/few-words-on-problem, either
controlled by Chief Goncho (aka site-admins), or maybe with something
for listadmins; the case I'm thinking of may be to show that, say the
LINX have had problems for a couple of months, "MTA tweak for
redelivery attempts to yahoo.com made on 2010-02-04"; these would be
added to a gnuplot/graph in a separate color, in my vision (maybe I've
used google analytics too long, but clicking on the event for more
info would be grand). Perhaps that's function creep, though.

> Exactly what
> information we can or should put in that table is up for discussion.  I do
> plan also to keep all bounce messages in MM3's "message store" so that
> postmortem debugging is easier.

In which case, there should definately be an option for "keep bounce
messages in store for N months", and perhaps make list-specific ones
available to list-admins.

> Because I'm just starting to think about all this, I wanted to throw this out
> to the list to get your feedback on things you'd like to see.  What is it
> about MM2's bounce processing that you like?  

It does most of the work for me; I set the global parameters, and
generally, just leave Mailman to do everything for me. I might
sometimes see the "been removed from the list due to bounce" mails; if
those were on a grid-thing somewhere in the admin pages, I don't think
I'd need/want the mails.

> What don't you like?  What MM2
> bounce features can you do without?  What would you like to see added?
> 
> Any and all feedback is welcome.
> -Barry



> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/adam-mailman%40amyl.org.uk
> 
> Security Policy: http://wiki.list.org/x/QIA9

-- 
"You know it cannot have been a good night when you get into a fight
 with Spider-Man and two cross-dressing men"
    -- Mark Davies (defence lawyer, regarding 'Cage fighters picked on
            because they were dressed as women for a stag night')