-------- Original-Nachricht --------
Datum: Sat, 5 Dec 2009 10:26:11 -0800
Von: Michael S. [email protected]
An: [email protected]
Betreff: Re: Nginx securiy problem
Sorry you’re right. “Installing” it to me means not just unpacking or
apt-getting but also getting it initially setup.
That is configuration/setup and something totally different.
And why is that an issue? You normally don’t mess with the installed
files. You just edit mm_cfg.py and that’s it.
Whenever you need to migrate? Ever had to migrate a mailman install
from one server to another? What about one distro to another? With
different paths on each machine?
YES! Once my distro of choice had the great idea in moving the whole
mailman file structure to another one. I first messed it up totally but
today I could in no time move from one FS structure to another. I did it
once wrongly, failed, learned and now I know. And yes. I have moved from
server A to server B as well. One of my systems got so borked up that I
needed to replace it. And I did it. Not only did I move the mailman
installation/list from server A to server B. No! I have moved from
server A to a cluster server B and server C. Was death easy. The only
thing that I needed to think about is how to make the various cron
scripts to be cluster aware. That’s it. Mailman on its own was easy.
Running now on two cluster nodes that both have a clustered FS
(GlusterFS) where all the mailman stuff is sitting.
All fine and dandy for a web application. But mailman can run without a
web server.
Sure, it can, as will mine. But the easiest way to manage everything
will be from a web UI, and nowadays, who really makes a fuss about
having to use a web UI? 
If the tool was from the start written for the Web then it’s okay. But
most tools are written for the console and then later on top of that
they add an Web UI. In general the Web UI has then less possibilities
then doing it from the command line. And this is what I don’t like.
times have you needed to go on the server and change options in the
command line for mailman after you have installed and configured it?
Well, I’ve had to run it in a “high-security” mode where I stripped
out attachments and some other stuff and the options to do this were
quite confusing. I was almost too scared to allow it to be used, as it
could have cost all of us our jobs for using it if any confidential
document got attached and somehow snuck through.
Ha! Don’t tell me that. I run two lists that need to be ABSOLUTELY
anonymous and no information about the sender nor any attachment is
allowed to sneak through. Attachment stripping is easy in mailman. But
the anonymity? ULTRA BAD! It does hide the sender but still you could
look at the headers of the mail and see who sent it. Enter Postfix.
Thanks to Postfix and the great possibility found in Postfix I can
filter out as much as I like. I can even plug stuff into the delivery
chain that allows me to change every single bit inside a mailman
message. Stripping headers: No problem. Generating a new message id: no
problem. Stripping attachments: No problem. etc, etc, etc…
However yes all that was done before deployment, but it also did not
give me a lot of confidence if post-deployment we found a small glitch
and had to go into panic mode to see if it could be fixed.
And how would a Web UI have prevented that panic mode?
Regarding the one file of changes, I have tried that route and it
still didn’t seem to get it all right for me. Maybe I was doing it
wrong but that’s the whole point of it. Why would something as simple
as editing a configuration file be difficult or wrong?
I don’t know? I have that little file there with a bunch of
configuration options and that’s it. I don’t fiddle around with it. I
don’t remember when I have touched that beast the last time?
are in different places, etc.
You don’t need to run bin/newlist, bin/withlist and I don’t know what
else. From within the mailman Web UI you can create, delete, modify new
lists all the time. No need to fuss around with the binaries. Okay,
okay. If you change the host for the archive from hostA to hostB then
you might have your hard time doing that in the Web UI but how often do
you do that? I mean the change is done easy in the Web UI but the
migration of pipermail/archives can’t be IMHO done from within the Web
UI.
And beside that: We are in 2009! No one is just fiddling around on the
server without having a proper release to management environment. So you
test the stuff in dev/test, then you document it, then you install in
pre-poduction/acceptance and if all is going fine then you go on and
deploy it in production. If anything happens in the production then the
documentation written by you before going to production should have +/-
all the steps needed to redo all your work on another system. And if you
ever need to move from server A to server B then you make a copy of the
mailman installation from production and install that stuff in dev/test
and try there until you are confident enough to do the step.
While testing a possible migration path you write everything down and
there you are. You have validated a possible migration and you have a
documentation describing how to do it.
Bring on that thing 
It sounds like you have a fine grip on mailman, but I am tired of
having to deal with the pain of configuration and such and the little
tweaks here and there. I would like to re-work it to emulate a more
modern style of package like WP, Drupal, phpList, etc.
Ach! It’s as with many things in life. You see that great thing of
software and then you thing: I need that!
Then you download and install it. Then you try to configure it and you
fail. Okay. Back to documentation. Reading. Not understanding everything
you follow blindly some How-To you have found on the net. Damn! Again
not working. Okay. Another How-To. Hmm… it works. Somehow. I don’t
understand what it does but it works. Good! I am happy. I use the
product.
Then later (months, maybe years have passed) you need to touch that
thing again. Ohhh boy. You don’t understand what is going on but now you
NEED to make it working. A gazillion of customers are using it and you
can’t just bring it down and fiddle around with it for days. It should
work NOW. Ahh. Sorry. YESTERDAY! And you idiot did not understood it
when you installed/configured it and now you pay for that ignorance.
Damn!
But time has passed by and you not only have lost some hair on your head
but you are more confident with all the tools you are using and this
time reading the documentation of mailman gives you AHA OOH now I
understand etc… and then things start to become clear and they settle
in your brain. From now on touching mailman is not any more black magic
but something you know how to handle and where to tweak it in order to
get things done.
Why not utilizing the MTA to do that? I have on my mailman installation:
SPF, Sender ID, DKIM, Anti-Virus, Anti-Spam (using mainly DSPAM but have
CRM114 and OSBF-Lua as well), Hashing (DCC, Pyzor, Razor), selective
greylisting (SQLGrey, GROSS), various blocking features (mainly
policyd-weight patched to use p0f, GeoIP (allowing me to penalize by
country, distance (YES! Little nice addition I have written after
reading this here:
http://www.technologyreview.com/communications/23086/), by continent,
etc), S25R (http://www.gabacho-net.jp/en/anti-spam/paper.html), etc,
etc…) and and and…
I think it would take you ages to get mailman to be on par with the
possibilities a full blown up MTA is giving you. So for me the logical
consequence is: Fully use mailman as much as possible but don’t try to
make it do something that it is not build for and that my MTA could do
light years better then mailman could ever do.
Also the source code will be freely available and written in PHP,
which will have a large audience of people who can contribute and
enhance it and keep it alive. Worst case, it goes nowhere, but at
least I’m giving it a shot. I know a few places I can implement it
quite easily and it will help gain some traction immediately.
While doing that code you will quickly realize that some limitations you
are facing now will not vanish if you abstract mailman in a Web UI.
Fundamental design flaws can’t always be fixed with a nice GUI. You can
definitely work around some design issues and handle that in the GUI but
don’t expect the mailman crew to be strict with their design flaws. They
will fix and reorder things and you will hunt them. You will mostly be
one or more step behind them. Some time you will be in front of them but
that will happen rarely. And after some time doing this hunting you will
come to the point asking yourself: Why am I doing this? WHY?
Funny, when looking at it quick, I just noticed this bug with mailman:
Bug #490114 “Mailman should be compliant with the Filesystem Hie...” : Bugs : GNU Mailman

LOL. That’s a good one 
nginx mailing list
[email protected]
nginx Info Page
–
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox
3.5 -
sicherer, schneller und einfacher! Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX