On Wed, Mar 28, 2012 at 9:20 AM, Jeff Breidenbach <jeff@jab.org> wrote:

...

archivers are configured site-wide, so there's almost nothing to expose in the web-ui.

I'm worried about confusion.

Indeed. I think Barry misspoke here. But remember, we're barely out of alpha test, and we don't actually have a standard archiver, just a simple handler to support further development.

The last thing we want is for a list to be accidentally archived contrary to the list administrator's wish. It sounds scary to me not to have any indication whatsoever in the web interface.

However, this is unavoidable, since in an open-subscription or confirm-only list anybody can request Gmane or mail-archive.com to subscribe, and of course users will save their mail in many cases.

I think it's arguable that it's best to archive everything (eg, so you can demonstrate that a particular piece of spam did or did not come through your list), and lock it down at the archive-viewer level.

Along similar lines, there seems opportunity for confusion if there are two independent mechanisms for archival; site wide configuration and also manually subscribing an archival subscriber

Personally, I think only the latter should be provided by default since it can't easily be prevented unless the list owner vets all subscribers very carefully (including having access to their .forwards!) Of course individual sites or lists can provide their own archiving handlers, and for the purpose of developing archivers and archive browsers offline, it may be useful to have a simple archive-to-maildir handler. (Note that the usual MTA/MDA suites can be used to deliver to maildirs, so for a list that's actually online, to get a local archive you just set up a $LIST-archiver virtual user delivering to maildir. AFAICS, this will be sufficiently efficient.)