Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
Habe ich da was verpasst? Wieso wolln die ganzen Idioten bei mir relayen?
Richard Lechner schrieb:
> Relay access denied (total: 334)
>
> Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
> Habe ich da was verpasst? Wieso wolln die ganzen Idioten bei mir relayen?
Wo ist "bei mir"? Bei dir in der Küche?
Besim
--
Besim at Karadeniz dot de >> Pforzheim/GER >>> http://www.karadeniz.de/
netplanet - Verstehen Sie mal das Internet! - http://www.netplanet.org/
"Schon die Mathematik lehrt uns, dass man Nullen nicht übersehen
darf." -- Gabriel Laub (1928-1998), tschech. Schriftsteller
Hallo Richard,
> Relay access denied (total: 334)
>
> Habe ich da was verpasst? Wieso wolln die ganzen Idioten bei mir
> relayen?
Mir fällt gerade auf, daß momentan eine Schwemme an Zustellversuchen
von diversen offenen Relays kommt, die an verschiedenen Dialups hängen.
Neben einem vorhandenen SÄhmTP, sagen wir mal Exchange 2003 v6.5.6944.0,
läuft auch jeweils der POP-Dienst und der Microsoft Office WebServer.
Entweder ist das jetzt gehäufte und zufällige Dummheit der User oder
es gibt wieder ein gehöriges Loch in der MS-Software.
Tschau,
--------------
/ h o m a s
--
Der neue Internet Trend: Abstossende Postings! Verfasse die Mail in
HTML, niemals mit Realnamen, haenge immer das Original-Posting als
Fullquote an die Antwort, signiere alles konsequent mit einer Visiten-
karte und Du wirst reichlich die diversen Filter begluecken. :-)))))))
> Richard Lechner schrieb:
>> Relay access denied (total: 334)
>>
>> Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
>> Habe ich da was verpasst? Wieso wolln die ganzen Idioten bei mir relayen?
>
> Wo ist "bei mir"? Bei dir in der Küche?
Du hast die Gruppe verwechselt und möchtest nach deh?
Richard Lechner schrieb:
> Du hast die Gruppe verwechselt und möchtest nach deh?
Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
beobachtest und die Frequenz der Relay-Versuche. Dialup-Bereich? Fester
Mailserver? Etc., etc. Mit einer einfachen Feststellung, dass du
Relayversuche beobachtest, haust du niemanden wirklich vom Hocker. Auf
unseren Mailservern sind an besonders schönen Tagen ein Viertel aller
SMTP-Dialoge Relayversuche in verschiedenen Ausprägungen, wobei da schon
unterschieden werden muss, ob das einfache Relayversuche sind oder z.B.
jemand die SMTP-Authentifizierung knacken will und eine
Wörterbuchattacke fährt.
Besim
--
Besim at Karadeniz dot de >> Pforzheim/GER >>> http://www.karadeniz.de/
netplanet - Verstehen Sie mal das Internet! - http://www.netplanet.org/
"Ich mache das, damit Kinder in Afrika Zugriff auf freie Lehrbücher
und Nachschlagewerke erhalten." - Jimmy Wales, Wikipedia-Mitbegründer
> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
Tut nichts zur Sache.
> beobachtest und die Frequenz der Relay-Versuche. Dialup-Bereich? Fester
> Mailserver? Etc., etc. Mit einer einfachen Feststellung, dass du
Tut ebenfalls nichts zur Sache.
> Relayversuche beobachtest, haust du niemanden wirklich vom Hocker. Auf
Soll auch niemanden vom Hocker hauen, tun deine Posts übrigens auch nicht.
Da ~ 330 Relayversuche kein Normalzustand sind dachte ich es geht eine
neue "Automatik" um. Wäre es normal würde ich nicht nach "Leidensgenossen"
fragen.
> unseren Mailservern sind an besonders schönen Tagen ein Viertel aller
> SMTP-Dialoge Relayversuche in verschiedenen Ausprägungen, wobei da schon
Also echt jetzt, entweder hast/habt du/ihr wenige SMTP-Dialoge oder etwas
läuft seltsam wenn bei dir/euch ein Viertel (25%) aller Dialoge Relayversuche
sind. Habe jetzt nachgesehen und den Report aus dem Mistkübel geholt, die
334 Relays sind 6,7% Anteil bei meinem Mailvolumen gestern.
> unterschieden werden muss, ob das einfache Relayversuche sind oder z.B.
> jemand die SMTP-Authentifizierung knacken will und eine
> Wörterbuchattacke fährt.
Das würde bedeuten dass Fehler in der SMTP-Authentifizierung mit einen Relay
access denied bei dir auflaufen? Hmmm, seltsames Setup, bei mir läuft das
mit einem Sasl-Fehler auf? (Vermutlich, finde gerade keinen) :-)
> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
> beobachtest und die Frequenz der Relay-Versuche.
Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
nur ein Auskundschaften der Mailserverversion - keine Ahnung.
Entweder sind sie alle am Multiline-Header gescheitert oder die haben
ihre Scripte sonstwie nicht im Griff weil nur die Mailserverversion
Abfragen hätte von einer Maschine aus gelangt.
Bernd
--
Geben Sie bitte keine Antwort auf sterben betreffende Mitteilung.
E-Mail, gesandt ein Sterben betreffende Adresse, braucht keine Antwort.
Um Hilfe zu leisten, gehen Sie ins System Ihres Kontos bei CitiBank ein
und wählen Sie Bastelraum Hinweis Hilfe auf der beliebigen Seite aus.
>> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
>
> Tut nichts zur Sache.
Natürlich tut es. Wir sind immer an Informationen interessiert, wo
gerade mal wieder jemand spinnt.
Du kannst das natürlich alles schön für Dich behalten.
> Richard Lechner wrote:
>
>>> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
>>
>> Tut nichts zur Sache.
>
> Natürlich tut es. Wir sind immer an Informationen interessiert, wo
> gerade mal wieder jemand spinnt.
Wer lesen kann......
Zitat: Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
Die Destination ist ein kleiner Server mit ~ 5000 Mails pro Tag.
> Besim Karadeniz wrote:
>
>> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
>> beobachtest und die Frequenz der Relay-Versuche.
Du willst unbedingt Source und Destination zu unterscheiden lernen.
> Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
>
> JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
> Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
> nur ein Auskundschaften der Mailserverversion - keine Ahnung.
>
> Entweder sind sie alle am Multiline-Header gescheitert oder die haben
> ihre Scripte sonstwie nicht im Griff weil nur die Mailserverversion
> Abfragen hätte von einer Maschine aus gelangt.
Ok, 80.253.80.23 wollte heute 4 mal Schrott einliefern. Bist du jetzt JEFTEX
und hast deine Server nicht im Griff oder waren die Fingerchen schneller als
das Hirn beim vorigen Post?
>> Natürlich tut es. Wir sind immer an Informationen interessiert, wo
>> gerade mal wieder jemand spinnt.
>
> Wer lesen kann......
>
> Zitat: Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
Validiert nach PTR oder nach WHOIS? Dass irgendwo .th an einem PTR klebt
sagt nicht, dass die IP auch im Bereich APNIC angesiedelt ist.
> Die Destination ist ein kleiner Server mit ~ 5000 Mails pro Tag.
ok.
> Richard Lechner wrote:
>
>>> Natürlich tut es. Wir sind immer an Informationen interessiert, wo
>>> gerade mal wieder jemand spinnt.
>>
>> Wer lesen kann......
>>
>> Zitat: Der Source kommt aus ee com cz th ru biz br lv ma my uk be de fr it.
>
> Validiert nach PTR oder nach WHOIS? Dass irgendwo .th an einem PTR klebt
> sagt nicht, dass die IP auch im Bereich APNIC angesiedelt ist.
Sagt das Log, also ungeprüft und PTR. :-) Nachdem es Weltweit ist vermute ich
ein Botnetz? Egal, werde auf den Report von morgen warten und dann weitersehen.
> Ok, 80.253.80.23 wollte heute 4 mal Schrott einliefern. Bist du jetzt JEFTEX
> und hast deine Server nicht im Griff oder waren die Fingerchen schneller als
> das Hirn beim vorigen Post?
Formuliere Deine Frage einfach so, dass Dir nicht sofort jemand eine
Bratpfanne in die Fresse hauen will und Du kannst auch eine höfliche und
ausführliche Antwort erwarten.
Und nun verpiss Dich, Twit.
> Formuliere Deine Frage einfach so, dass Dir nicht sofort jemand eine
> Bratpfanne in die Fresse hauen will und Du kannst auch eine höfliche und
> ausführliche Antwort erwarten.
>
> Und nun verpiss Dich, Twit.
Erst fällt dir das lesen und verstehen schwer und dann kommst du mit
solchen Anwürfen? Mann bist du eine kranke Birne.
>Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
>JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
>Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
>nur ein Auskundschaften der Mailserverversion - keine Ahnung.
[.....]
AFAIK ist das der Casino-Spammer, wenigstens isser leicht zu erkennen.
Das sind aber keine Relay-Versuche (zumindest nicht bei mir), sondern
normaler Spam. Läuft schon wochenlang und ist bei mir geerdet.
Toni
Richard Lechner schrieb:
>> Du willst die IP-Adresse bzw. den Range nennen, wo du die Relayversuche
>
> Tut nichts zur Sache.
Pardon.. tut es. Es ist schon interessant, zu wissen, ob Dialup-Bereiche
gescannt werden oder "alteingesessene" Mailserver. Das könnte anderen
Leuten helfen, eventuell die Ohren ihrer Mailserver anzulegen. Dann
hätte der Thread möglicherweise von Anfang an Sinn gehabt.
> Also echt jetzt, entweder hast/habt du/ihr wenige SMTP-Dialoge oder etwas
> läuft seltsam wenn bei dir/euch ein Viertel (25%) aller Dialoge Relayversuche
> sind. Habe jetzt nachgesehen und den Report aus dem Mistkübel geholt, die
> 334 Relays sind 6,7% Anteil bei meinem Mailvolumen gestern.
Dann kannst du dich an sich relativ geruhsam zurücklehnen. Wenn dein
Mailserver >500.000 SMTP-Dialoge am Tag spricht und seit über zehn
Jahren an der gleichen Stelle im Internet steht, siehst du das alles
eventuell anders.
> Das würde bedeuten dass Fehler in der SMTP-Authentifizierung mit einen Relay
> access denied bei dir auflaufen?
Woher liest du diese Feststellung heraus?
> Hmmm, seltsames Setup, bei mir läuft das
> mit einem Sasl-Fehler auf? (Vermutlich, finde gerade keinen) :-)
Exakt. Wenn du solche Angriffe hast, weißt du, dass jemand auf deinen
Mailserver setzt und sich wirklich die Finger schmutzig machen will. Und
da wäre es gut, dass wenn schon jemand außergewöhnliche Dinge im Netz
beobachtet, diese auch genauer spezifiziert, wenn er wirklich etwas mehr
beitragen möchte, als auf Applaus zu hoffen.
[flup poster]
Besim
--
Besim at Karadeniz dot de >> Pforzheim/GER >>> http://www.karadeniz.de/
netplanet - Verstehen Sie mal das Internet! - http://www.netplanet.org/
"Wissen, das nicht mit jedem Tag zunimmt, nimmt mit jedem Tag ab."
-- Aus China
>>JEFTEX-NET
> AFAIK ist das der Casino-Spammer, wenigstens isser leicht zu erkennen.
> Das sind aber keine Relay-Versuche (zumindest nicht bei mir), sondern
> normaler Spam. Läuft schon wochenlang und ist bei mir geerdet.
Schickst Du einen Multiline-Header? Wenn nein - mach das mal
spasseshalber. Die Ergebnisse sind wirklich verblüffend.
Dann ist er seit gestern auf der Suche nach offenen Relays.
Relay access denied (total: 280)
20 80.253.80.17
15 80.253.80.21
10 80.253.80.23
Und nein, das ist werder ein SASL-Login noch eine falsche Mailbox denn
dafür gabs gestern zum Beispiel das:
Recipient address rejected: User unknown in virtual alias table (total: 10)
@Besim, bitte keinen Applaus. Das ist nur eine Tatsachenbeschreibung und
scheinbar bin ich derzeit der einzige dems auffällt bzw. bei dems aufläuft.
Die Selbstdarstellung überlasse ich den fetten Wurstfingern die ihr Ego per
Blog beim Fenster raus hängen und die Menschheit mit ihrem geistigen Dünnpfiff
beglücken glauben zu müssen.
Aus 80.253.80.0/24 kommt immer wieder mal einer vorbei, bei mir
ausschließlich mit HELO = (freenet.de|gmx.de|t-online.de|web.de) und
darum ist er auch schön geerdet.
Erstes Aufschlagen am 2006-10-26, letztes heute; im März ist er aktiver
als sonst, aber eigentlich nichts Bewegendes:
2006-10 11 x
2006-11 133 x
2006-12 12 x
2007-01 0 x
2007-02 104 x
2007-03 312 x
Gruß,
Peter
Richard Lechner schrieb:
> @Besim, bitte keinen Applaus. Das ist nur eine Tatsachenbeschreibung und
> scheinbar bin ich derzeit der einzige dems auffällt bzw. bei dems aufläuft.
Das sieht fast so aus. Man kann das Internet jeden Tag neu entdecken und
das ist noch nicht mal ironisch gemeint.
> Die Selbstdarstellung überlasse ich den fetten Wurstfingern die ihr Ego per
> Blog beim Fenster raus hängen und die Menschheit mit ihrem geistigen Dünnpfiff
> beglücken glauben zu müssen.
Schade. Auf weitgehend sachliche, mitnichten beleidigende Kritik und
Nachfragen unsachlich und persönlich beleidigend antworten zu müssen...
ich bedaure solche Verschwendung von geistigem Potential und
Diskussionsressourcen sehr.
EOD
[flup poster]
Besim
--
Besim at Karadeniz dot de >> Pforzheim/GER >>> http://www.karadeniz.de/
netplanet - Verstehen Sie mal das Internet! - http://www.netplanet.org/
"Es stolpern mehr Menschen über ihre Zunge als über ihre Füsse."
-- Aus Tunesien
>>>JEFTEX-NET
>> AFAIK ist das der Casino-Spammer, wenigstens isser leicht zu erkennen.
>> Das sind aber keine Relay-Versuche (zumindest nicht bei mir), sondern
>> normaler Spam. Läuft schon wochenlang und ist bei mir geerdet.
>Schickst Du einen Multiline-Header? Wenn nein - mach das mal
>spasseshalber. Die Ergebnisse sind wirklich verblüffend.
Habe gerade zu wenig Zeit zum Rumspielen (Urlaub naht :-)), was passiert
denn dann?
Toni
[....]
>Aus 80.253.80.0/24 kommt immer wieder mal einer vorbei, bei mir
>ausschließlich mit HELO = (freenet.de|gmx.de|t-online.de|web.de) und
>darum ist er auch schön geerdet.
Local Part ist üblicherweise sowas wie 'mahnung[5 beliebige Buchstaben]'
oder 'anwalt[4 Buchstaben]', u.ä.
>Erstes Aufschlagen am 2006-10-26, letztes heute; im März ist er aktiver
>als sonst, aber eigentlich nichts Bewegendes:
[.....]
Ich habe nicht gezählt, aber geschätzt ist das Aufkommen bei mir seit
Feb. eher konstant.
Toni
>>Schickst Du einen Multiline-Header? Wenn nein - mach das mal
>>spasseshalber. Die Ergebnisse sind wirklich verblüffend.
>
> Habe gerade zu wenig Zeit zum Rumspielen (Urlaub naht :-)), was passiert
> denn dann?
Ganz unterschiedliche, witzige Sachen..
- Wenn der der Einlieferer ein "2xx{leer}OK" erwartet, aber ein
"2xx-Laber" bekommt, legt er sofort auf.
- Wenn der Einlieferer einfach nur die Daten reinprügelt wird die
Kommunikation asynchron (zumindest bei meinem Mailserver, ich will da
einen Handshake-Dialog) und mein RCPT TO kann mit Mailheadern nix
anfangen. Also schmeiss ich ihn nach paar Zeilen Schrott einfach raus.
- Im Fall von JEFTEX-NET ist es so, dass zwar der Handshake klappt, der
Sender aber mitten im Data auflegt ehe der "." gesendet wurde (was er
nicht macht, wenn es an einen Server mit gleicher Software aber ohne
Multilineheader geht). Da ich auf den "." bestehe, kommt es nie zu einer
Zustellung.
Ich möchte es nicht mit Zahlen übertreiben, aber so 35% des Spams findet
bei mir dadurch erst garnicht statt.
Bernd
--
Jonas was Schultz1 zum freier Mann Niklas Dschungelprinie zum,
schon wieder Deponie durchsickern gut im Danke, dass Sie sich
Zeit genommen haben. Niklas in extra und Endeinspeisung Ein-
treibdorn Dschungelprinie raus er/sie hat/hatte gesungen.
>>>Schickst Du einen Multiline-Header? Wenn nein - mach das mal
>>>spasseshalber. Die Ergebnisse sind wirklich verblüffend.
>>
>> Habe gerade zu wenig Zeit zum Rumspielen (Urlaub naht :-)), was passiert
>> denn dann?
>Ganz unterschiedliche, witzige Sachen..
[....]
>Ich möchte es nicht mit Zahlen übertreiben, aber so 35% des Spams findet
>bei mir dadurch erst garnicht statt.
Hm, klingt nicht uninteressant.
Toni
Hallo Peter,
> Aus 80.253.80.0/24 kommt immer wieder mal einer vorbei, bei mir
> ausschließlich mit HELO = (freenet.de|gmx.de|t-online.de|web.de) und
> darum ist er auch schön geerdet.
Vorzugsweise kommen die auch mit MAIL FROMs der Marke anwalt[2-5],
rechnung[2-5] und mahnung[2-5]@gmx.* daher. Bei dem ständigen aber
seichten Beschuß wundert es mich doch schon, daß deren Netz in keiner
RBL erscheint. Dafür fehlt aber der PTR, auch gut ...
> Erstes Aufschlagen am 2006-10-26, letztes heute; im März ist er
> aktiver als sonst, aber eigentlich nichts Bewegendes:
Für mich persönlich sehr interessant ist, daß aus dem selben Adress-
bereich auch HTTP-Request erfolgen, die _einzigst_ auf meine SpamProxy
URL auflaufen, während das Tool selbst nie heruntergeladen wird.
Tschau,
--------------
/ h o m a s
--
Kill-, Filter- und Scorefiles: Die modernen Schallschutzwaende des Usenet.
Hallo Bernd,
> Ganz unterschiedliche, witzige Sachen..
>
> - Wenn der der Einlieferer ein "2xx{leer}OK" erwartet, aber ein
> "2xx-Laber" bekommt, legt er sofort auf.
Eine kleine Zwischenfrage: Das Multiline-Greeting wird in der Zwischen-
von allen in der Wildlife vorhandenen MTA/MUAs auch korrekt unterstützt?
Ich frage jetzt nur deswegen, da GMX und AOL vor Jahren Multiline-
Greetings auf ihren MXen genutzt haben, dieses auch vereinzelt zu
Problemem mit einigen MTA/MUAs geführt hat, während heute diese
Greetings wieder sehr konservativ sind.
Natürlich, Multiline-Greeting ist eine nette Sache um einfach ge-
strickte SMTP-Bots aus dem Tritt zu bringen. Ich frage mich aller-
dings, ob es sich in der Zwischenzeit nebenwirkungsfrei anwenden
läßt?
Tschau,
--------------
/ h o m a s
--
email : sup...@gohel.de / go...@basicguru.de (PGP-Key available)
www : http://www.gohel.de / http://www.pbhq.de (PowerBASIC)
filter: html-postings, fullquotes, no realnames & no valid adresses
Cool. Wegen des fehlenden PTR habe ich das gar nicht bemerkt. Dieser
Depp ist z.B. am Freitag ueber 24000 Mal hier vor die Wand gelaufen. Da
nexlink.ch das nicht zu interessieren scheint, werde ich bei mir das /20
blocken.
Dietmar
>> - Wenn der der Einlieferer ein "2xx{leer}OK" erwartet, aber ein
>> "2xx-Laber" bekommt, legt er sofort auf.
>
> Eine kleine Zwischenfrage: Das Multiline-Greeting wird in der Zwischen-
> von allen in der Wildlife vorhandenen MTA/MUAs auch korrekt unterstützt?
Multiline-Greeting gibts ja eigentlich nicht, das sind mutliline
Responses. Und die waren schon in Postels RFC definiert. Daher gehe ich
davon aus, dass das jeder beherrscht.
> Ich frage jetzt nur deswegen, da GMX und AOL vor Jahren Multiline-
> Greetings auf ihren MXen genutzt haben, dieses auch vereinzelt zu
Problemem mit einigen MTA/MUAs geführt hat, während heute diese
Greetings wieder sehr konservativ sind.
Echt? AOL meldet einen 2 Zeiler (war früher mehr). Und
Multiline-Responses kommen an einigen Ecken vor - zb. wenn man Rejected
und ausführlich darin beschreibt an welche Mailadresse man sich wenden
kann wenn das so jetzt nicht ok war.
> Natürlich, Multiline-Greeting ist eine nette Sache um einfach ge-
> strickte SMTP-Bots aus dem Tritt zu bringen. Ich frage mich aller-
> dings, ob es sich in der Zwischenzeit nebenwirkungsfrei anwenden
> läßt?
Mal ganz ernsthaft: wenn ein MUA/MTA ein Problem damit hat, grundlegende
Anforderungen eines Handshake-Protokolls abzuwickeln und der Autor der
Software das nicht repariert, dann sollte man den Autor in die Wüste zum
Sandkörnerzählen schicken.
> Multiline-Greeting gibts ja eigentlich nicht, das sind mutliline
> Responses. Und die waren schon in Postels RFC definiert. Daher gehe ich
> davon aus, dass das jeder beherrscht.
Es gibt offensichtlich einen Dissens darüber, ob beim initialen
Greeting eine Multiline-Response erlaubt ist; der RFC ist
diesbezüglich widersprüchlich.
Siehe dazu bspw.
<14706.19721...@news.jors.net>
<dcsm.0701...@windlord.akallabeth.de>
<eol6rf$pav$1...@geiz-ist-geil.priv.at>
in de.comm.software.mailserver.
-thh
> Es gibt offensichtlich einen Dissens darüber, ob beim initialen
> Greeting eine Multiline-Response erlaubt ist; der RFC ist
> diesbezüglich widersprüchlich.
Ich kann Dir auch nicht beantworten, warum Kollege Juergen P. Meier die
RFCs nicht liest.
Da steht ganz eindeutig, dass die auszuwertende Response
"Greeting = "220 " Domain [ SP text ] CRLF" ist.
Da auch gilt "Only the EHLO, EXPN, and HELP commands are expected to
result in multiline replies in normal circumstances, however, multiline
replies are allowed for any command" hat die Programmierung für die
Auswertung der Response die Zeilen zu ignorieren, die mit "###-"
beginnen und auf das abschliessende "### " zu warten.
Von der Theorie her ist also auch folgendes als "OK" zu werten:
400-Erst wenn sich die Irren zusammenschließen, kann es
500-Fortschritte in der Gesellschaft geben.
200 Accepted
Da das Commandparsing eh zentral passiert, ist das bei allen Programmen
durch Zufühgung einer while-schleife und einer Hilfsvariablen zu
reparieren. Und ich verstehe nicht, warum manche Leute das nicht einfach
so machen statt kaputte Programmierung zu verteidigen.
> [...]
>
> Von der Theorie her ist also auch folgendes als "OK" zu werten:
>
> 400-Erst wenn sich die Irren zusammenschließen, kann es
> 500-Fortschritte in der Gesellschaft geben.
> 200 Accepted
Der Reply-Code darf innerhalb einer Multiline-Response wechseln?? Ich
verstehe RFC 2821 (Section 4.2.1) da anders.
> [...]
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
>> 400-Erst wenn sich die Irren zusammenschließen, kann es
>> 500-Fortschritte in der Gesellschaft geben.
>> 200 Accepted
>
> Der Reply-Code darf innerhalb einer Multiline-Response wechseln?? Ich
> verstehe RFC 2821 (Section 4.2.1) da anders.
Wenn Du das RFC vernünftig runterprogrammierst, merkst Du ganz schnell
das das Deinem Code ziemlich Wurst ist was in einer Multiline-Response
vorher steht da Du nur den Text der Response wegschreibst und nur die
letzte Zeile numerisch auswerten wirst.
So sehen das auch die Autoren von RFC 2821: "In many cases the SMTP
client then simply needs to search for a line beginning with the reply
code followed by <SP> or <CRLF> and ignore all preceding lines. In a
few cases, there is important data for the client in the reply "text".
The client will be able to identify these cases from the current context."
Ich will damit nicht sagen, dass man jetzt unbedingt den Replycode
mittendrin wechseln sollte. Aber wenn man das RFC 1:1 implementiert ist
es der Programmierung egal was da vorher ein Code kommt.
Na also. Damit darf aber auch nichts davor kommen.
> Da auch gilt "Only the EHLO, EXPN, and HELP commands are expected to
> result in multiline replies in normal circumstances, however, multiline
> replies are allowed for any command"
Und? Das Greeting ist kein Reply auf ein Command.
> Von der Theorie her ist also auch folgendes als "OK" zu werten:
Nein.
Bastian
>> Da auch gilt "Only the EHLO, EXPN, and HELP commands are expected to
>> result in multiline replies in normal circumstances, however, multiline
>> replies are allowed for any command"
>
> Und? Das Greeting ist kein Reply auf ein Command.
Es ist das Reply auf den Connect. Und nun halt dich heraus, wenn
Erwachsene sprechen.
Wow. Die Qualität dieser technischen Argumentation überzeugt natürlich
sofort.
Zwei Zitate:
| The format for multiline replies requires that every line, except the
| last, begin with the reply code, followed immediately by a hyphen,
| "-" (also known as minus), followed by text. The last line will
| begin with the reply code, followed immediately by <SP>, optionally
| some text, and <CRLF>.
| In ABNF, server responses are:
|
| Greeting = "220 " Domain [ SP text ] CRLF
| Reply-line = Reply-code [ SP text ] CRLF
Folgerung 1: da steht "begin with _the_ reply code", nicht "_a_ reply
code". Heißt:
400-Erst wenn sich die Irren zusammenschließen, kann es
500-Fortschritte in der Gesellschaft geben.
200 Accepted
ist unzulässig, weil "the reply code" dieser Antwort nun mal 200 ist,
und alle Zeilen damit zu beginnen haben. Dass das oft so implementiert
ist, dass man nur die letzte Zeile auswertet (ja, auch mein SMTP-Client
macht das so), heißt noch lange nicht, dass man sich darauf verlassen
darf. Was bitteschön spricht dagegen, die _erste_ Antwort auszuwerten?
Folgerung 2: Greeting enthält keinen reply-code, was man zumindest
derart interpretieren darf, dass eben alles, was sich auf einen
reply-code (z.B. multiline-reply) bezieht, hier nicht zutrifft. Wo
müsste dann eigentlich der Domain-Name stehen? So
220-Hi there, this is the
220 mail.example.com server!
oder so?
220-mail.example.com greets
220 you.
Bei den anderen multiline-replies befinden sich die auszuwertenden
Informationen auch in den "-"-Zeilen.
Ergo ist der RFC hier mindestens uneindeutig. Eine 100%ige Erlaubnis für
multiline-greetings sähe anders aus.
Stefan
>> Es ist das Reply auf den Connect. Und nun halt dich heraus, wenn
>> Erwachsene sprechen. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^
>
> Wow. Die Qualität dieser technischen Argumentation überzeugt natürlich
> sofort.
Wo siehst Du eine technische Argumention wenn ich jemand mit einer
Bratpfanne den Scheitel nachziehe?
> Folgerung 2: Greeting enthält keinen reply-code,
Ich darf statt eines Greetings nicht "400 Server busy, retry later"
senden? Interessant.
Bernd
Ich würde mit Blick auf 421 und 554 eher folgern, dass Greeting eine
spezialisierte Reply ist.
> Ergo ist der RFC hier mindestens uneindeutig. Eine 100%ige Erlaubnis für
> multiline-greetings sähe anders aus.
Ein Verbot ebenso.
Bei der ganzen Diskussion vermisse ich eine Nennung der MTAs und MUAs
die damit Probleme haben. Es wird zwar gerne orakelt, konkrete Namen und
Versionen habe ich bisher nicht gelesen.
Bye,
Daniel
554 ist ja in Abschnitt 3.1 explizit erwähnt, widerspricht aber eben der
ABNF-Definition von 'Greeting'.
>>Ergo ist der RFC hier mindestens uneindeutig. Eine 100%ige Erlaubnis für
>>multiline-greetings sähe anders aus.
>
> Ein Verbot ebenso.
Und daher kommt hier normalerweise das Robustness Principle zum Tragen:
ein SMTP-Client sollte damit umgehen können, ein SMTP-Server sollte es
aber nicht unbedingt ausnutzen.
Jedenfalls sehe ich durchaus Raum für Mehrdeutigkeiten in diesem RFC,
und noch lange keinen Grund, Leuten da "mit einer Bratpfanne den
Scheitel nachzuziehen".
> Bei der ganzen Diskussion vermisse ich eine Nennung der MTAs und MUAs
> die damit Probleme haben. Es wird zwar gerne orakelt, konkrete Namen und
> Versionen habe ich bisher nicht gelesen.
Na damit nicht klarkommen tun offenbar die Spambots :-)
Letztenendes steht eine multiline-greeting wohl auf dem gleichen Niveau
wie Greylisting: es basiert darauf, dass "normal programmierte" Clients
sich wohl passend verhalten, und damit umgehen, während Spambots das
nicht tun. Und wenn ich mich recht erinnere, hatten wohl durchaus einige
MTAs anfangs Probleme mit Graylisting (IIRC Yahoogroups).
Stefan
Und genau weil 554 und 421 laut 3.1 und 4.3.2 nach einem Connect
vorkommen dürfen aber beide nicht der Definition des Greetings
entsprechen handelt es sich IMO bei allen dreien (220, 421 und 554) um
Replies.
> Na damit nicht klarkommen tun offenbar die Spambots :-)
Sollen wir die ernsthaft zu MTAs oder MUAs zählen?
Bye,
Daniel
> Jedenfalls sehe ich durchaus Raum für Mehrdeutigkeiten in diesem RFC,
> und noch lange keinen Grund, Leuten da "mit einer Bratpfanne den
> Scheitel nachzuziehen".
BSD SENDMAIL 8.6 von 1993 meldet sich mit einem Multiline-Greeting, was
mit "brokensmtppeers" abgeschaltet werden kann. Einige andere SMTP
Daemons konnten das schon viel früher. Der Aufstand um das ML-Greeting
hat sich damals in Grenzen gehalten, die Programme wurden RFC821 konform
gemacht und gut war.
Ist Dir noch nie aufgefallen, dass sich diese "Multiline-Greeting ist
nicht RFC kondom"-Diskussion fast ausschliesslich in DE abspielt?
Bestünde für den Rest der Welt irgendein Klärungsbedarf, wäre das in
RF2821 von 2001 reingekommen. Schlussfolgerung: die Deutschen sind
einfach zu blöde, ein RFC zu lesen oder sie sind zu stur, ihren Fehler
zuzugeben.
Aber wer jetzt 14 Jahre später immer noch darüber diskutiert, dem gehört
einfach eine Bratpfanne übergezogen.
Bernd
Hallo Daniel,
> Bei der ganzen Diskussion vermisse ich eine Nennung der MTAs und MUAs
> die damit Probleme haben. Es wird zwar gerne orakelt, konkrete Namen
> und Versionen habe ich bisher nicht gelesen.
Postfix, Uralt-Versionen (<1999) der XP-Clients, Exchange v5,
Mailserver und und ...
Allgemein ist 2003 scheinbar das Jahr in dem sich die Umsetzung
des Multiline-Greetings weitgehend durchgesetzt hat.
Tschau,
--------------
/ h o m a s
--
Permanent Online Filter fuer: User ohne Realnamen im From:-Feld, Full-
quotes (zitieren des originalen Postings unter der eigenen Antwort),
Visitenkarten, HTML-Postings, Invalid- und ungueltige Email-Adressen
> Da steht ganz eindeutig, dass die auszuwertende Response
> "Greeting = "220 " Domain [ SP text ] CRLF" ist.
Richtig. Und da ist "220 " vorgeschrieben. Das schließt im Gegensatz
zum Beispiel für andere Responses ein "220-" aus.
> Da auch gilt "Only the EHLO, EXPN, and HELP commands are expected to
> result in multiline replies in normal circumstances, however, multiline
> replies are allowed for any command" hat die Programmierung für die
> Auswertung der Response die Zeilen zu ignorieren, die mit "###-"
> beginnen und auf das abschliessende "### " zu warten.
Auch das läßt die Interpretation zu, daß (nur) "multiline *replies*"
für jedes "command" zulässig sind, nicht aber ein "multiline
*greeting*". Das initiale greeting ist nämlich strenggenommen keine
Antwort und erfolgt nicht auf ein Kommando hin, sondern eben initial.
> Von der Theorie her ist also auch folgendes als "OK" zu werten:
>
> 400-Erst wenn sich die Irren zusammenschließen, kann es
> 500-Fortschritte in der Gesellschaft geben.
> 200 Accepted
Das sehe ich nicht so. Der Returncode darf m.E. in einer multiline
reply nicht wechseln.
> Da das Commandparsing eh zentral passiert, ist das bei allen Programmen
> durch Zufühgung einer while-schleife und einer Hilfsvariablen zu
> reparieren. Und ich verstehe nicht, warum manche Leute das nicht einfach
> so machen statt kaputte Programmierung zu verteidigen.
Die Frage ist doch zunächst einmal, was kaputt ist - der Client oder
der Server. :) Der RFC ist da nicht so eindeutig, wie er sein könnte.
-thh
--
BITTE *vor* dem Posten in de.admin.net-abuse.mail die Hinweise unter
<http://th-h.de/faq/danam-intro.html> und ggf. die dort genannten FAQs lesen!
Weitere kleine Texte rund um das Thema E-Mail: <http://th-h.de/infos/email/>
>> Da steht ganz eindeutig, dass die auszuwertende Response
>> "Greeting = "220 " Domain [ SP text ] CRLF" ist.
>
> Richtig. Und da ist "220 " vorgeschrieben. Das schließt im Gegensatz
> zum Beispiel für andere Responses ein "220-" aus.
Die auszuwertende Response mein Schatz... die Auszuwertende... Nicht das
Zeug, was davor steht.
Wenn man es so herunterprogrammiert, wie es im RFC steht, gibt das ein
robustes Ergebnis. Du kannst es natürlich so implementieren wie Du es
interpretierst - aber dann jammer nicht, wenn es knallt und beschwer
Dich erst recht nicht über die angeblichen Ungenauigkeiten im RFC.
> Allgemein ist 2003 scheinbar das Jahr in dem sich die Umsetzung
> des Multiline-Greetings weitgehend durchgesetzt hat.
Die ersten wackeligen Gehversuche mit meiner eigenen MTA-Software hab
ich so 1998 gemacht (natürlich ohne irgendein RFC zu lesen) und einer
ersteren Versuche damit Mail loszuwerden ist bei AOL gelandet wo mir 6
Zeilen Disclaimer im Greeting entgegengeworfen wurden.
Jetzt frag ich mich natürlich: mussten die genannten "Postfix, Exchange
v5, Mailserver und und ..." im Jahre 1998 nie bei AOL und anderen
Systemen Mails einwerfen?
Da kann also was nicht an der Zeitschiene stimmen.
Bernd
> Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
>
> JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
> Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
> nur ein Auskundschaften der Mailserverversion - keine Ahnung.
Aus meinen Webseiten-Logs kann ich 80.253.81.0 - 80.253.81.255 anbieten.
Ob die sich auch auf Mailservern tummeln, weiss ich aber nicht.
Jedenfalls wird seit langer Zeit mit beiden Ranges versucht, mehr von
meinen Seiten zu kriegen. Die 81-er Range ist bei mir in der Überzahl.
Jürgen
> [...]
>
> Auch das läßt die Interpretation zu, daß (nur) "multiline *replies*"
> für jedes "command" zulässig sind, nicht aber ein "multiline
> *greeting*". Das initiale greeting ist nämlich strenggenommen keine
> Antwort und erfolgt nicht auf ein Kommando hin, sondern eben initial.
Geh mal mit einem FTP-Client auf ftp.cert.dfn.de -- "multiline greeting"
ist da nur eine schwache Umschreibung, es dürften grob geschätzt knapp
dreißig Zeilen sein.
(Ich weiß, FTP ist nicht SMTP, aber die Systematik mit den "reply codes"
ist ja ähnlich.)
>> Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
>>
>> JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
>> Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
>> nur ein Auskundschaften der Mailserverversion - keine Ahnung.
>Aus meinen Webseiten-Logs kann ich 80.253.81.0 - 80.253.81.255 anbieten.
>Ob die sich auch auf Mailservern tummeln, weiss ich aber nicht.
Auf meinem jedenfalls nicht.
>Jedenfalls wird seit langer Zeit mit beiden Ranges versucht, mehr von
>meinen Seiten zu kriegen. Die 81-er Range ist bei mir in der Überzahl.
Im aktuellen Log nur wenige, jedenfalls zuwenig um eine vernünftige
Aussage zu treffen.
inetnum: 80.253.80.0 - 80.253.95.255
org: ORG-GCA1-RIPE
netname: CH-GREEN-20051201
descr: Green Connection AG
Das scheinen jedenfalls 'andere' zu sein.
Toni
>> Da hätte ich gerade was anzubieten: 80.253.80.0 - 80.253.80.255
>>
>> JEFTEX-NET mit Netz in der Schweiz, Sitz in Malaysia und knapp einem
>> Kilo Connects in der letzten Stunde. Ob das nun ein Relaytest war oder
>> nur ein Auskundschaften der Mailserverversion - keine Ahnung.
>Aus meinen Webseiten-Logs kann ich 80.253.81.0 - 80.253.81.255 anbieten.
>Ob die sich auch auf Mailservern tummeln, weiss ich aber nicht.
Auf meinem jedenfalls nicht.
>Jedenfalls wird seit langer Zeit mit beiden Ranges versucht, mehr von
>meinen Seiten zu kriegen. Die 81-er Range ist bei mir in der Überzahl.
Im aktuellen Log nur wenige, jedenfalls zuwenig um eine vernünftige
Aussage zu treffen.
Whois meint zu 80.253.81.0/24:
inetnum: 80.253.80.0 - 80.253.95.255
org: ORG-GCA1-RIPE
netname: CH-GREEN-20051201
descr: Green Connection AG
Das scheinen jedenfalls 'andere' zu sein, unser Patient 80.253.80.0/24
hat jedenfalls einen eigenen Eintrag.
Toni
(supersede wg. Korrektur)
Nein, das ist mir aber egal. Ich lese den RFC und implementiere den. Und
da er multiline-greetings weder explizit erlaubt noch verbietet, kommt
halt das robustness principle zum Einsatz. Heißt für mich: ein Server
sollte darauf verzichten, ein Client sollte damit umgehen können. Wenn
das in nicht-Deutschland keiner explizit in eine Newsgroup schreibt,
stört mich das irgendwie nicht.
Stefan
Hallo Toni,
>> Jedenfalls wird seit langer Zeit mit beiden Ranges versucht, mehr
>> von meinen Seiten zu kriegen. Die 81-er Range ist bei mir in der
>> Überzahl.
Die Zugriffsmuster auf meinem Webserver sind zw. 80.253.80.* und
80.253.81.* völlig identisch und auch extrem markant, da es jeweils
nur den reinen Content einer einzigsten Seite betrifft. Selbst
der Referer des Bots ist immer absolut identisch und auch markant.
> Das scheinen jedenfalls 'andere' zu sein, unser Patient
> 80.253.80.0/24 hat jedenfalls einen eigenen Eintrag.
Zumindestens kommen keine Connects auf Port 25 aus dem Bereich von
80.253.81.0/24.
Tschau,
--------------
/ h o m a s
--
Hallo Bernd,
>> Allgemein ist 2003 scheinbar das Jahr in dem sich die Umsetzung
>> des Multiline-Greetings weitgehend durchgesetzt hat.
> Die ersten wackeligen Gehversuche mit meiner eigenen MTA-Software hab
> ich so 1998 gemacht (natürlich ohne irgendein RFC zu lesen) und einer
> ersteren Versuche damit Mail loszuwerden ist bei AOL gelandet wo mir
> 6 Zeilen Disclaimer im Greeting entgegengeworfen wurden.
Bernd, es geht mir hier nicht darum irgendetwas zu verteufeln, sondern
ich bin lediglich daran interessiert zu wissen, welche Probleme ein
Multiline im Greeting heute noch aufwerfen kann. Leider wird aber nun
keine Programmierer in seinen Changelogs etwas zu einem Thema schreiben,
welches er bisher nicht gefixed hat oder noch nicht unterstützt, sofern
diese Software überhaupt noch weiterentwickelt wird.
Ich habe mich ab 1999 mit diversen Projekten um Mail, News, Spam und
ein paar anderen Sachen in dieser Preislage beschäftigt und im Jahre
2000 war das Thema in jedem Fall noch nicht zu den Akten gelegt.
> Jetzt frag ich mich natürlich: mussten die genannten "Postfix,
> Exchange v5, Mailserver und und ..." im Jahre 1998 nie bei AOL und
> anderen Systemen Mails einwerfen?
Frage mich jetzt nicht, aber ich war selber erschrocken, daß hier
extrem gehäuft das Jahr 2003 erscheint, anstatt wie vielleicht er-
wartet der Zeitraum 1998-2000.
> Da kann also was nicht an der Zeitschiene stimmen.
Meine Software kommt seit Beginn an (also seit 1999) mit dem Multi-
line im Greeting zurecht. So bin ich zumindestens den schwarzen Peter
los. :-)
Tschau,
--------------
/ h o m a s
--
Der neue Internet Trend: Abstossende Postings! Verfasse die Mail in
HTML, niemals mit Realnamen, haenge immer das Original-Posting als
Fullquote an die Antwort, signiere alles konsequent mit einer Visiten-
karte und Du wirst reichlich die diversen Filter begluecken. :-)))))))
>Hallo Toni,
>>> Jedenfalls wird seit langer Zeit mit beiden Ranges versucht, mehr
>>> von meinen Seiten zu kriegen. Die 81-er Range ist bei mir in der
>>> Überzahl.
>Die Zugriffsmuster auf meinem Webserver sind zw. 80.253.80.* und
>80.253.81.* völlig identisch und auch extrem markant, da es jeweils
>nur den reinen Content einer einzigsten Seite betrifft. Selbst
>der Referer des Bots ist immer absolut identisch und auch markant.
Sieht bei mir auch so aus, aber es sind im aktuellen Log zuwenig
Einträge um was Relevantes dazu zu sagen - und ich bin eigentlich schon
gar nicht mehr da, fahre in einer guten Stunde weg auf Kurzurlaub, daher
mochte ich nicht mehr in den älteren Logs rumstochern.
>> Das scheinen jedenfalls 'andere' zu sein, unser Patient
>> 80.253.80.0/24 hat jedenfalls einen eigenen Eintrag.
>Zumindestens kommen keine Connects auf Port 25 aus dem Bereich von
>80.253.81.0/24.
Stimmt, mir ist auch keiner aufgefallen.
Toni
> Ich habe mich ab 1999 mit diversen Projekten um Mail, News, Spam und
> ein paar anderen Sachen in dieser Preislage beschäftigt und im Jahre
> 2000 war das Thema in jedem Fall noch nicht zu den Akten gelegt.
Sagen wir es mal so: seit 1998 fahre ich ein Multiline-Greeting und
bislang ist keine Kommunikation verloren gegangen. Jedenfalls keine wo
mir jemand gesagt hat "ich werd meine Mail bei Dir nicht los" (und
Spammer rufen naturgemäss nicht den Admin an).
Unsere Software läuft auch seit über 2 Jahren auf grossen Installationen
in Gegenden, die vor paar Jahren noch völliges
Internet-Entwicklungsgebiet waren. Alle haben sie kräftige
Greeting-Banner. Mailverluste: keine bekannt (ausser von Spammern
natürlich).
Ich würde mal sagen, dass das Problem (wenn überhaupt) nur noch in den
düstersten Ecken der selbstgestrickten Tools herumgeistert.
Liebe Grüsse,
> Letztenendes steht eine multiline-greeting wohl auf dem gleichen Niveau
> wie Greylisting: es basiert darauf, dass "normal programmierte" Clients
> sich wohl passend verhalten, und damit umgehen, während Spambots das
> nicht tun. Und wenn ich mich recht erinnere, hatten wohl durchaus einige
> MTAs anfangs Probleme mit Graylisting (IIRC Yahoogroups).
Kleiner Unterschied:
Dass Yahoogroups nicht mit Greylisting zurecht kam (kommt?), liegt wohl
daran, dass sie jede Zustellung genau einmal versuchen, was natürlich
völlig RFC-widrig ist und auch ohne Greylisting zu verlorenen Mails
führt, wenn auch nicht so oft.
Die meisten anderen Greylisting-Probleme sind eher auf der Ebene, dass
*alle* Mails verzögert werden, nicht nur die erste (z.B. VERP), oder
dass die Verzögerung erheblich längert ist als gewünscht (z.B.
wechselnde IP).
Gruß Jost |8-)
> AFAIK ist das der Casino-Spammer, wenigstens isser leicht zu erkennen.
Erinnert sich noch jemand an die unselige "Porno Hacker Crew" und ihren
massenhaften Spam für Stardialer-Seiten? Die verwendeten genau das
gleiche System wie dieses "Casino" mit "Anwalt" und "Mahnung". Benutzt
da jemand nur die gleiche seltene Spamware oder ist es vielleicht sogar
derselbe Verursacher?
M.
IMO schon.
> Natürlich, Multiline-Greeting ist eine nette Sache um einfach ge-
> strickte SMTP-Bots aus dem Tritt zu bringen. Ich frage mich aller-
> dings, ob es sich in der Zwischenzeit nebenwirkungsfrei anwenden
> läßt?
Abgesehen von Endlos-Dskussion hiergroups: ja.
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Das hatten wir schon wiederlegt. Wenn du die Wiederlegung wiederlegen
kannst - bitte. Ansonsten bemühe das Archiv deines geringsten Misstrauens.
>> Da auch gilt "Only the EHLO, EXPN, and HELP commands are expected to
>> result in multiline replies in normal circumstances, however, multiline
>> replies are allowed for any command"
>
> Und? Das Greeting ist kein Reply auf ein Command.
Doch. Auf den Connect. Auch das hatten wir schon mal. vgl einfach 821
...
One important reply is the connection greeting.
^^^^^^^^^^^^^^^^^^^
Also Postel betrachtet das greeting als reply. Also ist das so, denn
der hats erfunden. Da fährt die Eisenbahn drüber. Ich weiss, dass das
einigen hier nicht passt.
cu
Clemens.
PS: Und vor jetzt wieder einige meckern: in 2821 kommt auch die
Formulierung "One important reply is the connection greeting." vor.
PPS: müssen wir wirklich die alle paar Monate das selbe hier aufführen?
Was ist das da? Absurdes Theater?