Subject: MHonArc archives to be retired?

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 15 Feb 2018 05:47:56 -0800

Greetings. I got this update to an issue that I had opened about a year 
ago:

Forwarded message:

> From: ietfdb issue tracker <[email-masked]>
> To: [email-masked], [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietfdb] #2227 (MailArchive: User Interface): Lack of 
> text wrapping makes MHonArc archive unusable
> Date: Thu, 15 Feb 2018 05:32:57 -0000
>
> #2227: Lack of text wrapping makes MHonArc archive unusable
>
> Changes (by [email-masked]):
>
>  * status:  new => closed
>  * resolution:   => wontfix
>
>
> Comment:
>
>  The MHonArc archive will soon be retired.
>
> -- 
> ------------------------------------------+-----------------------------
>   Reporter:  [email-masked]        |      Owner:  
> [email-masked]
>       Type:  defect                       |     Status:  closed
>   Priority:  n/a                          |  Milestone:  (None)
>  Component:  MailArchive: User Interface  |    Version:  6.x.x
> Resolution:  wontfix                      |   Keywords:
> ------------------------------------------+-----------------------------

Was there an IETF / IAOC decision to retire the MHonArc archive? The new 
mail archiver still has some pretty serious faults for those of us who 
need to skim WG archives by date.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Feb 2018 13:51:47 +0000

> Greetings. I got this update to an issue that I had opened about a year

Add me to the list who would not like to see the mhonarc archives
retired. While I do like the new one, I also often prefer the old
one.

S

>>   Reporter:  [email-masked]        |      Owner:  [email-masked]

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Feb 2018 09:47:34 -0500

Yeah, me too -- I find the mh ui much nicer (and it also seems a: tp
produce nicer URLS for links, and b: we have existing links to
messages).

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Feb 2018 09:56:24 -0500 (EST)

> produce nicer URLS for links, and b: we have existing links to

I also only use the mhonarc archives, as the new one is pretty
but lacking in basic functionality.

Paul

---

From: Lou Berger <[email-masked]>
Date: Thu, 15 Feb 2018 09:56:53 -0500

It would be good to capture/report any issues you have with the new tool 
so that it can be addressed before the old archives go away.  The 
biggest issue that I've heard is yet to be address is speed to 
access/browse a WG archive -- which interestingly enough I don't see in 
the open tickets [1]...

Lou

[1] 
https://trac.tools.ietf.org/tools/ietfdb/query?status=assigned&status=deployed&status=new&status=reopened&component=MailArchive%3A+User+Interface&group=priority&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&report=27&order=priority

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 15 Feb 2018 10:33:58 -0500

I also much prefer the MHonArc archives and would not like to see it go away.

On Thu, Feb 15, 2018 at 9:56 AM, Lou Berger <[email-masked]> wrote:
> It would be good to capture/report any issues you have with the new tool so
> that it can be addressed before the old archives go away.  The biggest issue
> that I've heard is yet to be address is speed to access/browse a WG archive
> -- which interestingly enough I don't see in the open tickets [1]...

I find it easier to follow email threads, the linkage between them and
how easy it is to pick a single message out of the thread are some of
the reasons for me.  It's the visual access, so I haven't opened a
ticket as I think it's not as easy to replicate.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Feb 2018 11:06:56 -0500

> On Feb 15, 2018, at 10:33 AM, Kathleen Moriarty <[email-masked]> wrote:
> 

Major improvements were made in the last release,  Have you looked recently?

If so, and you still find the new tool lacking, pease enter a ticket.

Russ

---

From: Tim Chown <[email-masked]>
Date: Thu, 15 Feb 2018 15:54:17 +0000

> I also much prefer the MHonArc archives and would not like to see it go away.

Agreed.

> ticket as I think it's not as easy to replicate.

Again, I agree.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Feb 2018 11:09:50 -0500

> -- which interestingly enough I don't see in the open tickets [1]...

a) mhonarc is just plain faster, particularly when you know what you want.
   Subjectively it's molasses vs rockets, I have no objective measurements,
   because I use them differently.

b) time-sequence reading is better with mhonarc.
c) it's obvious how to link to an entire thread, and to move around it.

d) just yesterday, I tried to search for a thread I knew existed, but my
   keywords did not find anything.  Why, because the thread was prior was
   about creating the TLA, and we didn't use the TLA yet :-)
   I resorted to scanning the subject lines via IMAP, which took about
   2 minutes and found the thread I cared about.

