mail archives

Bruce Dawson jbd at codemeta.com
Mon Jan 31 10:27:00 EST 2005


...

>There were a couple of other posts regarding this problem as well.
>
>What I have gleaned from all of this is that:
>
>
>1: upgrading mailman on the existing archive server is never going to
>happen because of technical difficulties related to Python2 and the
>fact that this is a production server that Bruce can't risk
>destabilizing.  The fact that newer software is available that offers
>features/bugfixes is inconsequential.
>  
>
The problems with python2 have been resolved, and there is a later 
version of mailman on that system. However, this has exposed a problem 
with "moving" a list from one version of mailman to a later version. 
After corrupting the mailman database while trying to move a test list, 
I decided it couldn't be done in the time I had. I believe I even sent a 
message to the -org list indicating this and soliciting help. None came.

See http://mail.gnhlug.org/mailman/private/gnhlug-org/2004-April/001009.html

>2:  (1) is irrelevant anyways since this wasn't the actual problem
>that started all of this.
>  
>
No single problem started the problems with the mailing list thread 
(take your pick as to which thread you want to talk about). There are 
several problems that people want to solve. Unfortunately, their 
recommended changes to mailman (if any - and I believe no one on any of 
our lists has tried to fix mailman) were not accepted into any of the 
distributions I've monitored for the past several years.

Because many clients (and a number of them actually pay for the service) 
use mailman on these systems, I can't just patch mailman (or the 
/etc/aliases, or /etc/mail/virtusertable, or ...) without handling the 
time consuming  operation of repatching after a new version of the 
system, mailman, python, ... comes through the "standard" distribution 
channels!

>3: We can't even re-configure the discussion list to reply back to
>the list because this will cause further destabilization and we all
>know that this will cause a big flamewar anyways.
>  
>
That wasn't the reason we can't reconfigure. The reason is that several 
people want it configured in mutually different ways. As we have 
discovered (witness this thread), a flame-war erupts every time the list 
gets reconfigured.

If we had the lists configured so that the return address is always the 
list, then this whole discussion would not occur - no individual address 
would appear anywhere. However, a number of people indicated they 
sometimes wanted to respond to just the poster.

>4: Offers of technical assistance (in response to requests for
>assistance) (such as scripts to obfuscate email addresses) are clearly
>not deemed to be helpful.
>  
>
Usually because they cause more problems than they solve. I have taken 
some people's offers of assistance because they really do assist, and I 
have given one or two that I really trust access to the system's admin 
account. How do I come to trust you? By having a low "signal-to-noise" 
ratio in your postings, and your postings indicate your depth of 
knowledge of the subject. Of course, this has to occur at a consistent 
level for a period of years.

>   (Speaking for myself, it feels like every single level-headed
>suggestion that I have offered on this topic has been greeted with a
>swift kick in the teeth.  You're welcome...)
>  
>
I believe "a swift kick in the teeth" would have been simply 
blacklisting your address on the list.  On the other hand, if you meant 
your scripts/solutions were not accepted into the mainline process as a 
swift kick, then I apologize for not publicly responding with a reason 
your scripts could not be implemented.

By the way, could you please provide a link (within the archives) to the 
message that had your scripts in it?

>6: Anybody who volunteers to put together their own archive should
>take care to not to include in this archive the email that in actually
>caused the original archive to go private in the first place.  Most of
>the list only has clues as to what this email might have been (myself
>included).  So, until we know more, it would probably be best to just
>throw away any any archives that existed before today.
>  
>
You must not trust anyone on this list - especially those who implement 
software, to be careful with the mailbox-format files I provide them 
with as test data. Although, I honestly don't think I've provided any 
within the past 18 months.

>So, it appears like we need an alternate mail archive server.  Several
>folks have offered suggestions;  I guess that we'll have to
>investigate these.  The suggestion of gmane.org was particularly
>interesting to me, but this needs more investigation (I note right
>from the start that gmane.org's web site says "Gmane requires that
>users post to Gmane groups using a valid e-mail address") which might
>put off certain Gnhlug member(s).
>  
>
I have it on my (growing) to-do list to look at gmane.org once I return 
to the states. However, if someone gets to it before me, then the GNHLUG 
community will be better served!

However, I want to encourage as many people as want to act as archivers. 
This way we can survey all the possibilities, and adopt the best for our 
needs. Once we decide to select one, then we can provide the prior archives.

I know there are several archives of this list "out there" that people 
don't want others on this list to know about for fear of getting flamed.

>LAST THING: regarding your "Real World" point of argument.  At no
>point in this discussion have I ever put forth the notion that running
>a mail archive server is easy (in terms of time, expense, headaches,
>etc.).  In reality, my only goal from the start of this thread has
>been to make the existing mail archives more useful.  I have even
>offered working code towards this goal.  I think that Bruce has
>performed a tremendously valuable service by hosting the archives.  I
>believe that I have even sent Bruce mail in the past thanking him for
>hosting these archives (if not, I would like to publicly say "thanks!" 
>right now).  I believe that this renders any complaints that you have
>regarding my unfamiliarity with the Real World baseless.
>
Thanks for noticing my contribution (or rather: my company's).  However, 
many people aren't aware of the Real World constraints on running a 
multiple customer server directly connected to the internet, and I 
haven't seen many of the "solutions" posted by others addressing these 
constraints.

Your scripts may have addressed some of them, but I can't seem to find 
them anywhere. I seem to remember someone posting some scripts "a long 
time ago", and I looked at them and discovered that they were lacking in 
some important "real world" ways, and then got refocused on something 
else. I'm sorry if I didn't provide sufficient follow-up.

--Bruce




More information about the gnhlug-discuss mailing list