Frequent use of clone_member
Hello,
We are changing student email from mailboxes, to forwarding addresses. Among other challenges, we are exploring various ways to deal with students who are subscribed to closed (only subscribers may post) mailing lists.
(There are a lot of similar challenges when switching to an email forwarding model - any list members who have gone through this, I would love to pick your brain!)
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@our.domain new@outside.domain
We could end up processing as many as 500 address changes nightly (running clone_member for each one), with each run of clone_member iterating through all mailing lists. I'm concerned that this is much more than clone_member was intended for.
Can Mailman developers or heavy uses of Mailman comment on this?
Thanks very much,
Ivan.
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@our.domain new@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.
How about having the forwarding address setup update accept_these_nonmembers, instead?
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.
HI Stephen,
-----Original Message----- From: Stephen J. Turnbull [mailto:stephen@xemacs.org] Sent: Thursday, October 21, 2010 10:13 PM To: Ivan Fetch Cc: mailman-users@python.org Subject: [Mailman-Users] Frequent use of clone_member
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@our.domain new@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. We have some mailing lists which are maintained by professors - although students know they are subscribed to the course mailing list, they haven't tended to manage those subscriptions.
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 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.
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.
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.
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.
Thanks,
Ivan.
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@our.domain new@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@lists.example.edu
foo-forwarding@lists.example.eduwhere "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)
participants (3)
-
Adam McGreggor -
Ivan Fetch -
Stephen J. Turnbull