e) the mailarchive is also slow because it is too responsive and keeps doing
   new searches, when really I just want to wander through what it's already
   returned.

I don't see how I can open bugs about these, because they are about
fundamental design decisions.

I think that many of us are happy that we have the Archived-At: headers
in place, and that it's all subject to full text search.

And I think that it is 80% of the actual under-the-covers moving parts, but
we really want the results of the search to be links into the mhonarc to
read.  (And some people would like imap: links I think)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 15 Feb 2018 11:14:08 -0500

> Major improvements were made in the last release,  Have you looked recently?

Yes, I use both somewhat regularly with checks on SecDir reviews to
see if there are responses to reviews.  I find it much easier to
quickly see if there was a response and to follow the thread with
HMonArc.  I'll try again to see if I can come up with helpful
suggestions on how to improve the interface and visuals.

-- 

Best regards,
Kathleen

---

From: Tony Finch <[email-masked]>
Date: Thu, 15 Feb 2018 17:13:07 +0000

> produce nicer URLS for links, and b: we have existing links to

The mhonarc archives should only be retired if there are
redirects to the new archives for each message.

Also the new UI ought to be a lot faster - getting the index
for a mailing list takes about 30 seconds (e.g.
https://mailarchive.ietf.org/arch/search/?email_list=dnsop)
whereas the mhonarc interface is basically instant.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Cyclonic 5 or 6. Rough or very rough. Rain or sleet. Moderate or
poor.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 15 Feb 2018 12:51:38 -0500

Perhaps a silly question, but why retire the MHonArc archives at all?

- Lots of lists run multiple archives

- I've been running MHonArc archives on a few dozen lists, for decades - 
with pretty much zero attention required - they just run themselves; 
they don't even take up that much disk space

It's not like there's a serious burden in keeping the MHonArc archives - 
in administrative labor, or disk space (not a lot of images or large 
files on the IETF lists) - so why not just keep them running?

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Feb 2018 13:23:15 -0500

For almost everything I do, HMonArc provides a vastly superior
interface. Trying to figure out what's going on with the new interface
and its tiny weeny little scrolling window feels like trying to figure
out what is in a room by looking through a keyhole as opposed to
simply walking into the room and seeing what's there. It is only in
the extraordinarily rare case that I actually want to do a key word
search or the like across multiple WG mailing lists that the new
interface might be better.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Feb 2018 14:06:09 -0500

> Perhaps a silly question, but why retire the MHonArc archives at all?

The goal is to save only once copy of the mail archives for all purposes. Current practices involve duplicate stores, which impact storage and replication and are subject to inconsistency.  Also, if the Secretariat is asked to remove a spam message from the archives, it must be done in multiple places.

The full answer is captured in RFC 6778.

Russ

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 16 Feb 2018 08:08:17 +1300

> files on the IETF lists) - so why not just keep them running?

Exactly. Even though the new archive is constantly improving, its UI and
underlying concept are so fundamentally different to MHonArc that it
can *never* do what MHonArc does best (and vice versa). Don't fight it.
Run both. Make everybody happy.

Regards
   Brian Carpenter
   Department of Computer Science
   The University of Auckland
   http://www.cs.auckland.ac.nz/~brian/

