Diskussion:Arbeitsgruppe Mailinglisten

Aus Freiheit statt Angst!

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
Aktuelle Version (07:03, 10. Jul. 2009) (bearbeiten) (rückgängig)
(vandal revert)
 
(Der Versionsvergleich bezieht 35 dazwischen liegende Versionen mit ein.)
Zeile 1: Zeile 1:
-
== Mailman Update ==
+
<p>Cool site goodluck&nbsp;:)
-
Eventuell könnte ein Update von Mailman Verbesserungen bringen?
+
</p>
-
Veränderungen seit der hier benutzten Version 2.1.5 -> http://pastebin.com/m2b64da2
+
<h2> Mailman Optimierung </h2>
-
(oder in der NEWS Datei der aktuellen version)
+
<p>Wurden schon "performance monitoring &amp; analysis" und entsprechende Optimierungen durchgeführt?
-
 
+
(z.B.: local DNS caching -&gt; http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq06.008.htp, usw.)
-
== Mailman Optimierung ==
+
</p><p>Wenn ich mir die Seite zu maximale Mailman Listengröße unter
-
Wurden schon "performance monitoring & analysis" und entsprechende Optimierungen durchgeführt?
+
http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.015.htp
-
(z.B.: local DNS caching -> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.008.htp, usw.)
+
-
 
+
-
Wenn ich mir die Seite zu maximale Mailman Listengröße unter
+
-
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.015.htp
+
anschaue und dazu lese
anschaue und dazu lese
-
 
+
</p>
-
For example, one mailing list managed
+
<pre class="_fck_mw_lspace">For example, one mailing list managed
-
by Mailman has had up to 3000 subscribers, and often receives
+
by Mailman has had up to 3000 subscribers, and often receives
-
100 messages in a day (i.e., hundreds of thousands of daily
+
100 messages in a day (i.e., hundreds of thousands of daily
-
deliveries). The list runs on a low-end Pentium with 48MB of
+
deliveries). The list runs on a low-end Pentium with 48MB of
-
RAM. The machine runs sendmail on GNU/Linux."
+
RAM. The machine runs sendmail on GNU/Linux."
-
...
+
</pre>
-
 
+
<p>...
-
If you're going to be running lists with more than a few thousand members, then you need to have a thorough
+
</p>
-
understanding of how your MTA and Mailman work, and a deep and intimate familiarity with Internet e-mail in
+
<pre class="_fck_mw_lspace">If you're going to be running lists with more than a few thousand members, then you need to have a thorough
-
general. And of course, you will have to carefully consider how best to tune your MTA and Mailman to work best
+
understanding of how your MTA and Mailman work, and a deep and intimate familiarity with Internet e-mail in
-
together. If you're missing any of these prerequisites, you're in for a difficult time."
+
general. And of course, you will have to carefully consider how best to tune your MTA and Mailman to work best
-
 
+
together. If you're missing any of these prerequisites, you're in for a difficult time."
-
scheint eine Optimierung des bestehenden Systems eine echte Alternative zum Umzug zu sein.
+
</pre>
-
[[Benutzer:Exc|Exc]] 21:45, 31. Mai 2008 (CEST)
+
<p>scheint eine Optimierung des bestehenden Systems eine echte Alternative zum Umzug zu sein.
-
 
+
<a href="Benutzer:Exc">Exc</a> 21:45, 31. Mai 2008 (CEST)
-
 
+
</p>
-
'''Technik-Diskussion von der Arbeisgruppen-Hauptseite verschoben:'''
+
<dl><dd> Nicht, wirklich, da ich an dem Sytem nicht herumbasteln will <a href="Benutzer:WernerH">Werner</a> 13:45, 16. Jan. 2009 (CET)
-
[[Benutzer:Validom|ValiDOM]] 17:08, 20. Nov. 2008 (CET)
+
</dd></dl>
-
 
+
<p><br />
-
=Technik=
+
<b>Technik-Diskussion von der Arbeisgruppen-Hauptseite verschoben:</b>
-
Der Mailinglistenserver hat große Lags, was kann man tun?
+
<a href="Benutzer:Validom">ValiDOM</a> 17:08, 20. Nov. 2008 (CET)
-
 
+
</p>
-
== Beschreibung der aktuellen Situation ==
+
<h2> Moderatoren-Team </h2>
-
* Derzeitige Hardware: 1&1 Rootserver XL => AMD 4000 Dualcore, 2GB RAM
+
<p>Was ist genau die Aufgabe des Moderatoren-Teams?
-
* Mehrere Projekte auf dem Server, AK Vorrat wohl das größte.
+
(ausser Begrüssungstexte etc. erstellen)--<a href="Benutzer:Rka">rka</a> 10:57, 29. Nov. 2008 (CET)
-
* Mailverzögerung derzeit ca. 2h
+
</p>
-
* Systemprotokolle? Munin-Graphen?
+
<ul><li> Ich erlaube mir das mal Stichpunktartig zu um-reißen
-
 
+
<ul><li> Das <b>Admin-Team</b>:
-
== Evaluieren der Ursache ==
+
<ul><li> Einrichten und Löschen von Mailinglisten
-
 
+
</li><li> Eintragen/Ändern von Moderatoren für div. OG/RG-Listen
-
Beispiel von "normalen" Laufzeiten im Oktober:
+
</li><li> Administrieren von Mailinglisten (z.b. Mails von Nicht-Mitgliedern, zu großen Anhängen, zu vielen Empfängern etc. ablehnen oder durch gehen lassen)
-
 
+
</li><li> ggf. moderieren von Mailinglisten (wir haben derzeit aber keine moderierten Listen und es wird wohl einen Konsens/Abstimmung brauchen falls wir sowas mal haben wollen)
-
Received: from d-s-c.biz ([212.227.104.134] helo=p15198016.pureserver.info)
+
</li><li> Ansprechpartner bei Problemen mit den Listen
-
by xxx (envelope-from <ml-bounces@ak-vds.de>) id 1KvCpJ-0003KM-46
+
</li></ul>
-
for xxx; Wed, 29 Oct 2008 16:19:18 +0100
+
</li><li> Das <b>Moderatoren-Team</b>
-
Received: (qmail 12353 invoked from network); 29 Oct 2008 16:32:21 +0100
+
<ul><li> Bildet sich quasi aus den in OG/RG-Listen eingetragenen Moderatoren
-
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
+
</li><li> Erfüllen die o.g. Aufgaben für ihre "eigene" Liste, Ändern aber keine Moderatoren, legen keine Mailinglisten an usw.
-
by localhost with SMTP; 29 Oct 2008 16:32:21 +0100
+
</li></ul>
-
Delivered-To: 12-ml@ak-vds.de
+
</li></ul>
-
Received: (qmail 12106 invoked from network); 29 Oct 2008 16:32:19 +0100
+
</li><li> Ich hoffe, das ist aufschlussreich&nbsp;? --<a href="Benutzer:Validom">ValiDOM</a>
-
Received: from moutng.kundenserver.de (212.227.126.187)
+
</li></ul>
-
by ak-vds.de with SMTP; 29 Oct 2008 16:32:19 +0100
+
<h2>Technik</h2>
-
 
+
<p>Der Mailinglistenserver hat große Lags, was kann man tun?
-
(hier dürften allerdings leichte Uhrzeit-Unterschiede noch mitspielen)
+
</p>
-
 
+
<h3> Beschreibung der aktuellen Situation </h3>
-
aktuell sieht es so aus:
+
<ul><li> Derzeitige Hardware: 1&amp;1 Rootserver XL =&gt; AMD 4000 Dualcore, 2GB RAM
-
 
