I run a low-volume mailing list (using Mailman 2.1.12) and I see that a few spam-messages have gotten through, which also means they're archived. I would like to remove them but all the info I can find when searching online are along the lines of "hard to do", "shouldn't be attempted", "impossible" and so on. Is this correct, or is there a solution?
Perhaps it helps to say that for the past two months (September and October) each of those only contains one message each, and they're spam. Other months contain a mix of spam and legitimate messages.
Hal
On 11/07/2017 01:29 AM, Hal via Mailman-Users wrote:
I run a low-volume mailing list (using Mailman 2.1.12) and I see that a few spam-messages have gotten through, which also means they're archived. I would like to remove them but all the info I can find when searching online are along the lines of "hard to do", "shouldn't be attempted", "impossible" and so on. Is this correct, or is there a solution?
man mmarch
I haven't done this in forever but IIRC the scary hard to do impossible part is editing the mbox file without messing it up, not exactly rocket science.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 11/07/2017 10:41 AM, Dimitri Maziuk wrote:
On 11/07/2017 01:29 AM, Hal via Mailman-Users wrote:
I run a low-volume mailing list (using Mailman 2.1.12) and I see that a few spam-messages have gotten through, which also means they're archived. I would like to remove them but all the info I can find when searching online are along the lines of "hard to do", "shouldn't be attempted", "impossible" and so on. Is this correct, or is there a solution?
man mmarch
Which is apparently some packager's version of Mailman's bin/arch
I haven't done this in forever but IIRC the scary hard to do impossible part is editing the mbox file without messing it up, not exactly rocket science.
This method, editing the cumulative archive mbox and rebuilding the archive is the "best" way, but it is not without caveats.
The FAQ at https://wiki.list.org/x/4030681 describes this method and it's caveats along with the method of just editing or removing the HTML files.
Note that removing the HTML files leaves broken links in the various index files. It is better to just edit out the "body".
However, whatever you do to the HTML doesn't affect the periodic .txt(.gz) files unless you edit those too.
If you want to remove the Subject: headers from the index files, this is possible to do properly with the script at https://www.msapiro.net/scripts/hdfix (mirrored at https://fog.ccsf.edu/~msapiro/scripts/hdfix, but the best way to remove stuff from the archive without side effects is to edit the message bodies and perhaps subjects in the cumulative archive mbox, check the mbox with Mailman's bin/cleanarch and maybe https://www.msapiro.net/scripts/check_arch (mirrored at http://fog.ccsf.edu/~msapiro/scripts/check_arch), and then run Mailman's bin/arch --wipe.
But read the FAQ at https://wiki.list.org/x/4030681 in it's entirety including all the notes and caveats.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/08/2017 06:00 PM, Mark Sapiro wrote:
On 11/07/2017 10:41 AM, Dimitri Maziuk wrote:
man mmarch
Which is apparently some packager's version of Mailman's bin/arch
well, given /bin/arch and its importance to packagers and such, you'd have to agree that bin/arch was perhaps not the best choice of name. ;)
Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 11/08/2017 04:19 PM, Dimitri Maziuk wrote:
On 11/08/2017 06:00 PM, Mark Sapiro wrote:
On 11/07/2017 10:41 AM, Dimitri Maziuk wrote:
man mmarch
Which is apparently some packager's version of Mailman's bin/arch
well, given /bin/arch and its importance to packagers and such, you'd have to agree that bin/arch was perhaps not the best choice of name. ;)
All of Mailman 2.1's command line tools are distributed in Mailman's bin/ directory. What users/packagers do from there such as symlinking them from /usr/local/bin or whatever is up to them.
I was only trying to say that the OP might not have a mmarch command or man page for it.
In MM 3 this changes. All supported tools are sub-commands of one 'mailman' command.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Dimitri Maziuk writes:
well, given /bin/arch and its importance to packagers and such, you'd have to agree that bin/arch was perhaps not the best choice of name. ;)
Yup, and pretty sure Mailman's was first. There's a reason why namespaces were invented.
<img src="animated_shade_in_sky.gif">
On 2017-11-10 01:06, Stephen J. Turnbull wrote:
Dimitri Maziuk writes:
well, given /bin/arch and its importance to packagers and such, you'd have to agree that bin/arch was perhaps not the best choice of name. ;)
Yup, and pretty sure Mailman's was first. There's a reason why namespaces were invented.
Heh. You made me look. No, contrary to the popular belief LiGNUx did not invent the world, nor did mailman invent "arch". Sunos had it since forever, but it appears nobody else did. Somehow it made its way into linux and apparently everyone's been trying to get rid of it ever since. Including sunos. <useless things I learn over Saturday morning coffee/>
Dima
On 11/11/17 13:17, Dimitri Maziuk wrote:
Heh. You made me look. No, contrary to the popular belief LiGNUx did not invent the world, nor did mailman invent "arch". Sunos had it since forever, but it appears nobody else did. Somehow it made its way into linux and apparently everyone's been trying to get rid of it ever since. Including sunos.
Heh, I just looked at that myself. How did such a useless tool ever become standard?
-- Phil Stracchino Babylon Communications phils@caerllewys.net phil@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
On 2017-11-11 12:22, Phil Stracchino wrote:
Heh, I just looked at that myself. How did such a useless tool ever become standard?
My guess is IIRC SunOS was on Solaris 8 by 2001, and it was *the* grown-up 64-bit unix: every other unix vendor's keeled over or was about to and x86_64 didn't exist. So it was a standard utility on the standard unix by the time when posix decided in 2001 The Standard Shall Be That Other Thing. Good thing about standards, as we all know, is there's plenty to choose from.
Dima
On 11/11/2017 11:04 AM, Dimitri Maziuk wrote:
On 2017-11-11 12:22, Phil Stracchino wrote:
Heh, I just looked at that myself. How did such a useless tool ever become standard? My guess is IIRC SunOS was on Solaris 8 by 2001, and it was *the* grown-up 64-bit unix: every other unix vendor's keeled over or was about to and x86_64 didn't exist. So it was a standard utility on the standard unix by the time when posix decided in 2001 The Standard Shall Be That Other Thing. Good thing about standards, as we all know, is there's plenty to choose from.
arch(1) dates back to at least SunOS 4.0, ca 1987. I haven't been able to find manual pages before that.
The competitor, "uname -m", dates back at least that far, in the System V branch of UNIX - it's in the SVID in 1986.
Much before that you find the "machid" system-type commands, e.g. the "vax" command that succeeds on a vax and fails on all other systems. (and: sun, iAPX286, i386, m68k, pdp11, sparc, u3b, u3b2, u3b5, u3b15.) Those are still present at SunOS 4.0, but not in SVID. (Strangely, I don't see them in BSD 4.x. I dimly remember them existing in a BSD derivative ca 1985.)
UNIX v7 (my manual © 1979, 1983) does not have any of those. I suspect that at that time there was only Zool. Er, PDP-11.
So I think the simple answer is that both the Sun/Berkeley fork and the AT&T/SysV fork realized the need for a better answer than the "machid" commands, and independently invented different answers.
On 2017-11-11 18:34, Jordan Brown wrote:
arch(1) dates back to at least SunOS 4.0, ca 1987. I haven't been able to find manual pages before that.
The competitor, "uname -m", dates back at least that far, in the System V branch of UNIX - it's in the SVID in 1986.
...
So I think the simple answer is that both the Sun/Berkeley fork and the AT&T/SysV fork realized the need for a better answer than the "machid" commands, and independently invented different answers.
By the time posix committee got to writing the standard about the only other unix vendors left standing were ibm and sun. So they picked the big iron way.
Whereas I've never seen an aches box in use in a cs department. It's all sparks. My guess is cs students playing with linux were shaping it the sunos way simply because of that. And by then a decade's worth of sunos shell scripts that called /bin/arch.
(Sun ran a 50% educational discount since I got to write purchase orders and until they went amd and lost the profit margin.)
Dima
On 11/11/2017 2:04 PM, Dimitri Maziuk wrote:
On 2017-11-11 12:22, Phil Stracchino wrote:
Heh, I just looked at that myself. How did such a useless tool ever become standard?
[snip]
Dimitri Maziuk writes:
Heh. You made me look. No, contrary to the popular belief LiGNUx did not invent the world,
There is no such thing as LiGNUx. Stallman may have his fingers in a lot of software (to my everlasting annoyance; he wrote, and at last check circa 2013 continues to write, some of the most unmaintainable and uncomposable crap), but he didn't invent the world either (he does seem to have independently invented #AlternativeFacts, though).
nor did mailman invent "arch".
Independent invention, apparently. :-)
Sunos had it since forever, but it appears nobody else did. Somehow it made its way into linux
If it is in POSIX, as Phil implies, that would explain it. By the time it made it into Linux distros, most of them were pretty serious about POSIX compatibility.
and apparently everyone's been trying to get rid of it ever since. Including sunos.
Do you have a citation for this history? I like to collect
<useless things I learn over Saturday morning coffee/>
ha ha
-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
Steve:
On 11/12/2017 23:37, Stephen J. Turnbull wrote:
Dimitri Maziuk writes:
Heh. You made me look. No, contrary to the popular belief LiGNUx did not invent the world,
There is no such thing as LiGNUx. Stallman may have his fingers in a lot of software (to my everlasting annoyance; he wrote, and at last check circa 2013 continues to write, some of the most unmaintainable and uncomposable crap), but he didn't invent the world either (he does seem to have independently invented #AlternativeFacts, though).
Everybody knows that the correct term is Glunix; Lignux is just one of Glunix's lugnuts. In re RMS's coding and cognitive style, it's possible that you just don't see the big picture. * Anyway, I think there are a few million people around the world who are aware of his contribution to freedom of computation. I've heard of Japan, but not Professor Turnbull nor even Tsukuba. Amoris umbra invidia.
Btw, I find 'incompossible' and 'uncompilable' but not your neologism.
- If his coding is no longer up to snuff maye it's because he's devoting his attention to even more important matters.
ed
nor did mailman invent "arch".
Independent invention, apparently. :-)
Sunos had it since forever, but it appears nobody else did. Somehow it made its way into linux
If it is in POSIX, as Phil implies, that would explain it. By the time it made it into Linux distros, most of them were pretty serious about POSIX compatibility.
and apparently everyone's been trying to get rid of it ever since. Including sunos.
Do you have a citation for this history? I like to collect
<useless things I learn over Saturday morning coffee/>
ha ha
On 11/13/2017 06:03 PM, eminmn wrote:
Steve:
On 11/12/2017 23:37, Stephen J. Turnbull wrote:
Dimitri Maziuk writes:
> Heh. You made me look. No, contrary to the popular belief LiGNUx did not > invent the world,
There is no such thing as LiGNUx. Stallman may have his fingers in a lot of software (to my everlasting annoyance; he wrote, and at last check circa 2013 continues to write, some of the most unmaintainable and uncomposable crap), but he didn't invent the world either (he does seem to have independently invented #AlternativeFacts, though).
Everybody knows that the correct term is Glunix; Lignux is just one of Glunix's lugnuts.
Actually, I was commenting on Stephen's "pretty sure Mailman's was first" -- some other mail man's might have been, but this GNU Mailman's wasn't.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 07/11/17 19:41, Dimitri Maziuk wrote:
On 11/07/2017 01:29 AM, Hal via Mailman-Users wrote:
I run a low-volume mailing list (using Mailman 2.1.12) and I see that a few spam-messages have gotten through, which also means they're archived. I would like to remove them but all the info I can find when searching online are along the lines of "hard to do", "shouldn't be attempted", "impossible" and so on. Is this correct, or is there a solution?
man mmarch
I haven't done this in forever but IIRC the scary hard to do impossible part is editing the mbox file without messing it up, not exactly rocket science.
So you're saying it's *NOT* hard to do? I looked up "mmarch" and came up with this page which really didn't make me much wiser: http://manpages.ubuntu.com/manpages/xenial/man8/mmarch.8.html
I also tried to log into the server and believe they're located somewhere here: /var/lib/mailman/archives/private/
unfortunately I'm unable to access that location ("permission denied") for some reason, so I'm contacting the server owner about that. But several years ago I did a lot of work cleaning up and importing archived messages from before I moved over to Mailman and made backups of said directory and it seems I have two main directories:
/var/lib/mailman/archives_BACKUP/private/LISTNAME/ and /var/lib/mailman/archives_BACKUP/private/LISTNAME.mbox/
The "LISTNAME.mbox/" directory contains a single "LISTNAME.mbox" file while the "LISTNAME/" directory contains a variety of files and sub-directories by month. I suppose I have to clean things up in both of those paths? In the former, if a certain month only contains spam message (i.e. no legit postings at all), can I just delete the following for instance and be done with it?
rm -riv 2017-October/ rm -iv 2017-October.txt rm -iv 2017-October.txt.gz
That would still leave spam in the "mbox" file, but at least when browsing through the archives via the web interface they wouldn't see any spam there.
Hal
On 11/11/2017 02:28 PM, Hal via Mailman-Users wrote:
I also tried to log into the server and believe they're located somewhere here: /var/lib/mailman/archives/private/
That's where they should be.
unfortunately I'm unable to access that location ("permission denied") for some reason,
It is not uncommon for /var/lib/mailman/archives/private/ to not be readable/searchable by other than the web server user or Mailman's group.
Whatever is done, needs to be done by someone with write access to that directory.
so I'm contacting the server owner about that. But several years ago I did a lot of work cleaning up and importing archived messages from before I moved over to Mailman and made backups of said directory and it seems I have two main directories:
/var/lib/mailman/archives_BACKUP/private/LISTNAME/ and /var/lib/mailman/archives_BACKUP/private/LISTNAME.mbox/
That's correct, but of course the back ups would not have any more recent posts.
The "LISTNAME.mbox/" directory contains a single "LISTNAME.mbox" file while the "LISTNAME/" directory contains a variety of files and sub-directories by month. I suppose I have to clean things up in both of those paths?
That depends. The easiest way to do it completely and correctly is to edit the LISTNAME.mbox/LISTNAME.mbox file and replace the spam bodies with "spam removed" or some such text and similarly for the Subject: headers, but leave the edited messages there so messages aren't renumbered when you do the next step.
Then rebuild the archives in the LISTNAME/ directory with Mailman's
bin/arch --wipe LISTNAME
(Mailman's bin/arch is what Dimitri referred to as mmarch)
You might review this entire thread beginning at https://mail.python.org/pipermail/mailman-users/2017-November/082712.html including https://mail.python.org/pipermail/mailman-users/2017-November/082722.html which refers you to https://wiki.list.org/x/4030681 which discusses all the options in detail.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/11/17 00:19, Mark Sapiro wrote:
On 11/11/2017 02:28 PM, Hal via Mailman-Users wrote:
unfortunately I'm unable to access that location ("permission denied") for some reason,
It is not uncommon for /var/lib/mailman/archives/private/ to not be readable/searchable by other than the web server user or Mailman's group.
Whatever is done, needs to be done by someone with write access to that directory.
Would adding me as a member to the Mailman group be the "safest" option? Safest meaning that the web-server owner not having to risk me messing up the whole server or something, while still letting me do cleanup work (or anything else related to the list configuration etc)?
so I'm contacting the server owner about that. But several years ago I did a lot of work cleaning up and importing archived messages from before I moved over to Mailman and made backups of said directory and it seems I have two main directories:
/var/lib/mailman/archives_BACKUP/private/LISTNAME/ and /var/lib/mailman/archives_BACKUP/private/LISTNAME.mbox/
That's correct, but of course the back ups would not have any more recent posts.
Yes, true. But being able to access those backups gave me some insight in the file/folder structure. I'll be sure to make backups of everything before messing around with the new postings as well.
The "LISTNAME.mbox/" directory contains a single "LISTNAME.mbox" file while the "LISTNAME/" directory contains a variety of files and sub-directories by month. I suppose I have to clean things up in both of those paths?
That depends. The easiest way to do it completely and correctly is to edit the LISTNAME.mbox/LISTNAME.mbox file and replace the spam bodies with "spam removed" or some such text and similarly for the Subject: headers, but leave the edited messages there so messages aren't renumbered when you do the next step.
Excellent suggestion! Does this apply even if say October only contains one posting, which is spam? Would that mess up the next month's postings (if any)?
Then rebuild the archives in the LISTNAME/ directory with Mailman's
bin/arch --wipe LISTNAME
(Mailman's bin/arch is what Dimitri referred to as mmarch)
You might review this entire thread beginning at https://mail.python.org/pipermail/mailman-users/2017-November/082712.html including https://mail.python.org/pipermail/mailman-users/2017-November/082722.html which refers you to https://wiki.list.org/x/4030681 which discusses all the options in detail.
Thanks. Just what I needed. I see it's well explained, but I'll probably read it through a few times before attempting to do this due to the complexity.
I read about the Mailman 3 development and I'm wondering if chances are that it'll ever become a matter of "point & click" to maintain such a mailing list, or will there always be the need to "deep dive" with UNIX commands and other complexities?
Hal
On 11/11/2017 03:58 PM, Hal via Mailman-Users wrote:
On 12/11/17 00:19, Mark Sapiro wrote:
Whatever is done, needs to be done by someone with write access to that directory.
Would adding me as a member to the Mailman group be the "safest" option? Safest meaning that the web-server owner not having to risk me messing up the whole server or something, while still letting me do cleanup work (or anything else related to the list configuration etc)?
It would allow you to do what you need (and to "mess up" Mailman ;) without giving you root or sudo.
That depends. The easiest way to do it completely and correctly is to edit the LISTNAME.mbox/LISTNAME.mbox file and replace the spam bodies with "spam removed" or some such text and similarly for the Subject: headers, but leave the edited messages there so messages aren't renumbered when you do the next step.
Excellent suggestion! Does this apply even if say October only contains one posting, which is spam? Would that mess up the next month's postings (if any)?
The issue is that every message in the archive has a URL. Those URLs contain a sequence number. If you delete messages from the .mbox and rebuild, the sequence numbers and hence the URLs of the subsequent messages change. If someone has a link to one of those messages, it no longer points to the correct one.
If you don't care about this, you can delete messages from the .mbox, but if you want the URLs to be stable, you can't.
I read about the Mailman 3 development and I'm wondering if chances are that it'll ever become a matter of "point & click" to maintain such a mailing list, or will there always be the need to "deep dive" with UNIX commands and other complexities?
We're working on it. The MM 3 core engine is controlled by a RESTful HTTP API. The GNU Mailman project also includes web applications for list management (Postorius) and archiving (HyperKitty), but these are not required. You can build your own and others may be contributed in the future.
The current state of Postorius is many list settings are still not exposed there. Enough is to make lists that work, but things are missing that currently would need to be set by command line tools.
HyperKitty is quite functional. It's message and thread URLs are stable and predictable, and you can delete archived messages via the web UI.
We wiil eventually get to a point where everything can be managed via a web UI.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12/11/17 02:10, Mark Sapiro wrote:
On 11/11/2017 03:58 PM, Hal via Mailman-Users wrote:
On 12/11/17 00:19, Mark Sapiro wrote:
Would adding me as a member to the Mailman group be the "safest" option?
It would allow you to do what you need (and to "mess up" Mailman ;) without giving you root or sudo.
Hopefully I won't be doing that, but if I do I won't mess up the entire server ;-) Your (and others') comments on how to solve all this has been very helpful. I'll look closer into it when the server owner gives me access and hopefully nobody else needs to see that spam.
I read about the Mailman 3 development and I'm wondering if chances are that it'll ever become a matter of "point & click" to maintain such a mailing list, or will there always be the need to "deep dive" with UNIX commands and other complexities?
We're working on it.
Mailman 3 sounds very promising. Is Postorius and HyperKitty a part of that installation or are we talking different software? Updates and additional software installations are done by the server owner, but once I spend the time to figure out what to download from where, I understand it's not such a huge and complex job to actually go ahead and install it for him.
I'm sure the new version will be announced here :-)
Oh, you mentioned that HyperKitty could be used to delete archived messages via the web user-interface. This would of course solve my initial problem of deleting those spam messages in a simple and quick way without entering the UNIX terminal.
Hal
On 11/14/2017 03:44 AM, Hal via Mailman-Users wrote:
Mailman 3 sounds very promising. Is Postorius and HyperKitty a part of that installation or are we talking different software?
Mailman 3 is much more modular than Mailman 2.1 There is a core list management engine that can run by itself, receive and distribute messages and do other functions. User's can subscribe and unsubscribe by email.
The core engine can be configured and lists created, etc. via shell commands and/or via a RESTful HTTP API which would normally only be exposed on the local host and is not suitable for end user (subscriber, list admin) use.
The GNU Mailman project also provides end user, web based tools for list administration, user subscription, etc. (this is Postorius) and archiving (this is HyperKitty). These are optional, but are part of the entire suite of tools.
Currently, no packagers are providing Mailman 3 packages (Debian is known to be working on it), but presumably, packages would include Postorius and HyperKitty or alternatives.
One of our developers, Abhilash Raj, maintains Docker container images for Mailman 3 which include Postorius and HyperKitty. See http://docs.list.org/en/latest/prodsetup.html#mailman-3-in-docker for info.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2017-11-11 17:19, Mark Sapiro wrote:
On 11/11/2017 02:28 PM, Hal via Mailman-Users wrote: ...
The "LISTNAME.mbox/" directory contains a single "LISTNAME.mbox" file while the "LISTNAME/" directory contains a variety of files and sub-directories by month. I suppose I have to clean things up in both of those paths?
The latter is auto-generated from the former by the (bin/|mm)arch.
That depends. The easiest way to do it completely and correctly is to edit the LISTNAME.mbox/LISTNAME.mbox file and replace the spam bodies with "spam removed" or some such text and similarly for the Subject: headers, but leave the edited messages there so messages aren't renumbered when you do the next step.
Note that this only really matters if you think/know people have hyperlinks to archived messages *and* you care about not breaking those links. E.g. this link would be broken if the messages get renumbered:
You might review this entire thread beginning at https://mail.python.org/pipermail/mailman-users/2017-November/082712.html ...
However if Mark said "you might review the entire thread titled 'Removing archived spam' at https://mail.python.org/pipermail/mailman-users/2017-November/thread.html" it wouldn't be a problem.
I think in terms of teh amount of work involved there is no much difference between deleting the entire message from .mbox file vs. deleting only the body and updating the subject. So you might as well do it right: Mark's way.
Dima
Just had to do it today. I chose method #1 - just deleted an URL that was probably used for phishing from two messages.
https://wiki.list.org/DOC/How%20do%20I%20edit%20the%20archives%20of%20a%20Ma...
On Mon, Nov 6, 2017 at 10:29 PM, Hal via Mailman-Users < mailman-users@python.org> wrote:
I run a low-volume mailing list (using Mailman 2.1.12) and I see that a few spam-messages have gotten through, which also means they're archived. I would like to remove them but all the info I can find when searching online are along the lines of "hard to do", "shouldn't be attempted", "impossible" and so on. Is this correct, or is there a solution?
Perhaps it helps to say that for the past two months (September and October) each of those only contains one message each, and they're spam. Other months contain a mix of spam and legitimate messages.
Hal
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/ma ilman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/james% 40dorydesign.com
participants (10)
-
Carl Zwanzig -
Dimitri Maziuk -
eminmn -
Hal -
Jim Dory -
Jordan Brown -
Mark Sapiro -
Phil Stracchino -
Richard Shetron -
Stephen J. Turnbull