(I am currently sending all mail from this address
due to a Gmail bug. I can still receive via Gmail.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 15 Feb 2018 11:30:13 -0800

On 15 Feb 2018, at 11:06, Russ Housley wrote:

> The goal is to save only once copy of the mail archives for all 
> purposes. Current practices involve duplicate stores, which impact 
> storage and replication and are subject to inconsistency.  Also, if 
> the Secretariat is asked to remove a spam message from the archives, 
> it must be done in multiple places.
>

That's a full answer to his question, but not mine. Was there a decision 
(from the IAOC or IESG) to retire the MHonArc archives? If so, a pointer 
to that would be useful.

FWIW, RFC 6778 mentions MHonArc once:

    There are many existing archived messages containing embedded links
    into the existing MHonArc [MHonArc] mail archive.  These links must
    continue to work, but they should reach the message as archived in
    the new system.

To me, that goes against the idea of retiring the archives.

--Paul

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Feb 2018 14:35:53 -0500

On 2/15/2018 1:23 PM, Donald Eastlake wrote:
> simply walking into the room and seeing what's there

This is my experience as well.  Very well stated.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 15 Feb 2018 13:43:46 -0600

On 2/15/18 1:30 PM, Paul Hoffman wrote:
> That's a full answer to his question, but not mine. Was there a 
> decision (from the IAOC or IESG) to retire the MHonArc archives? If 
> so, a pointer to that would be useful.
This (getting to a single source of truth for the archives) is something 
we have been working towards since we started on the project that 
RFC6778 informed was started. We occasionally think we're close, and 
assess, and find we need to do more before we switch fully to that 
single source of truth. That happened recently, where we (the tools 
development team) discussed the beginning of an idea to create static 
pages much more like the mhonarc pages that can be _recreated_ on demand 
when the single source of truth changes. That will require more 
development effort, and we are planning on discussing the feasibility 
of  that while in London. There is no decision to remove Mhonarc right 
away. We _will_ have a discussion with the community before it is 
retired. The ticket closure that started this thread was unfortunately 
terse - sorry for the apprehension it has raised.

> To me, that goes against the idea of retiring the archives.
Read it more carefully. Note that it says "reach the messages as 
archived in the new system". It was there to support the abilithy to 
retire Mhonarc in the long run.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 15 Feb 2018 15:20:42 -0500

> To me, that goes against the idea of retiring the archives.

Good point.  +1

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 15 Feb 2018 15:27:34 -0500

> The full answer is captured in RFC 6778.
Ok - removing spam is an issue - but, again, from personal experience, 
with good filters, and list posting only by list members, spam is a very 
rare event (potentially copyright infringement takedown requests might 
be more common).  But it's pretty easy to remove that rare message (at 
least in the implementation I'm running).

RFC6778 actually calls for redundancy, not de-duplication.  And, in any 
case, RFC6778 seems to be a rather old document, Informational only, and 
the product of a single individual.  Not the greatest justification for 
removing an archive that has been working well, for many years, for 
apparently quite a few people.

One might ask, who is making this decision, how, and is it 
representative of the greater community of folks who use the archives?

Miles Fidelman

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Feb 2018 15:45:58 -0500

Miles:
> 
> And, in any case, RFC6778 seems to be a rather old document, Informational only, and the product of a single individual.

That does not accurately represent the situation.  Robert Sparks held the pen to capture the requirements, and then the document went through an IETF-wide Last Call and IESG review.

The requirements captured in RFC 6778 have guided the Tools Team throughout the development of the mail archive tool.  As you have already seen on this thread, improvements are being worked right now.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Feb 2018 21:08:23 +0000

On 15/02/18 19:43, Robert Sparks wrote:
> We _will_ have a discussion with the community before it is retired.

That's good enough for me, thanks.

I'm sure you'll weigh the input from this thread as you get to that.
FWIW, I'd echo those who've said they like the speed, simplicity and
'overview' provided by mhonarc archives. I think the only (v. minor)
thing I'd add is that sometimes I've had to page through archives to
get back in time to a mail I wanted to find but about which I'd
forgotten most things (incl. subject, author etc:-) other than e.g.
"it was just before that big barney about <foo>" or some other
oddball context:-) Happens rarely, but the fact that most mhonarc
web pages cover a good range of dates for most lists makes that
kind of thing possible.

I do also appreciate the new UI's keyword search and a bunch of it's
other features too.

Cheers,
S.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 15 Feb 2018 13:10:14 -0800

On 15 Feb 2018, at 11:43, Robert Sparks wrote:

> There is no decision to remove Mhonarc right away. We _will_ have a 
> discussion with the community before it is retired.

Thank you.

> The ticket closure that started this thread was unfortunately terse - 
> sorry for the apprehension it has raised.

Not just the wording, but the fact that a long-standing problem that 
people have with the way we use MHonArc is now being actively ignored.

--Paul Hoffman

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 15 Feb 2018 16:32:18 -0500

On 2/15/18 3:45 PM, Russ Housley wrote:

> Miles:
>>
>> And, in any case, RFC6778 seems to be a rather old document, 
>> Informational only, and the product of a single individual.
>
> That does not accurately represent the situation.  Robert Sparks held 
> the pen to capture the requirements, and then the document went 
> through an IETF-wide Last Call and IESG review.
>
> The requirements captured in RFC 6778 have guided the Tools Team 
> throughout the development of the mail archive tool.  As you have 
> already seen on this thread, improvements are being worked right now.
>
>
Ok.  Fair enough.  (Particularly when you add RFC 7842).

But... then I'll point back to the observation that the only reference 
to deduplication is in the intro - "