+
</li><li> Mehrere Projekte auf dem Server, AK Vorrat wohl das größte.
-
Received: (qmail invoked by alias); 16 Nov 2008 16:31:16 -0000
+
</li><li> Mailverzögerung derzeit ca. 2h
-
Received: from d-s-c.biz (EHLO p15198016.pureserver.info) [212.227.104.134]
+
</li><li> Systemprotokolle? Munin-Graphen?
-
by mx0.gmx.net (mx068) with SMTP; 16 Nov 2008 17:31:16 +0100
+
</li></ul>
-
Received: (qmail 27018 invoked from network); 16 Nov 2008 14:09:06 +0100
+
<h3> Evaluieren der Ursache </h3>
-
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
+
<p>Beispiel von "normalen" Laufzeiten im Oktober:
-
by localhost with SMTP; 16 Nov 2008 14:09:06 +0100
+
</p>
-
Delivered-To: 12-ml@ak-vds.de
+
<pre class="_fck_mw_lspace">Received: from d-s-c.biz ([212.227.104.134] helo=p15198016.pureserver.info)
-
Received: (qmail 26471 invoked from network); 16 Nov 2008 14:09:05 +0100
+
by xxx (envelope-from &lt;<span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode">ml-bounces@ak-vds.de</span>&gt;) id 1KvCpJ-0003KM-46
-
Received: from foxtrot372.server4you.de (85.25.141.154)
+
for xxx; Wed, 29 Oct 2008 16:19:18 +0100
-
by ak-vds.de with (DHE-RSA-AES256-SHA encrypted) SMTP;
+
Received: (qmail 12353 invoked from network); 29 Oct 2008 16:32:21 +0100
-
16 Nov 2008 14:09:05 +0100
+
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
-
 
+
by localhost with SMTP; 29 Oct 2008 16:32:21 +0100
-
Es müßte also sinnvollerweise mal geprüft werden, wie die Mailqueue auf dem Server selber aussieht - vielleicht sind mitlerweile einfach so viele Leute in den Mailinglisten, daß es zu einer großen Verzögerung kommt. Andere Gründe könnten aber auch in Fehlern in den DNS-Einträgen zu suchen sein, die aber allem Anschein nach ausgeschlossen sein sollten ...
+
Delivered-To: <span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode">12-ml@ak-vds.de</span>
-
 
+
Received: (qmail 12106 invoked from network); 29 Oct 2008 16:32:19 +0100
-
Optimierungsmöglichkeiten gibt es ggf. im Rahmen der Timeouts des Mail-Dienstes, damit nicht unnötig bei der Zustellung (zB bei greylisting-Servern etc.) gewartet wird, statt dessen halt später probiert wird ...
+
Received: from moutng.kundenserver.de (212.227.126.187)
-
 
+
by ak-vds.de with SMTP; 29 Oct 2008 16:32:19 +0100
-
== Evaluieren des Bedarfs ==
+
</pre>
-
 
+
<p>(hier dürften allerdings leichte Uhrzeit-Unterschiede noch mitspielen)
-
* Wieviele Mails gehen pro Stunde über den Server?
+
</p><p>aktuell sieht es so aus:
-
:*für AK-Vorrat: ca. 150 Mails pro Tag mal ca. 1000 Subscriber ~ 150.000/Tag ~ 6.000/Stunde
+
</p>
-
 
+
<pre class="_fck_mw_lspace">Received: (qmail invoked by alias); 16 Nov 2008 16:31:16 -0000
-
:** Das sind deutlich mehr, dass es ja über 20 Listen sind, die für den AK auf dem Maillinglistenserver laufen
+
Received: from d-s-c.biz (EHLO p15198016.pureserver.info) [212.227.104.134]
-
 
+
by mx0.gmx.net (mx068) with SMTP; 16 Nov 2008 17:31:16 +0100
-
* Werden sie auf Viren und auf Spam gecheckt?
+
Received: (qmail 27018 invoked from network); 16 Nov 2008 14:09:06 +0100
-
 
+
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
-
:* Nein, da ja nur Mails von Listenmitgliedern (und ausdrücklich erlaubten AbsenderInnen) verteilt werden, alle anderen werden automatisch verworfen.
+
by localhost with SMTP; 16 Nov 2008 14:09:06 +0100
-
::* Woran liegt es dann, dass auf der berlin@ täglich duzende Spammails aufschlagen?
+
Delivered-To: <span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode">12-ml@ak-vds.de</span>
-
 
+
Received: (qmail 26471 invoked from network); 16 Nov 2008 14:09:05 +0100
-
== Lösungsmöglichkeiten ==
+
Received: from foxtrot372.server4you.de (85.25.141.154)
-
 
+
by ak-vds.de with (DHE-RSA-AES256-SHA encrypted) SMTP;
-
* Kernfrage: Was ist zwischen Ende Oktober und jetzt passiert, was die Zustellung so ausbremst? --[[Benutzer:Garry|Garry]]
+
16 Nov 2008 14:09:05 +0100
-
 
+
</pre>
-
* Kann man Spam- oder Virenchecks bei einigen oder allen Listen unnötig machen, indem man z. B. keine Anhänge zulässt oder nur eingetragene Mitglieder Schreibrechte haben?
+
<p>Es müßte also sinnvollerweise mal geprüft werden, wie die Mailqueue auf dem Server selber aussieht - vielleicht sind mitlerweile einfach so viele Leute in den Mailinglisten, daß es zu einer großen Verzögerung kommt. Andere Gründe könnten aber auch in Fehlern in den DNS-Einträgen zu suchen sein, die aber allem Anschein nach ausgeschlossen sein sollten ...
-
 
+
</p><p>Optimierungsmöglichkeiten gibt es ggf. im Rahmen der Timeouts des Mail-Dienstes, damit nicht unnötig bei der Zustellung (zB bei greylisting-Servern etc.) gewartet wird, statt dessen halt später probiert wird ...
-
:* Das ist ja bereits so?
+
</p>
-
 
+
<h3> Evaluieren des Bedarfs </h3>
-
* Kann man den Server dahingehend optimieren, dass er die Checks nur bei eingehenden Mails vornimmt?
+
<ul><li> Wieviele Mails gehen pro Stunde über den Server?
-
 
+
</li></ul>
-
* Ist vielleicht ein dedizierter Server angebracht, etwa in Form eines Vservers (oder ggf. noch größere Kapazität)?
+
<dl><dd><ul><li>für AK-Vorrat: ca. 150 Mails pro Tag mal ca. 1000 Subscriber ~ 150.000/Tag ~ 6.000/Stunde
-
 
+
</li></ul>
-
:* Wieso sollte ein VServer mehr Kapazität haben, als ein Rootserver, der zu 98 % dem AK zur Verfügung steht.
+
</dd></dl>
-
 
+
<dl><dd><ul><li><ul><li> Das sind deutlich mehr, dass es ja über 20 Listen sind, die für den AK auf dem Maillinglistenserver laufen
-
::* Das ja doch ne ganze Menge Mails die der da verschicken muss, ich würde behaupten, dass da nen VServer auch schon stark in die Knie geht. Eine Auslastungsgraph vom CPU wäre sicherlich mal interessant, besonders wenn man irgendwie den Mailserver Prozess dabei betrachtet.
+
</li></ul>
-
::*'''Die CPU-Auslastung in Vservern ist meistens nicht das''', was einen Vserver in die Knie zwingt. Meistens sind es Resourcen wie gleichzeitig offene Verbindungen, gleichzeitig geöffnete Dateien / Sockets / Prozesse. Bei Server4free (Virtouzzo Vserver-Technologie) ist das alles auf 500 begrenzt. Das wird schnell verbraucht. Daher würde ich für den Mailinglisten_Server von der Vserver-Idee wirklich abraten. -[[Benutzer:Validom|ValiDOM]]
+
</li></ul>
-
* Es wäre denkbar, Provider anzusprechen, die bekennende Unterstützer des AK Vorrats sind (jpb, prima, ...)
+
</dd></dl>
-
* unschöne Variante: non digit ausschalten - jeder bekommt nur noch die Zusammenfassung am Tag
+
<ul><li> Werden sie auf Viren und auf Spam gecheckt?
-
:* Keine Lösung, da dann die Verzögerung ja noch länger ist
+
</li></ul>
-
* sofern die Kapazitäten was Speicher/CPU angeht, noch ausreichend Reserven hat, könnte man mehrere Queue-Prozesse parallel laufen lassen --[[Benutzer:Garry|Garry]]
+
<dl><dd><ul><li> Nein, da ja nur Mails von Listenmitgliedern (und ausdrücklich erlaubten AbsenderInnen) verteilt werden, alle anderen werden automatisch verworfen.
-
* Prüfen, ob einzelne Ziele die Zustellung unnötig lang verzögern - gestaffelte Queue-Verzeichnisse mit jeweils reduzierten Queuing-Frequenzen könnten in dem Fall die Zustellung der anderen Mails beschleunigen --[[Benutzer:Garry|Garry]]
+
</li></ul>
 +
<dl><dd><ul><li> Woran liegt es dann, dass auf der berlin@ täglich duzende Spammails aufschlagen?
 +
</li></ul>
 +
<dl><dd><ul><li> Auf keiner der Mailinglisten kommt SPAM durch, da bei allen Mailinglisten nur AbonnentInnen senden dürfen. Vermutlich sit <span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode">berlin@vorratsdatenspeicherung.de</span> gemeint gewesen, das ist aber keine Liste sondern ein offener Kontaktverteiler. <a href="Benutzer:WernerH">Werner</a> 13:44, 16. Jan. 2009 (CET)
 +
</li></ul>
 +
</dd></dl>
 +
</dd></dl>
 +
</dd></dl>
 +
<h3> Lösungsmöglichkeiten </h3>
 +
<ul><li> Kernfrage: Was ist zwischen Ende Oktober und jetzt passiert, was die Zustellung so ausbremst? --<a href="Benutzer:Garry">Garry</a>
 +
</li></ul>
 +
<dl><dd><ul><li> Ab und zu werden die Logfiles zu groß, dann wird die Zustellung ausgebremst.
 +
</li></ul>
 +
</dd></dl>
 +
<ul><li> Kann man Spam- oder Virenchecks bei einigen oder allen Listen unnötig machen, indem man z. B. keine Anhänge zulässt oder nur eingetragene Mitglieder Schreibrechte haben?
 +
</li></ul>
 +
<dl><dd><ul><li> Das ist ja bereits so?
 +
</li></ul>
 +
<dl><dd><ul><li> Genau <a href="Benutzer:WernerH">Werner</a> 13:44, 16. Jan. 2009 (CET)
 +
</li><li> Bei allen Listen werden nur Mails von eingetragenen Mitgliedern akzeptiert. Also muss Mailman bei jeder Mail an eine Liste schauen, ob der Absender in der Liste ist. Bei den SPAM-Mails ist dies dann nicht der Fall, die werden dann weggeschmissen. Aber solagen die Mailinglistenadressen im Klartext (also &lt;listname&gt;@ak-vds.de) veröffentlicht werden und nicht mit einem "[at]" statt dem "@", wird der SPAM von Tag zu Tag mehr.
 +
</li></ul>
 +
<dl><dd><ul><li> Wir könnten das umschreiben. Zum Beispiel mit <img src="/images/At.png" _fck_mw_filename="At.png" alt="" /> statt "@". Spricht etwas dagegen? --<a href="Benutzer:Roam">roam</a> 09:53, 25. Apr. 2009 (CEST)
 +
</li></ul>
 +
</dd></dl>
 +
</dd></dl>
 +
</dd></dl>
 +
<ul><li> Kann man den Server dahingehend optimieren, dass er die Checks nur bei eingehenden Mails vornimmt?
 +
</li></ul>
 +
<dl><dd><ul><li> Nein, denn der Server macht weder SPAM- noch Virencheck
 +
</li></ul>
 +
</dd></dl>
 +
<ul><li> Ist vielleicht ein dedizierter Server angebracht, etwa in Form eines Vservers (oder ggf. noch größere Kapazität)?
 +
</li></ul>
 +
<dl><dd><ul><li> Wieso sollte ein VServer mehr Kapazität haben, als ein Rootserver, der zu 98&nbsp;% dem AK zur Verfügung steht.
 +
</li></ul>
 +
</dd></dl>
 +
<dl><dd><dl><dd><ul><li> Das ja doch ne ganze Menge Mails die der da verschicken muss, ich würde behaupten, dass da nen VServer auch schon stark in die Knie geht. Eine Auslastungsgraph vom CPU wäre sicherlich mal interessant, besonders wenn man irgendwie den Mailserver Prozess dabei betrachtet.
 +
</li><li><b>Die CPU-Auslastung in Vservern ist meistens nicht das</b>, was einen Vserver in die Knie zwingt. Meistens sind es Resourcen wie gleichzeitig offene Verbindungen, gleichzeitig geöffnete Dateien / Sockets / Prozesse. Bei Server4free (Virtouzzo Vserver-Technologie) ist das alles auf 500 begrenzt. Das wird schnell verbraucht. Daher würde ich für den Mailinglisten_Server von der Vserver-Idee wirklich abraten. -<a href="Benutzer:Validom">ValiDOM</a>
 +
</li></ul>
 +
</dd></dl>
 +
</dd></dl>
 +
<ul><li> Es wäre denkbar, Provider anzusprechen, die bekennende Unterstützer des AK Vorrats sind (jpb, prima, ...)
 +
</li><li> unschöne Variante: non digit ausschalten - jeder bekommt nur noch die Zusammenfassung am Tag
 +
</li></ul>
 +
<dl><dd><ul><li> Keine Lösung, da dann die Verzögerung ja noch länger ist
 +
</li></ul>
 +
</dd></dl>
 +
<ul><li> sofern die Kapazitäten was Speicher/CPU angeht, noch ausreichend Reserven hat, könnte man mehrere Queue-Prozesse parallel laufen lassen --<a href="Benutzer:Garry">Garry</a>
 +
</li><li> Prüfen, ob einzelne Ziele die Zustellung unnötig lang verzögern - gestaffelte Queue-Verzeichnisse mit jeweils reduzierten Queuing-Frequenzen könnten in dem Fall die Zustellung der anderen Mails beschleunigen --<a href="Benutzer:Garry">Garry</a>
 +
</li></ul>
 +
<h2> Abschiedstext </h2>
 +
<dl><dd><i>Hallo, schade, dass Sie die Mailingliste abbestellt haben. Wir würden uns dennoch sehr freuen, wenn Sie uns auch weiterhin verbunden bleiben würden. Für Fragen und Meinungen kontaktieren Sie einfach .... </i>
 +
</dd></dl>
 +
<p>Ich finde den Abschiedstext der einzelnen Listen ziemlich schmierig. Klingt als hätte irgendein fieses Unternehmen gerade einen Kunden verloren.<br />
 +
Wenn wir uns auf der List duzen, so sollte das auch beibehalten werden wenn dort jemand aussteigt. Ausserdem ist die Gegenüberstellung "wir" auf der einen Seite und der angesprochene auf der anderen Seite, zumindest in diesem Zusammenhang schwierig weil es denjenigen ausschliesst.
 +
</p><p>Vorschlag (an dem wohl auch noch etwas gefeilt werden müsste):<br />
 +
<i>Schade, dass du die Mailingliste abbestellt hast. Es wäre dennoch schön wenn du unser Anliegen weiterhin unterstützen möchtest. Bei Fragen, Anregungen oder Kritik kannst du jederzeit .... kontaktieren.</i>
 +
</p><p>---<a href="Benutzer:Nic">Nic</a> 23:54, 15. Jan. 2009 (CET)
 +
</p><p>Vorschlag 2 (weiterfeilen):<br />
 +
<i>Schade, dass du die Mailingliste </i>Name<i> abbestellt hast. Es wäre dennoch schön, wenn wir in unserem Anliegen verbunden blieben.<br /> Fragen, Anregungen oder Kritik kannst du natürlich weiterhin an </i>kontakt<span class="fck_mw_template">{{at}}</span>vorratsdatenspeicherung.de<i> richten.</i>
 +
</p><p>--<a href="Benutzer:Peu">Peu</a> 18:27, 16. Jan. 2009 (CET)
 +
</p><p>Unterschiedliche Listen benötigen unterschiedliche Texte, bei Abmeldung von ml ist es beispielsweise sinnvoll auf announce zu verweisen. <a href="Benutzer:WernerH">Werner</a> 09:24, 25. Apr. 2009 (CEST)
 +
</p>

Aktuelle Version

Cool site goodluck :)

Inhaltsverzeichnis

Mailman Optimierung

Wurden schon "performance monitoring & analysis" und entsprechende Optimierungen durchgeführt? (z.B.: local DNS caching -> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.008.htp, usw.)

Wenn ich mir die Seite zu maximale Mailman Listengröße unter

http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.015.htp anschaue und dazu lese 

For example, one mailing list managed
by Mailman has had up to 3000 subscribers, and often receives
100 messages in a day (i.e., hundreds of thousands of daily
deliveries). The list runs on a low-end Pentium with 48MB of
RAM. The machine runs sendmail on GNU/Linux."

... 

If you're going to be running lists with more than a few thousand members, then you need to have a thorough  
understanding of how your MTA and Mailman work, and a deep and intimate familiarity with Internet e-mail in  
general. And of course, you will have to carefully consider how best to tune your MTA and Mailman to work best 
together. If you're missing any of these prerequisites, you're in for a difficult time."

scheint eine Optimierung des bestehenden Systems eine echte Alternative zum Umzug zu sein. <a href="Benutzer:Exc">Exc</a> 21:45, 31. Mai 2008 (CEST)

Nicht, wirklich, da ich an dem Sytem nicht herumbasteln will <a href="Benutzer:WernerH">Werner</a> 13:45, 16. Jan. 2009 (CET) </dd>


Technik-Diskussion von der Arbeisgruppen-Hauptseite verschoben: <a href="Benutzer:Validom">ValiDOM</a> 17:08, 20. Nov. 2008 (CET)

Moderatoren-Team

Was ist genau die Aufgabe des Moderatoren-Teams? (ausser Begrüssungstexte etc. erstellen)--<a href="Benutzer:Rka">rka</a> 10:57, 29. Nov. 2008 (CET)

  • Ich erlaube mir das mal Stichpunktartig zu um-reißen
    • Das Admin-Team:
      • Einrichten und Löschen von Mailinglisten
      • Eintragen/Ändern von Moderatoren für div. OG/RG-Listen
      • Administrieren von Mailinglisten (z.b. Mails von Nicht-Mitgliedern, zu großen Anhängen, zu vielen Empfängern etc. ablehnen oder durch gehen lassen)
      • ggf. moderieren von Mailinglisten (wir haben derzeit aber keine moderierten Listen und es wird wohl einen Konsens/Abstimmung brauchen falls wir sowas mal haben wollen)
      • Ansprechpartner bei Problemen mit den Listen
    • Das Moderatoren-Team
      • Bildet sich quasi aus den in OG/RG-Listen eingetragenen Moderatoren
      • Erfüllen die o.g. Aufgaben für ihre "eigene" Liste, Ändern aber keine Moderatoren, legen keine Mailinglisten an usw.
  • Ich hoffe, das ist aufschlussreich ? --<a href="Benutzer:Validom">ValiDOM</a>

Technik

Der Mailinglistenserver hat große Lags, was kann man tun?

Beschreibung der aktuellen Situation

  • Derzeitige Hardware: 1&1 Rootserver XL => AMD 4000 Dualcore, 2GB RAM
  • Mehrere Projekte auf dem Server, AK Vorrat wohl das größte.
  • Mailverzögerung derzeit ca. 2h
  • Systemprotokolle? Munin-Graphen?

Evaluieren der Ursache

Beispiel von "normalen" Laufzeiten im Oktober: 

Received: from d-s-c.biz ([212.227.104.134] helo=p15198016.pureserver.info) 
  by xxx (envelope-from <<span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode"><enkode>ml-bounces@ak-vds.de</enkode></span>>) id 1KvCpJ-0003KM-46
  for xxx; Wed, 29 Oct 2008 16:19:18 +0100
Received: (qmail 12353 invoked from network); 29 Oct 2008 16:32:21 +0100
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
  by localhost with SMTP; 29 Oct 2008 16:32:21 +0100
Delivered-To: <span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode"><enkode>12-ml@ak-vds.de</enkode></span>
Received: (qmail 12106 invoked from network); 29 Oct 2008 16:32:19 +0100
Received: from moutng.kundenserver.de (212.227.126.187)
  by ak-vds.de with SMTP; 29 Oct 2008 16:32:19 +0100

(hier dürften allerdings leichte Uhrzeit-Unterschiede noch mitspielen)

aktuell sieht es so aus: 

Received: (qmail invoked by alias); 16 Nov 2008 16:31:16 -0000
Received: from d-s-c.biz (EHLO p15198016.pureserver.info) [212.227.104.134]
  by mx0.gmx.net (mx068) with SMTP; 16 Nov 2008 17:31:16 +0100
Received: (qmail 27018 invoked from network); 16 Nov 2008 14:09:06 +0100
Received: from localhost (HELO p15198016.pureserver.info) (127.0.0.1)
  by localhost with SMTP; 16 Nov 2008 14:09:06 +0100
Delivered-To: <span class="fck_mw_special" _fck_mw_customtag="true" _fck_mw_tagname="enkode"><enkode>12-ml@ak-vds.de</enkode></span>
Received: (qmail 26471 invoked from network); 16 Nov 2008 14:09:05 +0100
Received: from foxtrot372.server4you.de (85.25.141.154)
  by ak-vds.de with (DHE-RSA-AES256-SHA encrypted) SMTP;
  16 Nov 2008 14:09:05 +0100

Es müßte also sinnvollerweise mal geprüft werden, wie die Mailqueue auf dem Server selber aussieht - vielleicht sind mitlerweile einfach so viele Leute in den Mailinglisten, daß es zu einer großen Verzögerung kommt. Andere Gründe könnten aber auch in Fehlern in den DNS-Einträgen zu suchen sein, die aber allem Anschein nach ausgeschlossen sein sollten ...

Optimierungsmöglichkeiten gibt es ggf. im Rahmen der Timeouts des Mail-Dienstes, damit nicht unnötig bei der Zustellung (zB bei greylisting-Servern etc.) gewartet wird, statt dessen halt später probiert wird ...

Evaluieren des Bedarfs

  • Wieviele Mails gehen pro Stunde über den Server?
  • für AK-Vorrat: ca. 150 Mails pro Tag mal ca. 1000 Subscriber ~ 150.000/Tag ~ 6.000/Stunde

</dd>

    • Das sind deutlich mehr, dass es ja über 20 Listen sind, die für den AK auf dem Maillinglistenserver laufen

</dd>

  • Werden sie auf Viren und auf Spam gecheckt?
  • Nein, da ja nur Mails von Listenmitgliedern (und ausdrücklich erlaubten AbsenderInnen) verteilt werden, alle anderen werden automatisch verworfen.
  • Woran liegt es dann, dass auf der berlin@ täglich duzende Spammails aufschlagen?
  • Auf keiner der Mailinglisten kommt SPAM durch, da bei allen Mailinglisten nur AbonnentInnen senden dürfen. Vermutlich sit gemeint gewesen, das ist aber keine Liste sondern ein offener Kontaktverteiler. <a href="Benutzer:WernerH">Werner</a> 13:44, 16. Jan. 2009 (CET)

</dd>

</dd>
</dd>

Lösungsmöglichkeiten

  • Kernfrage: Was ist zwischen Ende Oktober und jetzt passiert, was die Zustellung so ausbremst? --<a href="Benutzer:Garry">Garry</a>
  • Ab und zu werden die Logfiles zu groß, dann wird die Zustellung ausgebremst.

</dd>

  • Kann man Spam- oder Virenchecks bei einigen oder allen Listen unnötig machen, indem man z. B. keine Anhänge zulässt oder nur eingetragene Mitglieder Schreibrechte haben?
  • Das ist ja bereits so?
  • Genau <a href="Benutzer:WernerH">Werner</a> 13:44, 16. Jan. 2009 (CET)
  • Bei allen Listen werden nur Mails von eingetragenen Mitgliedern akzeptiert. Also muss Mailman bei jeder Mail an eine Liste schauen, ob der Absender in der Liste ist. Bei den SPAM-Mails ist dies dann nicht der Fall, die werden dann weggeschmissen. Aber solagen die Mailinglistenadressen im Klartext (also <listname>@ak-vds.de) veröffentlicht werden und nicht mit einem "[at]" statt dem "@", wird der SPAM von Tag zu Tag mehr.
  • Wir könnten das umschreiben. Zum Beispiel mit <img src="/images/At.png" _fck_mw_filename="At.png" alt="" /> statt "@". Spricht etwas dagegen? --<a href="Benutzer:Roam">roam</a> 09:53, 25. Apr. 2009 (CEST)

</dd>

</dd>
</dd>

  • Kann man den Server dahingehend optimieren, dass er die Checks nur bei eingehenden Mails vornimmt?
  • Nein, denn der Server macht weder SPAM- noch Virencheck

</dd>

  • Ist vielleicht ein dedizierter Server angebracht, etwa in Form eines Vservers (oder ggf. noch größere Kapazität)?
  • Wieso sollte ein VServer mehr Kapazität haben, als ein Rootserver, der zu 98 % dem AK zur Verfügung steht.

</dd>

  • Das ja doch ne ganze Menge Mails die der da verschicken muss, ich würde behaupten, dass da nen VServer auch schon stark in die Knie geht. Eine Auslastungsgraph vom CPU wäre sicherlich mal interessant, besonders wenn man irgendwie den Mailserver Prozess dabei betrachtet.
  • Die CPU-Auslastung in Vservern ist meistens nicht das, was einen Vserver in die Knie zwingt. Meistens sind es Resourcen wie gleichzeitig offene Verbindungen, gleichzeitig geöffnete Dateien / Sockets / Prozesse. Bei Server4free (Virtouzzo Vserver-Technologie) ist das alles auf 500 begrenzt. Das wird schnell verbraucht. Daher würde ich für den Mailinglisten_Server von der Vserver-Idee wirklich abraten. -<a href="Benutzer:Validom">ValiDOM</a>

</dd>

</dd>

  • Es wäre denkbar, Provider anzusprechen, die bekennende Unterstützer des AK Vorrats sind (jpb, prima, ...)
  • unschöne Variante: non digit ausschalten - jeder bekommt nur noch die Zusammenfassung am Tag
  • Keine Lösung, da dann die Verzögerung ja noch länger ist

</dd>

  • sofern die Kapazitäten was Speicher/CPU angeht, noch ausreichend Reserven hat, könnte man mehrere Queue-Prozesse parallel laufen lassen --<a href="Benutzer:Garry">Garry</a>
  • Prüfen, ob einzelne Ziele die Zustellung unnötig lang verzögern - gestaffelte Queue-Verzeichnisse mit jeweils reduzierten Queuing-Frequenzen könnten in dem Fall die Zustellung der anderen Mails beschleunigen --<a href="Benutzer:Garry">Garry</a>

Abschiedstext

Hallo, schade, dass Sie die Mailingliste abbestellt haben. Wir würden uns dennoch sehr freuen, wenn Sie uns auch weiterhin verbunden bleiben würden. Für Fragen und Meinungen kontaktieren Sie einfach .... </dd>

Ich finde den Abschiedstext der einzelnen Listen ziemlich schmierig. Klingt als hätte irgendein fieses Unternehmen gerade einen Kunden verloren.
Wenn wir uns auf der List duzen, so sollte das auch beibehalten werden wenn dort jemand aussteigt. Ausserdem ist die Gegenüberstellung "wir" auf der einen Seite und der angesprochene auf der anderen Seite, zumindest in diesem Zusammenhang schwierig weil es denjenigen ausschliesst.

Vorschlag (an dem wohl auch noch etwas gefeilt werden müsste):

Schade, dass du die Mailingliste abbestellt hast. Es wäre dennoch schön wenn du unser Anliegen weiterhin unterstützen möchtest. Bei Fragen, Anregungen oder Kritik kannst du jederzeit .... kontaktieren.

---<a href="Benutzer:Nic">Nic</a> 23:54, 15. Jan. 2009 (CET)

Vorschlag 2 (weiterfeilen):

Schade, dass du die Mailingliste Name abbestellt hast. Es wäre dennoch schön, wenn wir in unserem Anliegen verbunden blieben.
Fragen, Anregungen oder Kritik kannst du natürlich weiterhin an kontaktBild:At.pngvorratsdatenspeicherung.de richten.

--<a href="Benutzer:Peu">Peu</a> 18:27, 16. Jan. 2009 (CET)

Unterschiedliche Listen benötigen unterschiedliche Texte, bei Abmeldung von ml ist es beispielsweise sinnvoll auf announce zu verweisen. <a href="Benutzer:WernerH">Werner</a> 09:24, 25. Apr. 2009 (CEST)

Von „http://wiki.vorratsdatenspeicherung.de/Diskussion:Arbeitsgruppe_Mailinglisten“
Persönliche Werkzeuge
Werkzeuge