Barry> In principle, I like more general solutions and hooks for Barry> extensibility than hard-coding in external dependencies like Barry> this.
Like this? Since the Mailman UI is a bunch of HTML forms, put the GUI control for third party archiving on the internet.
Configuration Categories * [General Options] * Passwords * Language options * Bounce processing * Membership Management... * Local archiving * Non-digest options * Third party archiving * Digest options * Mail<->News gateways
List admin clicks on [Third party archiving], which is special hyperlink  that goes to a mailman controlled dynamic webpage, perhaps on or redirected through list.org.
Third party archiving
Archive the list publicly on The Mail Archive? [No] [Yes]
Archive the list publicly on MARC? [No] [Yes]
Set as primary archive? [None] [Mail-Archive] [MARC]
[Submit Your Changes]
When the user clicks on the submit button, the form POST goes back to the mailman GUI and sets the appropriate functionality. There are two main advantages to this approach. First, it provides a global deadman switch. Second, the feature gracefully degrades. The web page can can say "not implemented yet" or "feature disabled". It can hold manual instructions, honest to god tightly integrated GUI controls, or a combination of the above.
Of course now the Mailman is kind of on the hook for keeping something up and running on the internet, which is kind of a pain. But as Lars said, this is something that archival services can help with.
 The hyperlink would be a little bit fancier than normal, and since it would need to embed some information about the location of the mailman installation. For example, if mailman was set up on foo.com, then $FORM_POST_URL would be the form submission location on foo.com, e.g.. http://foo.com/mailman/admin/list1/thirdpartyarchiving
<a href=http://list.org/mailman17?arg=$FORM_POST_URL> Third Party Archiving</a>