The current archive mechanism could also be made more efficient.  The current practices involve duplicate stores (for the web and ftp
interfaces), which impact storage and replication and are subject to inconsistency."
While there is an extensive section on redundancy.

And the requirement for keeping the MhonArc links working.

One might argue that maintaining the MhonArc archive serves both requirements, while removing it requires new mechanisms.

Leading to a follow-up question:  What was the design review process?  Was there one?
RFC6778 & RFC 7842 may be fully coordinated & reviewed requirements documents.  Has the tools team produced a similarly
detailed and coordinated design document?

Now, this is a bit after the fact, so patently unfair to raise now - but somehow, Mailman + a custom archiving system seems like a rather
convoluted approach to improving the IETF's list environment.  If it were me, I would have replaced mailman with Sympa, years ago - fully integrated
MhonArc comes with it - along with a simple interface for removing messages without changing lots of files.  Seems like an awful lot of
folks have gone to an awful lot of work, buildings something custom - when off-the-shelf, open source solutions were available.

Miles

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Feb 2018 16:53:38 -0500

> Major improvements were made in the last release, Have you looked

I used it yesterday.  It was different I noticed.
Not better, just more confusing to me.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Feb 2018 16:57:46 -0500

Donald Eastlake <[email-masked]> wrote:
    > out what is in a room by looking through a keyhole as opposed to simply
    > walking into the room and seeing what's there.

That's pretty much how I feel, and my browser window is 2K x 1K in size, an
entire monitor.  Thank you for the very apt analogy -- it catches my feelings
exactly.

I think that one thing that might help is if there was an easier way to get
the WG list buttons clicks on the left, and also if there was a "submit" or
"update" button so that it wasn't updating underneath me while I'm still
adding constraints.   The update is never instantaenous so I find that it's
always jumping around doing new searches while I'm just trying to absorb what
the previous results were.

Maybe the designer needs to visit s/he grandparent and see how well they use
the interface.  And do it on a higher latency link.

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2018 20:52:44 -0500

>Major improvements were made in the last release,  Have you looked recently?

I'll send in a ticket but just in a minute or two here's some:

* very slow, just took 10 seconds to return the first result

* in the common case where I know which list I want to look at, telling
it which list is really painful.  Is there a way to bookmark a search
with the list already chosen?

* options often don't work.  Do a search from the main page for
"elliptic curve", in the result page FILTER BY LIST and FILTER BY FROM
are in the left margin but have no options and you can't click on them

* Click the Thread button, wait 10 seconds, I guess there's threads in that
little Subject pane but they're a lot harder to follow than in the old
mhonarc display

I do sometimes appreciate the ability to search across the whole
archive, but that's not usually what I want to do.

R's,
John

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 16 Feb 2018 15:06:52 +1300

On 16/02/2018 14:52, John Levine wrote:
...
> archive, but that's not usually what I want to do.

Exactly. I'd say the trickiest searches I ever need to do are ones where
I remember that in about (e.g.) 2012, somebody on (e.g.) v6ops wrote about
a particular issue. But I don't know the subject header in use and I can't
really give keywords or dates that are specific enough.

Scanning a complete list of thread titles month by month, in a single
full size window, is by far the quickest way. MHonArch supports this nicely.

None of this is to say that the new archive is a bad thing.

Regards
   Brian

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2018 20:52:10 -0500

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 16 Feb 2018 07:57:09 -0500

On Thu, Feb 15, 2018 at 11:09:50AM -0500, Michael Richardson wrote:
[ a bunch of excellent observations ]

> fundamental design decisions.

I strongly concur.  But apparently the preferred direction is now for
pretty, glitzy, complex, and slow over baseline, simple, fast, necessary
functionality that can be accessed via text-only browers and command lines.

And this:

> (And some people would like imap: links I think)

As well as links to complete downloadable copies of the entire archives
of the mailing list in mbox format.

Of course there is abolutely no reason whatsoever why archives can't
be presented in multiple formats and regenerated as necessary from
the original sources (e.g. the mbox files).  Writing Makefile rules
and running them via daily cron jobs suffices to rebuild when necessary
with a maximum latency of 24 hours.

---rsk

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Feb 2018 08:11:02 -0500

> with a maximum latency of 24 hours.

+1 for this. For kicks, I rsync'ed the archives yesterday and played with 
mhonarch - 15G and 5 minutes of effort leads me to conclude this is very 
reasonable. BTW according to the ietf sync page updates are available every 
4 hours...

Lou

---

