[Mailman-Users] Frequent use of clone_member

[Adam McGreggor]

On Mon, Nov 01, 2010 at 07:31:26PM -0600, Ivan Fetch wrote:
> Ivan Fetch writes:
> 
>  > One possibility we're exploring, is to change a student's mailing
>  > list subscriptions, when they change their forwarding address. We
>  > would iterate through these address changes and run clone_member,
>  > like:
>  > 
>  > Clone_member --remove --admin  old at our.domain new at outside.domain
> 
> I can't really comment on the burden on the host, but ISTM that this
> would be a substantial burden on the students.  They would have to
> remember which account is their real account to make any changes, or
> to post.  This might be non-trivial for students with multiple
> mailboxes.

> Students are changing their forward, and we would be trying to
> "help" them keep mailing list subscriptions pointed to that new
> forwarding address. 

Is this not looking for a technical solution to a social one?

(It was the case that both times I was at college (Federal
Universities), that my college/university provided address was defined
as a contact address, and it was *my* responsibility to ensure I
picked up mails sent to that address).

> We are leaning more toward tracking when a forwarding address
> changes, and sending a helpful email about mailing list memberships
> which may need to be changed - but not actually changing anything.

How do you manage forwarding, currently? If your email setup uses a
database, how about adding 

(for example)
    (a) a timestamp, 
    (b) a change-log (the previous value),
    (c) current value

to that, and using the timestamp to calculate if anything needs to be
done (and to whom), and then using the values of (b) and (c), to
update your lists? (presumably, using something like find_member, and
then clone_member or non_members [1])

[1] http://www.msapiro.net/scripts/non_members

> How about having the forwarding address setup update
> accept_these_nonmembers, instead?

> IF we start filling accept_these_nonmembers, this separate source of addresses will need to be cleaned out - this is likely a larger overhead / bucket of hurt, than we want to create.

Or you can purge the old addresses, too. Or maybe even go down the
sibling list approach, and have

    foo-acadaemia at lists.example.edu
    foo-forwarding at lists.example.edu

where "official" (institution provided) addresses are always
subscribed, and leave -forwarding to be built/manipulated by scripts?

(and foo-forwarding to obviously receive foo-acadaemia mails).

> Also, what are you going to do about the old forwarding address?  It
> seems likely that in many cases students will want to do things like
> receive on their cellphone account but sometimes post from their home
> ISP, etc.  Then they change back, creating a real muddle.  OTOH,
> allowing dead or dormant accounts to post is a potential issue.

If there's a time-stamp (or flag, or whatever) included, that's
something that could be checked against, and appropriate action (not)
taken.


> This is one of the reasons we have begun thinking about sending an
> informative email, instead of changing addresses. As soon as we start
> taking it apon ourselves to helpfully change addresses, we will break
> things for subscribers who have other addresses (which happen to be an
> old forward) subscribed for a reason.

Tricky business. Informative mails will presumably need to include
find_member output, or something like that. That said, it pushes the
responsibilites over to the user: surely a good thing (assuming they
get the mail, and it's not "helpfully" spam-classified by their
(web)mail provider.


> We will still need to do mas-address changes for faculty and staff, who will be moving to MS Exchange - in some cases, they choose to begin using a different form of their email address. I would still be curious to hear from anyone who has input on running clone_member to change 200-300 addresses, as part of a nightly cron job.

find_member accepts regexps. 

There are a few examples of how to change this sort of thing. You
might find my quick-and-dirty googlemail->gmail script [2] something
to work from. You might find creagting that request as a new thread
might garner more responses.

[2] http://blog.amyl.org.uk/2010/06/mailman-googlemail-to-gmail/ (step
2 could trivially be done progmatically)

-- 
"There seems to be something wrong with our bloody ships today"
    -- David, Vice-Admiral Beatty (re: the Battle of the Jutland)