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.
Mailman-Developers mailing list
Mailman-Developers at python.org
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')

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
groupmailman-developers @
postedJan 8, '11 at 12:30a
activeJan 9, '11 at 3:04p



site design / logo © 2021 Grokbase