From: Russ Housley <[email-masked]>
Date: Fri, 16 Feb 2018 15:33:34 -0500

> with the list already chosen?

I use this URL for the its mail list:
https://mailarchive.ietf.org/arch/search/?email_list=its <https://mailarchive.ietf.org/arch/search/?email_list=its>

Russ

---

From: "John R Levine" <[email-masked]>
Date: 16 Feb 2018 15:53:50 -0500

> https://mailarchive.ietf.org/arch/search/?email_list=its <https://mailarchive.ietf.org/arch/search/?email_list=its>

Seems reasonable.  Too bad we don't have links like that on the WG pages.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2018 16:15:01 -0500

>of the mailing list in mbox format.

mbox, urrgh.  There is a perfectly good IMAP archive of all of our
lists, one folder per list.  If you want to copy a whole list into an
mbox file, that's about three keystrokes in most MUAs.

By the way, the IMAP server works quite well.  If you have an MUA that
can do IMAP searches (most of them) give it a try.

R's,
John

PS: does the IMAP server use the same back end archive as mhonarc, the
new archive, or a separate copy?

---

From: Russ Housley <[email-masked]>
Date: Fri, 16 Feb 2018 16:31:52 -0500

> new archive, or a separate copy?

The IMAP server runs off the same archive as the mail search tool.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Feb 2018 15:43:02 -0600

> can do IMAP searches (most of them) give it a try.

Hmm, last time I tried, I failed to convince either alpine or mutt
to talk to the IMAP server.  Is there a wiki page or something where
a known-good configuration lives?

Unrelatedly, I kind-of expected a minority of folks who would be
unhappy that the new mail archive requires javascript in order to
function, though I don't remember anyone mentioning that yet.
(For myself, if the MHonArc archives go away, I'm likely to treat
that as a forcing function to get something talking to the IMAP
server insted of enabling javascript, though of course I do not
expect anyone else to do so.)

-Ben

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 17 Feb 2018 13:32:42 +1300

> Seems reasonable.  Too bad we don't have links like that on the WG pages.

Yes, good idea and should be easy. Will you raise a ticket?

    Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Feb 2018 20:37:29 -0500

> On Feb 16, 2018, at 3:33 PM, Russ Housley <[email-masked]> wrote:
> 
> https://mailarchive.ietf.org/arch/search/?email_list=its

This is MUCH slower to load the initial page than going to the old-style list
archive.  Frankly if a web search accidentally takes me to the new archive I
redo the search until I find the corresponding old page.  I've found the
new interface sufficiently usable.  My primary browser has javascript turned
off by default.  I don't think any quantity of tickets will make the new UI
more usable for me.  The old stuff is faster, simpler and requires no JS.
The battle is over without a single shot being fired.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2018 23:11:41 -0500

>a known-good configuration lives?

This works for me in the folder-collections list in alpine.

	IETF "{imap.ietf.org/novalidate-cert/user=[email-masked]}Shared Folders/[]",

There's no INBOX, but there's lots of folders.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 18 Feb 2018 11:00:29 -0500

> mbox file, that's about three keystrokes in most MUAs.

Agreed, but that means that it can't be done via a script
that just picks up the updates via rsync...and use of rsync's
bandwidth-limiting feature (--bwlimit) is critical for me, and
likely for anyone else who is on the far side of a slow connection.

Besides, Mailman maintains an archive of every list in mbox format
anyway, so the cost of creating it is zero.  If the root of the Mailman
tree is /var/local/mailman, and the mailing list is "fubar", then:

	/var/local/mailman/archives/private/fubar.mbox/fubar.mbox

has everything.  (Yes, the redundancy in the URL really is there.)
All that's necessary is to either make that accessible or -- probably a
better idea for both utility and security -- to rsync the entire ensemble
of all mboxes to a single exposed directory so that it's trivial to rsync
(or http/ftp) one list or ten of them or all of them at once.  If the local
rsync is done once an hour by cron that's easily good enough to keep
this repository updated.  And after the first time, it'll run in seconds.

Here's a script that does just that; salt to taste:

--------------------------
#!/bin/bash

outputdir=/var/local/www/html/lists
mailmanbin=/usr/local/mailman/bin
mailmanvar=/var/local/mailman
rsyncflags=-vaHx

mlists=$($mailmanbin/list_lists -b)

for i in $mlists
do
	mbox=$mailmanvar/archives/private/$i.mbox/$i.mbox
	rsync $rsyncflags $mbox $outputdir
done
--------------------------

---rsk