relaytest.kundenserver.de
Sascha Kimmel
was soll das denn nettes?
Kühne Mission im Sinne aller Internetnutzer oder irgendein Selbstzweck, der
mir noch nicht bekannt geworden ist?
<XX>Mar 12 15:44:34 sendmail[29935]: g2CEiY629935: ruleset=check_rcpt,
arg1=<rel...@relaytest.kundenserver.de>, relay=relaytest.kundenserver.de
[212.227.126.156], reject=550 5.7.1 <rel...@relaytest.kundenserver.de>...
SMTP relay denied, authenticate via POP/IMAP first
Grüße
Sascha
Joachim Deckers
Guido Hennecke schrieb:
> Die Flachnasen antworten nichtmal auf Anfragen.
Das kenne ich aber wesentlich anders! Habe auch Sonntags da schon
qualifizierte Unterstützung erhalten.
Aber: Vielleicht macht der Ton die Musik? Wenn man mich erstmal als
Flachnase bezeichnete, würde ich meinerseits nicht antworten (sondern
denjenigen eher in mein Killfile aufnehmen).
> Gibbet nur eines: kundenserver.de komplett blacklisten.
Nee, es reicht schon völlig, dass kundenserver.de zu Unrecht bei
Osirusoft gelistet ist und deswegen meine eigenen Mails an meine
Dienstadresse nicht mehr ankommen...
Dass Osirusoft Auth-SMTP-Server blockiert, halte ich auch nur für mäßig
sinnvoll!
Zu Unrecht übrigens deswegen, weil der betreffende Newsthread, auf den
in der Meldung durch Osirusoft als Ursache für das Blockieren verwiesen
wurde, deutlich zeigt, dass kundenserver.de da nix mit zu tun hatte.
Aber im Gegensatz zu kundenserver.de erhält man bei osirusoft
grundsätzlich keine Antwort - oder ich weiß nicht, an wen ich mich dort
hätte (besser) wenden können.
Gruß
Joachim
Hendrik Weimer
> Guido Hennecke schrieb:
>
> > Gibbet nur eines: kundenserver.de komplett blacklisten.
>
> Nee, es reicht schon völlig, dass kundenserver.de zu Unrecht bei
> Osirusoft gelistet ist und deswegen meine eigenen Mails an meine
> Dienstadresse nicht mehr ankommen...
Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
Hendrik
Sebastian Niehaus
[...]
> Nee, es reicht schon völlig, dass kundenserver.de zu Unrecht bei
> Osirusoft gelistet ist
Zu Unrecht? Die Mailserver von Schlund/Puretec sind doch
berühmt-berüchtigt für ihren praktisch völlig offenen Status.
> Dass Osirusoft Auth-SMTP-Server blockiert, halte ich auch nur für
> mäßig sinnvoll!
Das ist in der Tat nicht optimal. Zumindest, wenn die Mails, die per
SMTP-AUTH gesendet werden, auch von einem anderen Server (mit anderer
IP) gesendet werden, sollte das ein "Klacks" sein.
"Lustig" finde ich, daß P/S nun selber nach offenen Relays scannt,
selber auf diesem Gebiet aber einige "Meriten" hat. Glashaus und
Steine?
Oder vielleicht ein beginnendes Umdenken?
Sebastian
Joachim Deckers
> Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
Das nervt, ja. Habe mich deswegen als 1&1-Kunde auch mehrfach
ergebnisfrei bei 1&1 und Schlund beschwert.
Deswegen nutze ich mittlerweile selbst nur noch Auth-SMTP.
Aber: 195.20.224.219 = mrvdom.kundenserver.de
Geblockt wird unter anderem aber auch 195.20.224.89 =
mout04.kundenserver.de
Gruß
Joachim
Joachim Deckers
> Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
Okay, mittlerweile ist ein anderer Grund (URL zu Google-Groups) durch
osirusoft.org angegeben:
http://groups.google.com/groups?q=kundenserver.de&hl=en&group=news.admin.net-abuse.*&sa=G&scoring=d
Der ist nachvollziehbar.
Aber das sind ja auch besondere Experten bei kundenserver.de:
Received: from [172.19.20.60] (helo=mrelayng0.kundenserver.de)
by mout04.kundenserver.de with esmtp (Exim 2.12 #2)
id 16hWmw-00079q-00
for xxx...@mariengymnasium-arnsberg.de; Sun, 3 Mar 2002 15:16:34 +0100
Received: from [80.130.229.226] (helo=mobil)
by mrelayng0.kundenserver.de with asmtp (Exim 3.22 #2)
id 16hWmw-0005el-00
for xxx...@mariengymnasium-arnsberg.de; Sun, 03 Mar 2002 15:16:34 +0100
mrelayng0.kundenserver.de ist mein Auth-SMTP-Host. Und dann leiten die
das intern anscheinend weiter an einen beliebigen anderen Server... Da
bringt das Auth-SMTP mir letztlich nichts mehr.
Gruß
Joachim
Anders Henke
>> Dass Osirusoft Auth-SMTP-Server blockiert, halte ich auch nur f?r
>> m??ig sinnvoll!
Es ist kein einfacher Block, sondern viel haerter:
anders@ista:~$ host 89.224.20.195.relays.osirusoft.com
89.224.20.195.relays.osirusoft.com A 127.0.0.4
127.0.0.4 Confirmed Spam Source
A site has been identified as a constant source of spam, and is
manually added. Submissions for this type of spam require multiple
nominations from multiple sites.
Interessanterweise ist aber das gesamte Netz gelistet:
anders@ista:~$ host 18.225.20.195.relays.osirusoft.com
18.225.20.195.relays.osirusoft.com A 127.0.0.4
Hmmm. Ich wusste nicht, dass die www.puretec.de ein offenes Relay
ist oder zum Spam-Verschicken benutzt wird ...
Puretec hostet ein paar Mio .de-Domains mit entsprechend vielen Kunden - und
solange nicht jemand jede Kundenmail vor dem Ausliefern einzeln gegen die
'Spamming verboten'-Klausel der Puretec-AGBs vergleicht, ist da eben auch
viel Spam dabei.
Dagegen hilft kein Meckern, sondern nur konsequentes Abmahnen und Rauswerfen
der Spammer. Wenn die aber immer ueber das halboffene Relay verschicken,
koennen die sich gegenueber dem Abuse-Desk immer mit 'ich war's nicht'
rausreden, da hat der Abuse-Desk einfach keine Chance. Also: dafuer sorgen,
dass die Spammer sich nicht mehr verstecken koennen und smtp-auth fuer alle
einfuehren.
SMTP-Auth gibt es bei Puretec/S+P schon laenger: Puretec bewirbt es seit
letztem Sommer, bei Schlund war es schon ein paar Monate frueher da.
Dummerweise gibt es da auch ein paar tausend Reseller, die ihren Endkunden
smtp-auth beibringen muessen und viele Leute, die smtp-auth einfach
nicht in ihren Mailclient einkonfiguriert bekommen oder es einfach nicht
machen ("tut ja auch so"). Und solange das nicht halbwegs geklaert ist,
kann man eben auch nicht einfach das halboffene Relay abschalten.
> Das ist in der Tat nicht optimal. Zumindest, wenn die Mails, die per
> SMTP-AUTH gesendet werden, auch von einem anderen Server (mit anderer
> IP) gesendet werden, sollte das ein "Klacks" sein.
Das werden sie doch: Rein auf mrvdom.kundenserver.de, raus ueber
moutvdom.kundenserver.de. Rein auf authentifizierter Verbindung
(smtp-auth, lokaler IP-Range), raus ueber mout.kundenserver.de.
moutvdom und mout haben verschiedene IPs und sind damit dann auch fuer
jeden eindeutig identifizierbar.
> "Lustig" finde ich, da? P/S nun selber nach offenen Relays scannt,
> selber auf diesem Gebiet aber einige "Meriten" hat. Glashaus und
> Steine?
Naja, es ist zumindest geschlossen genug, um von einfachen Tests
und den ueblichen Spammern als solches erkannt zu werden
(loca...@kundenserver.de tut nicht, localpart@$ip tut nicht,
erst localpart@domain_hat_mx_auf_kundenserver.de wird relayed).
Nicht wirklich genial, hilft aber gegen den typischen 'gorgeous
teens'-Spammer (mit from: bl...@hotmail.com).
Und solange es offene Relays zu hauf gibt, die jeden Mist annehmen,
wird sich auch kein Spammer die Muehe machen, rueckwaerts nach dem MX
anderer Domains auf dem gleichen Mailsystem zu suchen.
> Oder vielleicht ein beginnendes Umdenken?
Schau dir mal http://relaytest.kundenserver.de/ oder
http://spamblock.kundenserver.de/ an.
Ich denke, das ist schon eine recht eindeutige Haltung:
-spamblock.kundenserver.de: Massenmail-Versender und Spammer ueber
smtp.kundenserver.de werden geblockt und zu smtp-auth gezwungen.
Von dem Moment an koennen die sich bei Complaints ueber ihren Spam aber
auch nicht mehr mit 'war ich doch gar nicht' herausreden,
ab...@kundenserver.de kann sie aber eindeutig identifizieren,
auf ihren Spam festnageln und abmahnen/kuendigen.
Auf der faq.puretec.de und Co wird ja auch seit Ewigkeiten nur
smtp-auth beschrieben, die smtp.kundenserver.de ist dort gar nicht zu finden.
Es ist wahrscheinlich nur noch eine Frage der Zeit, bis man alle
Kunden zu smtp-auth gebracht hat und die Spamschleuder abschalten kann.
Wuerde man die Spamschleudern einfach so abschalten, waeren die
Hotlines am naechsten Tag sicherlich komplett ueberlastet oder tot.
-relaytest.kundenserver.de: jeder Rechner, der auf den MXen Mails einliefert,
wird auf 'offenes Relay' gecheckt und darueber ausgelieferte Mails bekommen
einen zusaetzlichen Warnheader.
-User werden per Header aufgefordert, bei erwuenschter Mail dem Absender
zu sagen, dass sein ISP das offene Relay bitte dichtmachen soll.
Wenn sich Kunden bei ihren ISPs beschweren, duerfte das deutlich
effektiver sein als wenn irgendeine RBL Cronjob-Mails an ISPs
verschickt. Auf diese Weise bekommt man auch die diversen offenen
Relays im geschlossen, die keinem so richtig auffallen.
-Wer als Admin ein offenes Relay hat, kann dieses auch sofort retesten
lassen (also deutlich praktischer als z.B. Osirusoft, die ja lt.
eigener FAQ bis zu einem Monat brauchen, um einen Retest zu machen).
Nach <3c8f8d96...@News.CIS.DFN.DE> zu urteilen scheint das ja auch
zu funktionieren: Gestern abend war 217.115.139.35 noch ein ein offenes
Relay (http://relaytest.kundenserver.de/view.php?id=435388, konnte man
gestern abend noch direkt von point.php?ip=217.115.139.35 aus anklicken),
heute morgen hat es den Status "Relay attempt refused: ok"
(http://relaytest.kundenserver.de/view.php?ip=217.115.139.35).
Schade an dem ganzen ist, dass das ganze nicht grossartig beworben wird,
damit die ganzen Puretec-Kunden endlich auf smtp-auth umstellen und man
die Spamschleudern getrost vom Netz nehmen kann.
Anders
--
http://sysiphus.de/
Peter Lemke
>
> Hendrik Weimer schrieb:
> > Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
>
> Das nervt, ja. Habe mich deswegen als 1&1-Kunde auch mehrfach
> ergebnisfrei bei 1&1 und Schlund beschwert.
>
mrvdom.kundenserver.de ist kein offenes Relay (siehe Posting von
Anders Henke a6pg6q$ndc$1...@news.schlund.de).
> Deswegen nutze ich mittlerweile selbst nur noch Auth-SMTP.
> Aber: 195.20.224.219 = mrvdom.kundenserver.de
> Geblockt wird unter anderem aber auch 195.20.224.89 =
> mout04.kundenserver.de
Osirusoft blockiert das ganze Netz 195.20.224.0/24, in dem unter
anderem die moutNN.kundenserver.de liegen.
Da Osirusoft nicht auf Anfragen antwortet, wird der auth.smtp
mittlerweile über nicht geblockte mouts geroutet. Das wird
hoffentlich zur weiteren Verbreitung der Benutzung authentifizierten
SMTPs beitragen.
Gruß
Peter
Oliver Friedman
>Dummerweise gibt es da auch ein paar tausend Reseller, die ihren Endkunden
>smtp-auth beibringen muessen und viele Leute, die smtp-auth einfach
>nicht in ihren Mailclient einkonfiguriert bekommen oder es einfach nicht
>machen ("tut ja auch so"). Und solange das nicht halbwegs geklaert ist,
>kann man eben auch nicht einfach das halboffene Relay abschalten.
Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape Messenger
das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert, so dass es immer
wieder erneut eingeben werden muss. Wenn man viele E-Mails einzeln über den
Tag hinweg verstreut verschickt, nervt das ungeheuerlich.
Oliver
Marc Langer
> Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape Messenger
> das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert, so dass es immer
> wieder erneut eingeben werden muss. Wenn man viele E-Mails einzeln über den
> Tag hinweg verstreut verschickt, nervt das ungeheuerlich.
Dann sollen die Leute halt entweder den Server ihres Providers benutzen
(die meisten sind ohnehin bei T-Online und können sich für
smtprelay anmelden) oder auf ein anderes Mailprogramm umsteigen.
Marc
Marc Langer
> Hmmm. Ich wusste nicht, dass die www.puretec.de ein offenes Relay
> ist oder zum Spam-Verschicken benutzt wird ...
Vielleicht ein Formmailer? :)
Marc
Oliver Friedman
>Am Thu, 14 Mar 2002 09:53:09 GMT schrieb Oliver Friedman:
>
>> Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape Messenger
>> das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert, so dass es immer
>> wieder erneut eingeben werden muss. Wenn man viele E-Mails einzeln über den
>> Tag hinweg verstreut verschickt, nervt das ungeheuerlich.
>
>Dann sollen die Leute halt entweder den Server ihres Providers benutzen
Das Netscape Messenger-Problem ist eines, das mit dem Server nichts zu tun hat.
Im übrigen benutzen Puretec-Kunden die Server eben dieses Providers.
>(die meisten sind ohnehin bei T-Online
Privatkunden!
und können sich für
>smtprelay anmelden) oder auf ein anderes Mailprogramm umsteigen.
"Surfer", die das Internet zum Spielen benutzen, können zweifelllos
ohne weiteres auf andere Mailprogramme umsteigen. Bei Menschen, die
mit Computern arbeiten, sieht das anders aus. Bei ersteren kann man
allerdings keinerlei Verständnis für Begriffe, wie Workflow,
Produktivität und Ergonomie voraussetzen.
>Marc
Oliver
Sebastian Niehaus
> Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil
> Netscape Messenger das Passwort zur Anmeldung am SMTP-Auth-Server
> nicht speichert, so dass es immer wieder erneut eingeben werden
> muss.
Du verlangst jetzt, daß S/P Rücksicht auf schlecht geschriebene
Software nimmt?
Also, ich weiß ja nicht.
Sebastian
Oliver Friedman
<niehaus-dated-1...@socha.net> wrote:
Wie kommst Du darauf?
Auch wüßte ich nicht, wie sie darauf Rücksicht könnten.
Ich habe lediglich auf ein Problem hingewiesen, das Anwender der
Client-Software davon abhält, Auth zu benutzen.
Oliver
Marc Langer
>>Dann sollen die Leute halt entweder den Server ihres Providers benutzen
>
> Das Netscape Messenger-Problem ist eines, das mit dem Server nichts zu tun hat.
Es hat mit SMTP-Auth zu tun. Die benötigt man aber nur, wenn der
eigene Zugangsprovider keinen nutzbaren SMTP-Server anbietet (denn
der authorisiert normalerweise anhand der IP-Adresse, so dass man
auch ohne Passwort Mail verschicken kann).
> Im übrigen benutzen Puretec-Kunden die Server eben dieses Providers.
Webspace-Provider != Zugangsprovider.
>>(die meisten sind ohnehin bei T-Online
>
> Privatkunden!
Geschäftskunden benutzen keine Zugangsprovider, die keinen eigenen
SMTP-Server anbieten. Nur Billig-Provider (Call-by-Call) tun das nicht.
> "Surfer", die das Internet zum Spielen benutzen, können zweifelllos
> ohne weiteres auf andere Mailprogramme umsteigen. Bei Menschen, die
> mit Computern arbeiten, sieht das anders aus.
Wer das Internet geschäftlich nutzt, ist bei Billigprovidern ohnehin
falsch. Und Firmen haben ohnehin meist einen eigenen Mailserver im
Haus, so dass das Mailprogramm unerheblich ist.
Marc
Christian Holpert
>Schau dir mal http://relaytest.kundenserver.de/ oder
>http://spamblock.kundenserver.de/ an.
Interessant evtl. auch die Warnungen, die puretec inzwischen in
eingehende mails (gestern zum ersten Mal gesehen) einfuegt:
|X-RBL-Warning: (relays.bl.kundenserver.de) mail received via unsecured
|relay host, see http://relaytest.kundenserver.de/point.php?ip=195.27.186.15
Man scheint erkannt zu haben, dass es Probleme mit offenen relays gibt.
Ich hoffe, dass man daraus auch entsprechende Konsequenzen ziehen wird.
Christian
--
Christian Holpert - chri...@holpert.de
Internet kostenlos mit XXL, Einwahlnummern und eine FAQ dazu:
http://www.internet-ortstarif.de
Oliver Friedman
>Am Thu, 14 Mar 2002 12:08:03 GMT schrieb Oliver Friedman:
>
>>>Dann sollen die Leute halt entweder den Server ihres Providers benutzen
>>
>> Das Netscape Messenger-Problem ist eines, das mit dem Server nichts zu tun hat.
>
>Es hat mit SMTP-Auth zu tun. Die benötigt man aber nur, wenn der
>eigene Zugangsprovider keinen nutzbaren SMTP-Server anbietet (denn
>der authorisiert normalerweise anhand der IP-Adresse, so dass man
>auch ohne Passwort Mail verschicken kann).
Ich habe keine feste IP-Adresse, da ich weder einen Web- noch einen
Mail-Server im Hause habe. Dafür (E-Commerce) besteht in Ingenieurbüros,
bei Softwareentwicklen und dergleichen kein Bedarf. Was dagegen erforderlich
ist, ist 10 bis 30 mal täglich ein auf wenige Sekunden bis Minuten beschränkter
Zugriff auf's Internet, um E-Mails auszutauschen.
Die kostengünstigste Lösung für mich war daher Webspace und POP3 von Schlund
plus Dialup-Zugang vom Drittanbieter. Würde denn Auth ohne das Netscape
Messenger-Problem möglich sein, wenn ich den DialUp-Account ebenfalls
bei Schlund/Puretec hätte?
>Geschäftskunden benutzen keine Zugangsprovider, die keinen eigenen
>SMTP-Server anbieten. Nur Billig-Provider (Call-by-Call) tun das nicht.
>[snip]Und Firmen haben ohnehin meist einen eigenen Mailserver im
>Haus, so dass das Mailprogramm unerheblich ist.
Die meisten Unternehmen heißen nicht Siemens und haben keinen eigenen
Server. Und was das Vorhandensein eines eigenen Mailservers mit
der Wahl des Mailprogramms zu tun haben sollte, bleibt schleierhaft.
Dabei spielen die Leistungsmerkmale des Programms eine Rolle sowie
mit einer Umstellung verbundene betriebswirtschaftliche Verluste
(Portieren der alten Nachrichten, damit sie im Zugriff bleiben,
Einrichten der Filter für die Eingangsablage, Schulung der
Mitarbeiter, etc.).
Ich portiere seit 1983 meine Korrespondenz und Datenbanken auf neue
Systeme und meine Neigung, das zu tun, ist von Mal zu Mal geringer
geworden.
Oliver
Marc Langer
> Die kostengünstigste Lösung für mich war daher Webspace und POP3 von Schlund
> plus Dialup-Zugang vom Drittanbieter. Würde denn Auth ohne das Netscape
> Messenger-Problem möglich sein, wenn ich den DialUp-Account ebenfalls
> bei Schlund/Puretec hätte?
Weiß ich nicht. Musst Du halt mal nachfragen.
> Die meisten Unternehmen heißen nicht Siemens und haben keinen eigenen
> Server.
Etliche aber doch. Zumindest ist das bei unseren Kunden nicht unbedingt
selten, gerade heutzutage, wo häufig eine serverbasierte
Virenschutz-Lösung eingesetzt wird.
> Und was das Vorhandensein eines eigenen Mailservers mit
> der Wahl des Mailprogramms zu tun haben sollte, bleibt schleierhaft.
Dass das Mailprogramm dann keine SMTP-Auth bzw. Passwortspeicherung
mehr machen muss, weil man den eigenen SMTP-Server passend
konfigurieren kann.
Marc
Marc Langer
> Dabei spielen die Leistungsmerkmale des Programms eine Rolle sowie
> mit einer Umstellung verbundene betriebswirtschaftliche Verluste
> (Portieren der alten Nachrichten, damit sie im Zugriff bleiben,
> Einrichten der Filter für die Eingangsablage, Schulung der
> Mitarbeiter, etc.).
Hierzu noch ein Kommentar: Jeder beschwert sich über zunehmenden
Spam und unerwünschte Mails, und verlangt vom Provider, etwas dagegen
zu tun. Zumindest aus meiner Erfahrung (Mailserver-Administrator und
Kunden-Support im Bereich Mail und Internet-Zugang).
Auf der anderen Seite sind diese Personen aber teilweise nicht bereit
einzusehen, dass entsprechende Schutzmaßnahmen Einschränkungen
bedeuten, z.B. Zugangsbeschränkungen zu Mailservern und Führen von
Blacklists.
Der Provider muss zusehen, dass er seine Systeme möglichst dicht
kriegt, denn die Verluste durch schlechtes Image wegen Nichtstun gegen
offene Mailrelays dürften höher liegen als die von ein paar
unzufriedenen Kunden verursachten, die sich keinen vernünftigten
Internetzugang oder keine vernünftige Mailsoftware leisten können.
Aus meiner Sicht geht es bei Puretec nicht um die Einstellung eines
Dienstes, sondern um die Beseitigung eines offenen
Spammer-Scheunentors, die schon längst überfällig ist.
Marc
Jens Wahnes
> On 14 Mar 2002 12:40:30 GMT, Marc Langer <re...@marclanger.de> wrote:
> Was dagegen erforderlich ist, ist 10 bis 30 mal täglich ein auf
> wenige Sekunden bis Minuten beschränkter Zugriff auf's Internet, um
> E-Mails auszutauschen.
> Die kostengünstigste Lösung für mich war daher Webspace und POP3 von Schlund
> plus Dialup-Zugang vom Drittanbieter. Würde denn Auth ohne das Netscape
> Messenger-Problem möglich sein, wenn ich den DialUp-Account ebenfalls
> bei Schlund/Puretec hätte?
[...]
> Die meisten Unternehmen heißen nicht Siemens und haben keinen eigenen
> Server. Und was das Vorhandensein eines eigenen Mailservers mit
> der Wahl des Mailprogramms zu tun haben sollte, bleibt schleierhaft.
Von was für "Unternehmen" sprichst du denn? Und warum sollten die keine
eigenen Mailserver haben (ich meine natürlich eine Software, nicht
unbedingt eine Hardware-Kiste, die ausschließlich Mail macht)? Wenn es
um überschaubare Kleinbetriebe mit vielleicht einem dutzend
Mitarbeitern geht, bei denen das Anlegen und die Pflege von Accounts
"von Hand" kein Problem ist, könnte man in diesem Fall einfach den
Hamster nehmen, der die Mails holt und verschickt. Der ist kostenlos,
einfach zu konfigurieren (d.h., auch WinDAUs bekommen das hin) und kann
automatisiert Mails (inkl. Dialup) abrufen und für lokale Clients
vorhalten. Auch können Clients ihre ausgehenden Mails einfach per SMTP
bei ihm abkippen, er leitet die dann auch per SMTP-AUTH an einen
Smarthost weiter. Dank einer integrierten, einfachen Skriptsprache
lässt sich das ganze auch für etwas kompliziertere Fälle anpassen.
Jens
Oliver Friedman
>Von was für "Unternehmen" sprichst du denn?
10 bis 20 Arbeitsplätze, im Regelfall bestenfalls "historische"
Unix-Kenntnisse und keine Zeit.
>Und warum sollten die keine
>eigenen Mailserver haben (ich meine natürlich eine Software, nicht
>unbedingt eine Hardware-Kiste, die ausschließlich Mail macht)?
Da hab' ich offenbar was verpaßt!
>Wenn es
>um überschaubare Kleinbetriebe mit vielleicht einem dutzend
>Mitarbeitern geht, bei denen das Anlegen und die Pflege von Accounts
>"von Hand" kein Problem ist, könnte man in diesem Fall einfach den
>Hamster nehmen, der die Mails holt und verschickt.
Habe den gerade gefunden (http://home.t-online.de/home/micha-wr/hamster/)
und bin begeistert! Vielen Dank für den Tip, der, finde ich, in die FAQ
gehört!
>Der ist kostenlos,
>einfach zu konfigurieren (d.h., auch WinDAUs bekommen das hin) und kann
>automatisiert Mails (inkl. Dialup) abrufen und für lokale Clients
>vorhalten. Auch können Clients ihre ausgehenden Mails einfach per SMTP
>bei ihm abkippen, er leitet die dann auch per SMTP-AUTH an einen
>Smarthost weiter. Dank einer integrierten, einfachen Skriptsprache
>lässt sich das ganze auch für etwas kompliziertere Fälle anpassen.
>
>
>Jens
Nochmals Danke!
Oliver
Oliver Friedman
Ich denke, dass wir uns jetzt einig werden. Aufwand und Ertrag müssen
in einem angemessenen Verhältnis zueinander stehen, und wegen des SPAMs
beim Anwender den gesamten E-Mail-Workflow umzukrempeln ist heute
wohl im Regelfall noch nicht zu rechtfertigen.
Aber auch auch gar nicht *notwendig*, wenn der Hamster hält, was er
verspricht!
Oliver
Markus Ammann
Oliver Friedman wrote:
> Die kostengünstigste Lösung für mich war daher Webspace und POP3 von Schlund
> plus Dialup-Zugang vom Drittanbieter. Würde denn Auth ohne das Netscape
> Messenger-Problem möglich sein, wenn ich den DialUp-Account ebenfalls
> bei Schlund/Puretec hätte?
Was Netscape betrifft, da ist das Passwort für SMTP-Authentifizierung
nur einmal nach *Programmstart* einzutippen.
Solange dann Netscape läuft, bleibt dieser gespeichert.
Wenn man es mal zwischendurch beendet und neu aufstartet, so wäre
dann bei erneuten E-Mail-Versand das Passwort erneut einzutippen.
Gruss Markus
--
Windows-Crash-Service
file:///C|/con/con file:///C|/nul/nul Mehr dazu auf:
http://www.microsoft.com/technet/security/bulletin/ms00-017.asp
Homepage: http://markus.ammann.buz.ch/
Hendrik Weimer
> Joachim Deckers wrote:
> >
> > Hendrik Weimer schrieb:
> > > Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
> >
> > Das nervt, ja. Habe mich deswegen als 1&1-Kunde auch mehrfach
> > ergebnisfrei bei 1&1 und Schlund beschwert.
>
> mrvdom.kundenserver.de ist kein offenes Relay (siehe Posting von
> Anders Henke a6pg6q$ndc$1...@news.schlund.de).
Natürlich ist es das (und Anders hat das auch gar nicht
bestritten). Wie wäre es zur Abwechslung einmal mit vorher
informieren?
Hendrik
Peter Lemke
Unter offenem Relay verstehe ich eine Server, der Mails von beliebigen
Absendern von beliebigen IPs an beliebige Empfänger versendet. Um über
mrvdom.kundenserver.de Mails relayen zu können, braucht man eine bei
Schlund liegende Domain. Das bedeutet, Du mußt zum Versenden von Mails
zumindest den Sender fälschen. Ich kenne zwar keine Rechtsprechung dazu,
kann mir aber gut vorstellen, dass das in schwerwiegenden Fällen
strafbar ist.
Peter
michael hufnagl
dev...@oliverfriedman.de (Oliver Friedman) wrote in
news:3c909caa...@News.CIS.DFN.DE:
>>>>Dann sollen die Leute halt entweder den Server ihres Providers
>>>>benutzen
>>>
>>> Das Netscape Messenger-Problem ist eines, das mit dem Server nichts
>>> zu tun hat.
>>
>>Es hat mit SMTP-Auth zu tun. Die benötigt man aber nur, wenn der
>>eigene Zugangsprovider keinen nutzbaren SMTP-Server anbietet (denn
>>der authorisiert normalerweise anhand der IP-Adresse, so dass man auch
>>ohne Passwort Mail verschicken kann).
>
> Ich habe keine feste IP-Adresse, da ich weder einen Web- noch einen
das meint marc auch nicht.
freilich hat man gewoehlich eine dyn. IP. aber diese stammt immer aus dem
pool des zugangsproviders. es spricht nichts dagegen, wenn der
zugangsprovider seine smtp-server fuer diese IP-range ganz auf macht. kein
smtp-auth, kein smtp-after-pop3, kein pseudoschutz ala 'domain im from'.
wozu aus? der zugangsprovider kann sich jederzeit anhand der uhrzeit und
der IP den user greifen und gegebenenfalls verhauen.
> Die kostengünstigste Lösung für mich war daher Webspace und POP3 von
> Schlund plus Dialup-Zugang vom Drittanbieter. Würde denn Auth ohne das
und genau dieser drittanbieter hat keinen smtp-server, den du verwenden
koenntest? naja... 'wir koennen nur billig' mag wirklich nicht die beste
loesung fuer einen zugang sein, mit dem auch gearbeitet werden muss.
>>[snip]Und Firmen haben ohnehin meist einen eigenen Mailserver im
>>Haus, so dass das Mailprogramm unerheblich ist.
da kann ich marc zum glueck nicht recht geben. 's gibt ohnehin schon genug
exchange-schuesseln, mehr muss nicht sein... :-|
cu
micha
Henning Schlottmann
> Hendrik Weimer wrote:
> >
> > > mrvdom.kundenserver.de ist kein offenes Relay (siehe Posting von
> > > Anders Henke a6pg6q$ndc$1...@news.schlund.de).
> >
> > Natürlich ist es das (und Anders hat das auch gar nicht
> > bestritten). Wie wäre es zur Abwechslung einmal mit vorher
> > informieren?
>
> Unter offenem Relay verstehe ich eine Server, der Mails von beliebigen
> Absendern von beliebigen IPs an beliebige Empfänger versendet. Um über
> mrvdom.kundenserver.de Mails relayen zu können, braucht man eine bei
> Schlund liegende Domain. Das bedeutet, Du mußt zum Versenden von Mails
> zumindest den Sender fälschen.
Ja und? Nahezu jede UCE, die bei mir eintrifft, hat einen frei
erfundenen oder fremden Eintrag als "from". Das ist Standard bei
Spammern.
Die Server sind offen wie ein Scheunentor, für jeden, der auch nur eine
dort gehostete Domain kennt.
> Ich kenne zwar keine Rechtsprechung dazu,
> kann mir aber gut vorstellen, dass das in schwerwiegenden Fällen
> strafbar ist.
Nein, die Angabe eines falschen Absenders ist zunächst mal keine
Straftat (jedenfalls nach deutschem Recht).
Ciao Henning
Diedrich Ehlerding
>
> Unter offenem Relay verstehe ich eine Server, der Mails von beliebigen
> Absendern von beliebigen IPs an beliebige Empfänger versendet.
Exakt.
> Um über
> mrvdom.kundenserver.de Mails relayen zu können, braucht man eine bei
> Schlund liegende Domain.
Ach was. Man braucht nur im Envelope zu behaupten, man sei
zum Beispiel "postm...@kundenserver.de". Man braucht nur
eine dort gehostet Domain zu kennen - mehr nicht.
> Das bedeutet, Du mußt zum Versenden von Mails
> zumindest den Sender fälschen.
Ja. Aber es wäre Schlunds Aufgabe, die _Möglichkeit_, auf diese
Weise Mail zu versenden, zu unterbinden. Jeder kann den
mrvdom.kundenserver.de missbrauchen.
> Ich kenne zwar keine Rechtsprechung dazu,
> kann mir aber gut vorstellen, dass das in schwerwiegenden Fällen
> strafbar ist.
Ja und? Stört das die Spammer? Selbst wenn es so ist: ist insoweit
deutsches Strafrecht durchsetzbar gegen einen Übeltäter aus, sagen
wir mal, Russland? Und hat Schlund schon mal versucht, gegen einen
ihren Server missbrauchenden Spamnmer vorzugehen? Nein? Aha.
Diedrich
--
pgp-Key (RSA) 1024/09B8C0BD auf den üblichen Servern
fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3
Anders Henke
>> Um ?ber
>> mrvdom.kundenserver.de Mails relayen zu k?nnen, braucht man eine bei
>> Schlund liegende Domain.
> Ach was. Man braucht nur im Envelope zu behaupten, man sei
> zum Beispiel "postm...@kundenserver.de". Man braucht nur
> eine dort gehostet Domain zu kennen - mehr nicht.
anders@mupfel:~$ telnet smtp.puretec.de 25
Trying 195.20.224.219...
Connected to smtp.puretec.de.
Escape character is '^]'.
220 mrvdom03.kundenserver.de ESMTP Exim 2.12 #2 Thu, 14 Mar 2002
21:32:26 +0100
helo blah
250 mrvdom03.kundenserver.de Hello blah [194.121.21.248]
mail from: postm...@kundenserver.de
550 rejected: administrative prohibition
quit
221 mrvdom03.kundenserver.de closing connection
Hmmm. Also der Dummuser-Test mit 'localpart@domain_aus_reverse_von_ip' taugt
nicht, es muss schon ein-zwei Nummern weiter gehen. Soweit muss aber doch
kein Spammer gehen, schliesslich laufen da draussen doch Hunderttausende
von komplett offenen Relays herum, die bedingungslos Mail annehmen und
weiterverteilen.
Da suche ich mir als Spammer doch lieber eines der richtig offenen Relays
oder ich liefere direkt von meiner Dialin-IP an MXe aus.
Per RFC ist ja auch jeder MX dazu verpflichtet, fuer mindestens 100 Recipients
Mail anzunehmen, da kann man locker seinen Spam einmal vorsortieren
lassen und dann gesammelt in einer Handvoll Connections direkt ausliefern.
>> Das bedeutet, Du mu?t zum Versenden von Mails
>> zumindest den Sender f?lschen.
> Ja. Aber es w?re Schlunds Aufgabe, die _M?glichkeit_, auf diese
> Weise Mail zu versenden, zu unterbinden. Jeder kann den
> mrvdom.kundenserver.de missbrauchen.
Helfe doch bitte aktiv gegen Spam mit, indem du dich einfach mal
bei Schlund/Puretec meldest und du im Kampf fuer Gerechtigkeit und
gegen den Spam dann den 1,3 Mio Kunden smtp-auth beibringst.
Genau das probieren Schlund/Puretec doch schon seit einer halben Ewigkeit.
auth.smtp.kundenserver.de gibt es inzwischen seit einem Jahr fuer
Schlund-Kunden, seit ueber einem Dreivierteljahr wird es fuer Puretec-Kunden
als eines der Features von 'Puretec 3.0' verkauft. faq.puretec.de sowie
service.schlund.de beschreiben auch nur smtp-auth und erklaeren fuer
verschiedene MUAs, wie man diesen smtp-auth beibringt.
Allerdings vermute ich, dass entweder smtp-auth den Puretec-Kunden
einfach nicht klar genug vor Augen liegt oder einfach nicht von
sonderlich hoher Akzeptanz gekroent ist:
anders@mupfel:~$ host smtp.puretec.de
smtp.puretec.de CNAME smtp.kundenserver.de
smtp.kundenserver.de CNAME mrvdom.kundenserver.de
mrvdom.kundenserver.de A 195.20.224.220
mrvdom.kundenserver.de A 212.227.126.161
mrvdom.kundenserver.de A 212.227.126.155
mrvdom.kundenserver.de A 195.20.224.204
mrvdom.kundenserver.de A 195.20.224.219
anders@mupfel:~$ host auth.smtp.puretec.de
auth.smtp.puretec.de CNAME auth.smtp.kundenserver.de
auth.smtp.kundenserver.de A 212.227.126.160
Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
mindestens fuenfmal so vielen Rechnern wie das authentifizierende System.
Das spricht nicht gerade fuer eine hohe Akzeptanz seitens der Kunden, denn
sonst waeren die Spamschleudern wohl laengst abgeschaltet oder zumindest
die Anzahl der Rechner haetten ein anderes Verhaeltnis.
Sofortiges Abschalten der Spamschleuder wuerde bedeuten, dass garantiert
alle Kunden gleichzeitig ueber die Hotline hereinbrechen - faellt flach.
Stufenweises Abschalten der Spamschleuder-Rechner fuehrt zu boeser Presse
"der Puretec-Mailserver ist sooooo langsam" (schliesslich will ja
offensichtlich keiner smtp-auth benutzen).
Der naechste Schritt kann nur sein, dass man den Kunden noch einmal
gut zuredet (forget it) oder sie ueber Restriktionen vom Spamsystem mehr
oder weniger elegant weglotst und quasi zu ihrem Glueck in Form des
authentifizierenden Systems zwingt.
Und http://spamblock.kundenserver.de/ kann man durchaus als einen
Schritt in genau diese Richtung interpretieren, denn dem Versand
per Spamschleuder werden eben Restriktionen auferlegt, die man bei
der Alternative smtp-auth eben nicht hat und auf die auch hingewiesen
wird.
Und von spamfreundlich kann dabei ja auch keine Rede sein ...
http://relaytest.kundenserver.de/faq.php:
"If you received spam promoting services hosted at our site or received
spam through mout*.kundenserver.de, please contact abuse (at)
kundenserver.de.
Spamming is a strict violation against our Terms of Service and offending
customers are being warned after their first violation, upon further
violations we also do temporarily shut down access to the customers site
or cancel their contracts."
http://spamblock.kundenserver.de/:
"Bitte beachten Sie jedoch, das der Versand nicht angeforderter Mails -
insbesondere zu Werbezwecken - rechtswidrig ist und auch in unseren AGBs
ausdrücklich untersagt wird. Ein wiederholter Verstoß kann zu Sperrung und
Kündigung der Präsenz führen."
> Ja und? St?rt das die Spammer? Selbst wenn es so ist: ist insoweit
> deutsches Strafrecht durchsetzbar gegen einen ?belt?ter aus, sagen
> wir mal, Russland?
Naja. Das macht derjenige einmal, danach konfiguriert man halt
fuer halb Russland einen Netzblock auf smtp.kundenserver.de ein.
So viele Kunden werden ja nicht aus Russland Mail schicken wollen - und
wer es dennoch will, muss halt smtp-auth verwenden ...
> Und hat Schlund schon mal versucht, gegen einen
> ihren Server missbrauchenden Spamnmer vorzugehen?
Das kann nur Schlund beantworten, alles andere waere Mutmassung und
Geruechte-Streuerei. Man waere aber schoen doof, wenn man nichts
gegen Spammer im eigenen Kundenkreis oder Ressourcenmissbrauch taete;
aber anscheinend wird ja doch etwas gegen Spam getan.
Anders
--
http://www.sysiphus.de/
Anders Henke
> Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape
> Messenger das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert,
> so dass es immer wieder erneut eingeben werden muss.
Dann entspricht das Userinterface deines MUA nicht deinen Forderungen.
Wende dich an den Hersteller der Software oder tausche die Software aus.
> Wenn man viele E-Mails einzeln ?ber den Tag hinweg verstreut verschickt,
> nervt das ungeheuerlich.
Lese ich das richtig, dass aufgrund einer schlechte Implementation des
Userinterfaces von smtp-auth in einem bestimmten MUA die Spamschleudern
von Schlund/Puretec offenbleiben sollen?
Oder erwartest du, dass Schlund fuer dich einen offensichtlich
untauglichen MUA fixt?
Nimm doch einfach den Relayserver deines Einwahlproviders.
Dein Einwahlprovider kann anhand der IP eindeutig "der darf relayen"
feststellen und hat damit das einfachste wie sicherste Mittel, um
eindeutig Relaykontrolle zu betreiben. Abgesehen davon sind auch die Wege
zum Smarthost deines Einwahlproviders kuerzer als zu jedem anderen Host ...
Selbst die grossen Callbycall-Anbieter bieten einem einen Smarthost an,
lediglich ein paar Billigheimer verweisen stattdessen gerne auf
oeffentliche Newsserver (statt einem eigenen) oder irgendwelche offenen
Relays (statt einem eigenen, sicherem Relay). Und solche Schmarotzer-ISPs
wirst du doch nicht ernsthaft foerdern wollen?
smtp.puretec.de war wichtig, als man noch beim Versand ueber mail.btx.dtag.de
noch ein Zwangs-From aus der Userkennung bekam und nur mit dem externen
Relay seine Domain auch als Mailadresse wirklich immer fuehren konnte.
Seit dem smtprelay.t-online.de ist das aber auch nicht mehr noetig.
Wenn nicht so viele Puretec-Kunden auf die Idee verfallen wuerden, ihre
Mail zwanghaft bei Puretec statt bei ihrem Einwahl-ISP einzukippen, waere
das ganze auch kein Problem und man koennte bei Puretec sowohl smtp-auth
wie auch offenes Relay komplett abschalten. Diesen Moment werden wir
aber wohl nie erleben ...
Anders
--
http://www.sysiphus.de/
Hendrik Weimer
> Unter offenem Relay verstehe ich eine Server, der Mails von beliebigen
> Absendern von beliebigen IPs an beliebige Empfänger versendet.
Ein offenes Relay ist ein Server, der keine oder unzureichende
Maßnahmen durchführt, um den Absender zu authentifizieren. Wenn
IP-Segmente freigeschaltet sind, über die der Betreiber keine
Kontrolle hat, ist das auch scheiße.
> Um über mrvdom.kundenserver.de Mails relayen zu können, braucht man
> eine bei Schlund liegende Domain.
Nein. Ich bin nicht Kunde von Schlund oder Puretec, kann aber trotzdem
nach Herzenslust über diesen Server Mails versenden.
> Das bedeutet, Du mußt zum Versenden von Mails zumindest den Sender
> fälschen. Ich kenne zwar keine Rechtsprechung dazu, kann mir aber
> gut vorstellen, dass das in schwerwiegenden Fällen strafbar ist.
Seit wann hat das auch nur einen Spammer interessiert?
Hendrik
Joachim Deckers
> Nimm doch einfach den Relayserver deines Einwahlproviders.
Und was machen die 1&1-Kunden (wie ich), die 1&1 als Einwahlprovider
_und_ Webspaceprovider nutzen?
Ich las schon vorher den Hinweis: Einwahlprovider != Webspaceprovider
Der ist in dieser Form nicht korrekt!
> Wenn nicht so viele Puretec-Kunden auf die Idee verfallen wuerden, ihre
> Mail zwanghaft bei Puretec statt bei ihrem Einwahl-ISP einzukippen, waere
> das ganze auch kein Problem und man koennte bei Puretec sowohl smtp-auth
> wie auch offenes Relay komplett abschalten. Diesen Moment werden wir
> aber wohl nie erleben ...
Aus eben dem genannten Grund. (Und ich werde nicht zu einem teureren
Provider wechseln. Oder wer bietet mir sonst schon einen günstigeren
Tarif für ca. 50 - 80 Stunden mtl. DSL-Nutzung an?)
Gruß
Joachim
Marc Langer
>>>[snip]Und Firmen haben ohnehin meist einen eigenen Mailserver im
>>>Haus, so dass das Mailprogramm unerheblich ist.
>
> da kann ich marc zum glueck nicht recht geben. 's gibt ohnehin schon genug
> exchange-schuesseln, mehr muss nicht sein... :-|
Da ist bloß der Vertrieb gefragt, den Kunden eine Unix-Lösung inkl.
Einweisugn und Support zu verkaufen ;-)
Marc
Thomas Hochstein
> auth.smtp.kundenserver.de gibt es inzwischen seit einem Jahr fuer
> Schlund-Kunden, seit ueber einem Dreivierteljahr wird es fuer Puretec-Kunden
> als eines der Features von 'Puretec 3.0' verkauft. faq.puretec.de sowie
> service.schlund.de beschreiben auch nur smtp-auth und erklaeren fuer
> verschiedene MUAs, wie man diesen smtp-auth beibringt.
Schön wäre es ja ...
http://faq.puretec.de/mail_news_ums/mailclients_einrichten/1.html
http://faq.puretec.de/mail_news_ums/mailclients_einrichten/5.html
http://faq.puretec.de/mail_news_ums/mailclients_einrichten/8.html
Bei der Suche nach Mail findet sich (fettgedruckt) erst der Hinweis
auf die Einrichtung von Mailclients in der FAQ, und da steht in Text
und Screenshots eben nicht der SMTP-Auth-Server. Es ist richtig, es
findet sich auch ein Verweis auf die "sichere Alternative zum normalen
SMTP" - aber bitte, welcher Nutzer würde dahinter irgendetwas mit
E-Mail vermuten? SMTP - kann man das essen? ;-)
Erklärt ist übrigens die Einrichtung von SMTP-Auth nur für OE.
Gruß,
-thh
--
FAQ der Newsgroup: http://home.snafu.de/laura/de.admin.net-abuse.mail.txt
Adreßfälscher-FAQ: http://home.pages.de/~gerlo/falsche-email-adressen.html
E-Mail-Header-FAQ: http://www.th-h.de/faq/headrfaq.html
Viren-/Würmer-FAQ: http://www.th-h.de/faq/hybris.html
Rainer Zocholl
>Interessanterweise ist aber das gesamte Netz gelistet:
>anders@ista:~$ host 18.225.20.195.relays.osirusoft.com
>18.225.20.195.relays.osirusoft.com A 127.0.0.4
>Hmmm. Ich wusste nicht, dass die www.puretec.de ein offenes Relay
>ist oder zum Spam-Verschicken benutzt wird ...
form mails?
>Puretec hostet ein paar Mio .de-Domains mit entsprechend vielen Kunden
>- und solange nicht jemand jede Kundenmail vor dem Ausliefern einzeln
>gegen die 'Spamming verboten'-Klausel der Puretec-AGBs vergleicht, ist
>da eben auch viel Spam dabei.
Sicherlich haben solche Unternehmungien wie osirusoft ein Problem
mit der "Einschätzung" was sie da gerade sperren...
Vgl. spamspade, der gmx wegen "zu hohem Spamanteil" gelistet hatte.
Von 47(!) mails waren 15 Spam...
Rainer Zocholl
>Allerdings vermute ich, dass entweder smtp-auth den Puretec-Kunden
>einfach nicht klar genug vor Augen liegt oder einfach nicht von
>sonderlich hoher Akzeptanz gekroent ist:
>anders@mupfel:~$ host smtp.puretec.de
>smtp.puretec.de CNAME smtp.kundenserver.de
>smtp.kundenserver.de CNAME mrvdom.kundenserver.de
>mrvdom.kundenserver.de A 195.20.224.220
>mrvdom.kundenserver.de A 212.227.126.161
>mrvdom.kundenserver.de A 212.227.126.155
>mrvdom.kundenserver.de A 195.20.224.204
>mrvdom.kundenserver.de A 195.20.224.219
>anders@mupfel:~$ host auth.smtp.puretec.de
>auth.smtp.puretec.de CNAME auth.smtp.kundenserver.de
>auth.smtp.kundenserver.de A 212.227.126.160
>Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
>mindestens fuenfmal so vielen Rechnern wie das authentifizierende
>System.
Wie kommst Du auf dieses dünne Sprungtuch von der Anzahl der
Ip-# auf die Anzahl der Server schliessen zu wollen?
Weder muessen
mrvdom.kundenserver.de A 195.20.224.220
mrvdom.kundenserver.de A 212.227.126.161
mrvdom.kundenserver.de A 212.227.126.155
mrvdom.kundenserver.de A 195.20.224.204
mrvdom.kundenserver.de A 195.20.224.219
verschiedene Rechner sein, noch muss
auth.smtp.kundenserver.de A 212.227.126.160
ein einziger Rechner sein.
Rainer Zocholl
>Hendrik Weimer schrieb:
>> Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
>Das nervt, ja. Habe mich deswegen als 1&1-Kunde auch mehrfach
>ergebnisfrei bei 1&1 und Schlund beschwert.
BTW:
Bekommst Du eigentlich ne Fehlermeldung von Schlund, oder
kommt die eMail "einfach nur nicht an"?
>Deswegen nutze ich mittlerweile selbst nur noch Auth-SMTP.
>Aber: 195.20.224.219 = mrvdom.kundenserver.de
>Geblockt wird unter anderem aber auch 195.20.224.89 =
>mout04.kundenserver.de
Weil von dort und noch ein paar anderen "Kundenserver"-Addressen
massenweise (zu zig tausenden!) "formmailer"-spam kommen.
Schlund rotiert auch gerne die IP-Nummern der Mailout-Rechner.
Insofern sind die ganz zu recht geblockt.
Die RBL-Leute haben -verständlicherweise- keinen Bock zu solchem
Kinderkram, den Schlund da versucht und sind auch nicht so
doof wie Schund sie zuhalten scheint.
Die Server von schlund sind wohl zu dem so asozial eingestellt, dass
sie solange zu fremden Servern weitere Connects aufmachen
(ohne auf den ersten connects mehr als den SMTP-Header losgeworden
zusein), bis diese Server platt sind. Das stört die Schlund-Server
aber garnicht, denn dann machen sie ebend die MXe auch noch platt...
Das ist hier nicht einmal, nicht zweimal sondern inzwischen
dreimal innerhalb von 10 Tagen passiert!
Anscheinnend bekommt Schlund die Formmail-Relays nicht in den Griff.
Und auf wirklich *freundliche* Anschreiben unserer Postmaster gab
es -natürlich(?)- keinerlei Reaktion, (sondern 2 tage später die
nächste Spamwelle.).
Rainer Zocholl
>> Ich habe keine feste IP-Adresse, da ich weder einen Web- noch einen
>freilich hat man gewoehlich eine dyn. IP. aber diese stammt immer aus
>dem pool des zugangsproviders. es spricht nichts dagegen, wenn der
>zugangsprovider seine smtp-server fuer diese IP-range ganz auf macht.
>kein smtp-auth, kein smtp-after-pop3, kein pseudoschutz ala 'domain im
>from'. wozu aus? der zugangsprovider kann sich jederzeit anhand der
>uhrzeit und der IP den user greifen und gegebenenfalls verhauen.
Klasse.
Und wenn der liebe Kunde einen Offenen Proxy ("WinProxy" ist ja sooooo
einfach zu installieren) installiert hat, oder mit Suse rumgespielt
hat und ein offenes Relay gebaut hat, weil seine Leute im LAN
auch mails verschicken sollten, geht der Spam erstmal stundenlang raus!
Klingt nicht unkritisch. (Für den Empfänger der Junk mails).
Rainer Zocholl
>On 14 Mar 2002 06:32:58 GMT, Anders Henke wrote:
>>Schau dir mal http://relaytest.kundenserver.de/ oder
>>http://spamblock.kundenserver.de/ an.
>Interessant evtl. auch die Warnungen, die puretec inzwischen in
>eingehende mails (gestern zum ersten Mal gesehen) einfuegt:
>|X-RBL-Warning: (relays.bl.kundenserver.de) mail received via
>unsecured |relay host, see http://relaytest.kundenserver.de/point.php?
>ip=195.27.186.15
>Man scheint erkannt zu haben, dass es Probleme mit offenen relays
>gibt.
Ausser mit den eigenen.. ;-)
>Ich hoffe, dass man daraus auch entsprechende Konsequenzen
>ziehen wird.
Und eine eigene Blacklist dem Netz zur Verfügung stellen?
Wäre ja ganz was neues, das Schlund den Commons etwas zurückgibt?
http://relaytest.kundenserver.de/faq.php
I'd like to use your list for my own server.
This list is not for public usage.
Naja. Alles andere hätte mich auch SCHWER (angenehm) überrascht!
Simon Kissel
Peter Lemke (net-abu...@pline.de) wrote:
> Unter offenem Relay verstehe ich eine Server, der Mails von beliebigen
> Absendern von beliebigen IPs an beliebige Empfänger versendet. Um über
> mrvdom.kundenserver.de Mails relayen zu können, braucht man eine bei
> Schlund liegende Domain. Das bedeutet, Du mußt zum Versenden von Mails
> zumindest den Sender fälschen. Ich kenne zwar keine Rechtsprechung dazu,
> kann mir aber gut vorstellen, dass das in schwerwiegenden Fällen
> strafbar ist.
Selbst wenn es strafbar WÄRE würdet Ihr doch eh nichts dagegen
unternehmen.
Ich habe noch NIE eine Antwort auf Mails an Euere Abuse-Abteilung
bekommen. Davon mal abgesehen hosted Ihr nach wie vor jede Menge
Spammmer.
Es ist schade, daß Ihr nur als offenes Relay gelisted seit, und nicht
z.B. bei Spews.
Aber es ist ja schonmal ein schönes Zeichen, daß der Druck durch Eure
Kunden anscheinend langsam wächst und sich hier mal jemand von Euch
blicken lässt.
Jetzt wäre es an der Zeit zum Chef zu gehen und zu sagen "Ich glaube
wir sollten uns ein Abuse-Management anschaffen, da wir sonst
zunehmende Probleme kriegen".
Simon
Marc Haber
>Ja und? Nahezu jede UCE, die bei mir eintrifft, hat einen frei
>erfundenen oder fremden Eintrag als "from". Das ist Standard bei
>Spammern.
>
>Die Server sind offen wie ein Scheunentor, für jeden, der auch nur eine
>dort gehostete Domain kennt.
Fakt ist, dass es so viele komplett offene Relays gibt, dass sich kein
ernsthafter Spammer mit überlasteten (=langsamen) halboffenen Relays
abgibt.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Marc Haber
>Die Server von schlund sind wohl zu dem so asozial eingestellt, dass
>sie solange zu fremden Servern weitere Connects aufmachen
>(ohne auf den ersten connects mehr als den SMTP-Header losgeworden
>zusein), bis diese Server platt sind. Das stört die Schlund-Server
>aber garnicht, denn dann machen sie ebend die MXe auch noch platt...
Diesen Vorwurf möchtest Du belegen. IIRC kann man einen exim gar nicht
so konfigurieren.
Oliver Friedman
>Oliver Friedman <dev...@oliverfriedman.de> wrote:
>> Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape
>> Messenger das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert,
>> so dass es immer wieder erneut eingeben werden muss.
>
>Dann entspricht das Userinterface deines MUA nicht deinen Forderungen.
>Wende dich an den Hersteller der Software oder tausche die Software aus.
Das ist genau die Haltung, mit der Du nichts konstruktives erreichen wirst!
Sowohl der Anwender als auch der ISP sind durch Spam genervt. Dem Anwender
aber lediglich an den Kopf zu knallen, er solle gefälligst seinen Arbeits-
fluß umstellen, statt ihm Wege aufzuzeigen, wie er dies mit geringstmöglicher
Belastung tun kann, führt bei diesem lediglich zur Blockade.
Ebenso wenig hilfreich ist es, wenn Anwender ISPs mit Beschwerden vollmüllen
ohne selbst an der Lösung des Problems mitzuwirken.
>> Wenn man viele E-Mails einzeln ?ber den Tag hinweg verstreut verschickt,
>> nervt das ungeheuerlich.
>
>Lese ich das richtig, dass aufgrund einer schlechte Implementation des
>Userinterfaces von smtp-auth in einem bestimmten MUA die Spamschleudern
>von Schlund/Puretec offenbleiben sollen?
>
>Oder erwartest du, dass Schlund fuer dich einen offensichtlich
>untauglichen MUA fixt?
Fällt Dir eine dritte Variante ein?
Oliver
Robert Grimm
> Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
> mindestens fuenfmal so vielen Rechnern wie das authentifizierende System.
> Das spricht nicht gerade fuer eine hohe Akzeptanz seitens der Kunden, denn
> sonst waeren die Spamschleudern wohl laengst abgeschaltet oder zumindest
> die Anzahl der Rechner haetten ein anderes Verhaeltnis.
Es gibt bestimmt auch eine hohe anzahl von Kunden, die wie ich
smtprelay.t-online.de nutzen, da es bestimmt auch etliche "enthält:
kundenserver.de" filterer gibt. Die smtp server von Puretec nutze ich gar
nicht.
> Anders
Gruß,
Robert
Thomas Hochstein
>> Hmmm. Ich wusste nicht, dass die www.puretec.de ein offenes Relay
>> ist oder zum Spam-Verschicken benutzt wird ...
>
> form mails?
Nein, das geht alles über dedizierte Mailout-Server raus.
Sebastian Niehaus
> Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
> mindestens fuenfmal so vielen Rechnern wie das authentifizierende
> System.
Eben. Während der aufwendige SMTP-AUTH-Server nur /Kunden/ vorbehalten
ist, gilt für die anderen der "sponsored mode", der auch Nicht-Kunden"
offen steht, sofern sie bei Puretec gehostete Domains bekannter
machen.
Klar, daß der eine hohe Last zieht....
Sebastian
Sebastian Niehaus
> Anders Henke <anders...@sysiphus.de> wrote:
>
> > smtp.puretec.de war wichtig, als man noch beim Versand ueber
> > mail.btx.dtag.de noch ein Zwangs-From aus der Userkennung bekam
> > und nur mit dem externen Relay seine Domain auch als Mailadresse
> > wirklich immer fuehren konnte. Seit dem smtprelay.t-online.de ist
> > das aber auch nicht mehr noetig.
>
> Einspruch. Da smtprelay.t-online.de den X-Sender reinschreibt ist
> der Server IMO nutzlos,
Ich schlage vor, daß genau einer für das, was in der Mail so steht
verantwortlich ist.
Nämlich *Du*.
Es zwingt Dich keiner, T-Online zu nutzen. Wenn Dir der Service nicht
passt, solltest Du über einen Wechsel nachdenken.
Andreas dafür anzumaulen, daß T-Online Deine Header vergurkt, ist ja
wohl etwas neben der Spur.
Bei Schlund tut sich offensichtlich etwas bezüglich deren offener
Server. "Gelöst" ist das Problem erst, wenn deren letztes offenes
Relay abgeschaltet ist. Insofern: Hoffen, daß sie offenen Server auf
allen denkbaren Listen landen, hoffen, daß sie bei vielen Providern
gesperrt werden.
Wenn dann irgendjemand mit unzulänglicher Software daherkommt und
keinen vernünftigen Provider hat, hat er eben Pech.
Sebastian
Anders Henke
>>Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
>>mindestens fuenfmal so vielen Rechnern wie das authentifizierende
>>System.
> Wie kommst Du auf dieses d?nne Sprungtuch von der Anzahl der
> Ip-# auf die Anzahl der Server schliessen zu wollen?
>
> Weder muessen
>
> mrvdom.kundenserver.de A 195.20.224.220
> mrvdom.kundenserver.de A 212.227.126.161
> mrvdom.kundenserver.de A 212.227.126.155
> mrvdom.kundenserver.de A 195.20.224.204
> mrvdom.kundenserver.de A 195.20.224.219
> verschiedene Rechner sein, noch muss
> auth.smtp.kundenserver.de A 212.227.126.160
> ein einziger Rechner sein.
Connecte auf Port 25: im Greeting-Banner melden sich die Rechner alle
jeweils eindeutig mit Namen wie 'mrvdom03.kundenserver.de'. Und bei
darueber verschickten Mails sieht man auch im Path nur diese fuenf
(bzw. bei Auth einen) verschiedenen Rechner.
Und wenn fuer's Spam-System DNS-Roundrobin reicht und man keinen
Loadbalancer braucht, wird man fuer Auth auch keinen bereitstellen ...
Anders
--
http://sysiphus.de/
Anders Henke
> Anscheinnend bekommt Schlund die Formmail-Relays nicht in den Griff.
Ganz ehrlich: was kann man als Provider denn gegen ein vor fuenf Jahren
verbrochenes Scheunentor von CGI tun, das nach Aussage des Autoren schon
1998 millionenfach downgeloadet wurde und auch im 10ten Bugfix nie
wirklich sicher wurde? Code-Auditing fuer 10-Euro-Webspaces?
Immerhin gibt es mit http://nms-cgi.sf.net/ eine Reihe sicherer
1:1-Austauschskripte als Alternativen zu den Matt-Wright-Sicherheitsloechern.
Sauber geschrieben und dokumentiert, meckern nicht bei 'perl -w' und
sind von den Perlmongers London explizit auf Sicherheit getrimmt worden.
Schade nur, dass sie kaum einer kennt und stattdessen alle weiterhin
die jahrealten Muellskripte vom Matts Skript Archiv rauskramen.
Anders
--
http://sysiphus.de/
Anders Henke
>> Nimm doch einfach den Relayserver deines Einwahlproviders.
> Und was machen die 1&1-Kunden (wie ich), die 1&1 als Einwahlprovider
> _und_ Webspaceprovider nutzen?
Eindeutig SMTP-Auth.
1&1 ist kein richtiger Einwahlprovider, sondern DTAG-Reseller.
Bei der Einwahl bekommst du von der DTAG irgendwelche IPs aus den riesigen
Einwahlpools der DTAG zugewiesen, die Radius-Server bei 1&1 werden nur
zu 'passen User/Pass zusammen' gefragt und 1&1 hat dann keine Chance,
spaeter diese IPs irgendwie als "dahinter ist ein eigener Kunde" zu
identifizieren.
> Aus eben dem genannten Grund.
Noe.
> (Und ich werde nicht zu einem teureren
> Provider wechseln. Oder wer bietet mir sonst schon einen g?nstigeren
> Tarif f?r ca. 50 - 80 Stunden mtl. DSL-Nutzung an?)
1&1 muss halt seinen Einwahlkunden klar auf den Tisch legen,
dass sie von der DTAG keine realtime-Daten bekommen und dies eben
Nachteile hat, die man nur durch smtp-auth fixen kann.
Als DSL-User bekommst du doch z.B. auch erst 'ne Woche spaeter
eine Trafficauswertung, waehrend z.B. die Logauswertungen vom Webspace
taeglich stattfinden. Warum? Webspace macht 1&1 selbst, Traffic- oder
Einwahldaten bekommen sie erst Tage spaeter von der DTAG.
Anders
--
http://sysiphus.de/
Rainer Zocholl
>Rainer Zocholl <Usenet...@zocki.toppoint.de> wrote:
>>>Also das fuer die Spamschleuder verwendete Mailsystem besteht aus
>>>mindestens fuenfmal so vielen Rechnern wie das authentifizierende
>>>System.
>> Wie kommst Du auf dieses d?nne Sprungtuch von der Anzahl der
>> Ip-# auf die Anzahl der Server schliessen zu wollen?
>>
>> Weder muessen
>>
>> mrvdom.kundenserver.de A 195.20.224.220
>> mrvdom.kundenserver.de A 212.227.126.161
>> mrvdom.kundenserver.de A 212.227.126.155
>> mrvdom.kundenserver.de A 195.20.224.204
>> mrvdom.kundenserver.de A 195.20.224.219
>> verschiedene Rechner sein, noch muss
>> auth.smtp.kundenserver.de A 212.227.126.160
>> ein einziger Rechner sein.
>Connecte auf Port 25: im Greeting-Banner melden sich die Rechner alle
>jeweils eindeutig mit Namen wie 'mrvdom03.kundenserver.de'.
Und? Was soll das belegen?
Virtual hosting geht ja wohl auch bei port 25?
Der an das Interface gebundene Proccess könnte ja durchaus bei
seinem Start einen reverslookup machen und dass ins Greeting einbauen.
Ist keine schlechte Idee: Erspart Konfigurations arbeit
und lässt den einen 486er als 6 MTA erscheinen, Aussenstehende
sind beeindruckt ob der vielen Server ;-)
>Und bei darueber verschickten Mails sieht man auch im
>Path nur diese fuenf (bzw. bei Auth einen) verschiedenen Rechner.
Und? Verstehe nicht warum das belegen soll, das das
verschiedene Rechner(*) sein muessten.
>Und wenn fuer's Spam-System DNS-Roundrobin reicht und man keinen
>Loadbalancer braucht, wird man fuer Auth auch keinen bereitstellen ...
(*) Evtl. muessen wir mal definieren was "verschiedene Rechner"
sind, ehe wir lustig aneinander vorbeireden? ;-)
Rainer Zocholl
>Rainer Zocholl <Usenet...@zocki.toppoint.de> wrote:
>> Anscheinnend bekommt Schlund die Formmail-Relays nicht in den Griff.
>Ganz ehrlich: was kann man als Provider denn gegen ein vor fuenf
>Jahren verbrochenes Scheunentor von CGI tun, das nach Aussage des
>Autoren schon 1998 millionenfach downgeloadet wurde
Wie war das "einst" mit sendmail?
Jedenfalls: Die Hände in den Schoss legen ist nicht Ok.
>und auch im 10ten Bugfix nie wirklich sicher wurde?
>Code-Auditing fuer 10-Euro-Webspaces?
Man kann ganz offensichltich nicht seriös für 10 Euro
Webspaces anbieten, also muss es eingestellt werden
oder ein ANGEMESSENER Preis genommen werden.
Wo siehst Du das Problem?
Wer CGI benutzen will, muss entwender eine entsprechende
Ausbildung nachweisen, oder sich das KnowHow mitkaufen.
Es kann auf jeden Fall nicht angehen, das man zu Dumping-preisen
anbietet und die anderen Systeme leiden lässt, dort einen
Gigabyte grossen Traffic erzeugt.
(Schlund hat bestimmt nicht aus "menschenfreude" die RBLs eingeführt,
sondern wohl eher, weil ihn der Tera-Traffic für Spam und Bounces
inzwischen zu teuer kam. Vgl. die Diskussion mit germany.net die
um Traffic zu sparen, ganze Netze sperren.).
Und wenn ein Provider schon so schlau ist, einen
Bounce-Account vorzuschreiben, warum kann er da nicht
ein Script drauf setzen, das Alarm schlägt, sobald innerhalb
von 5minuten der 100ste "550"-Error von einem einzigen Server
gekommen ist?
Das klingt nicht besonders aufwändig, 2. Lehrjahr, maximal.
Aber stimmt, wie immer das Problem bei Spamfreindly Billig-hostern:
IP kostet nix oder nicht das eigene Geld, Man-power kostet
reichlich. Damit kann also man nicht genug Geld aus den Commons ziehen.
Also lässt der Billig-Provider seine Server weiter offen für DDOS-Attacken.
Statt nachzusehen, warum da zu hunderten "User unknown" kommen,
werden die Output server gewechselt,
damit das bespamte System garantiert KO geht?
Den 32KB langen "netstat" mit hunderten von "established"
Verbindungen von den diversen m*.kundenserver.de schicke ich
Dir auf Wunsch gerne per eMail zu, falls du mir so nicht glaubst
das es da ein Problem gibt.
kundenserver.de/Schlund ist der einzige Webhoster, der hier
in dieser Weise immer wieder negativ auffällt.
>Immerhin gibt es mit http://nms-cgi.sf.net/ eine Reihe sicherer
>1:1-Austauschskripte als Alternativen zu den
>Matt-Wright-Sicherheitsloechern. Sauber geschrieben und dokumentiert,
>meckern nicht bei 'perl -w' und sind von den Perlmongers London
>explizit auf Sicherheit getrimmt worden.
>Schade nur, dass sie kaum einer kennt und stattdessen alle weiterhin
>die jahrealten Muellskripte vom Matts Skript Archiv rauskramen.
Ja.
Aber ein Billig-Provider wie Schlund kann ja wohl seinen
Kunden vorgeben, welche CGIs sie verwenden sollen?
Wenn die AGBs das nicht hergeben, stehen die Schlund server
vollkommen zu recht in den RBLs. In noch viel zu wenigen!
Oder welche Möglichkeiten siehst Du, dem Server zu sagen:
"Hört mit den scheiss verbindungen aufbauen auf", wenn dieser
sich dann einfach dem MX zuwendet und diese plätten?
Ich sehe keine, ausser der, das der Server nach der 3..4 offenen
Verbindung aufhört weitere aufzubauen, bis die erste beendet
wurde.
Vielleicht könnte man einen speziellen Fehler-text vereinbaren
555 talk2 to webmaster: your cgi is currently abused, stop it.
555 talk2 to postmaster: too many open connections, pls. wait
Das aus dem Logfile zu angeln müsste sogar ein Lehrling
im 1. Jahr programmieren können.
Mei, Schlund muss wohl wirklich das IP geschenkt bekommen.
Oder wie finanziert er den ganze Spam-Traffic?
Anders Henke
>>Interessant evtl. auch die Warnungen, die puretec inzwischen in
>>eingehende mails (gestern zum ersten Mal gesehen) einfuegt:
>>|X-RBL-Warning: (relays.bl.kundenserver.de) mail received via
>>unsecured |relay host, see http://relaytest.kundenserver.de/point.php?
>>ip=195.27.186.15
>
>
> Und eine eigene Blacklist dem Netz zur Verf?gung stellen?
> W?re ja ganz was neues, das Schlund den Commons etwas zur?ckgibt?
>
>
> http://relaytest.kundenserver.de/faq.php
> I'd like to use your list for my own server.
> This list is not for public usage.
>
Du hast den Rest vergessen zu quoten:
---cut
I'd like to use your list for my own server.
This list is not for public usage.
If you want to use a RBL for your mail system, please take a look
at these sites:
http://orbz.org/
http://www.ordb.org/
http://relays.visi.com/
We're also sending out daily bulk-submits to ordb as well as other
RBLs, so the public RBLs get to know of our findings and there's no need
for you to add our RBLs.
---cut
Die im X-RBL-Warning genannte relays.bl.kundenserver.de ist auf jeden
Fall oeffentlich querybar; die auf spamblock.kundenserver.de genannte
mrelay.bl aber wohl nicht (kein NS-Eintrag), von daher wird sich
irgendjemand wohl was dabei gedacht haben, die Leute wissen, wie man
Services gezielt freigibt.
Nach der FAQ wird auch mindestens die ORDB mit offenen Relays gefuettert,
dadurch sind die gefundenen Relays auch fuer die Commons verfuegbar
(hoere ich da gerade ein paar Argumente zu Staub zerfallen?).
Wenn du dir ORDB und ORBZ anschaust, haben die dort aber auch reichlich
Probleme mit Rechtsstreits und viel Support. Wenn du dir eine RBL ausdenkst,
bindest du dir damit gleich einen Klotz von Problemen ans Bein
(DoS von Spammern, Dauerkandidat vor Gericht, ...). Selbst ORBZ sagt doch
"wir wollen nicht, dass ihr sie benutzt. Die Listen sind einfach da.
Ihr koennt sie benutzen, aber das ist eure Entscheidung".
Aus meiner Sicht spricht nichts dagegen, diesen oeffentlich abfragbaren
Service relays.bl.kundenserver.de zumindest loggend auch zu verwenden.
Voll vertrauen wuerde ich darauf aber nicht, schliesslich koennen die
bei Schlund ja einfach der Reihe nach ihre Konkurrenten als offene Relays
eintragen, damit in den Dreck ziehen und sich dann mit "war zum Testzeitpunkt
ein offenes Relay" rausreden. Und die eigenen Rechner werden sowieso nicht
eingetragen sein (auch schwer moeglich: jedes noch so gesicherte Host wird
fuer Rechner aus dem eigenen Netz liebend gerne relayen).
Relays.bl.kundenserver.de ist oeffentlich querybar und
die Ergebnisse werden lt. Schlund auch an ORBD submittet.
Indem du ORDB verwendest, kommst du damit auch an die Ergebnisse,
die auf der relays.bl.kundenserver.de gefunden und auch von ORDB
noch einmal verifiziert wurden. Letzten Endes foerdert Schlund
damit doch die ORDB, indem ORDB bereits bei Schlund bekannte offene
Relays kriegt.
Ich finde die Idee der relaytest.kundenserver.de einfach gut: es wird einfach
gnadenlos jeder Rechner getestet, der bei Schlund Mails einliefern will.
Und weil da eben ganz Puretec drueber geht, sind das eben auch entsprechend
viele Rechner, die da getestet werden, sobald sie auch nur einmal probieren,
eine Mail zu verschicken.
Dadurch bekommt man natuerlich offene Relays viel schneller raus als wenn
eine Kiste erst zwei Wochen am Netz haengt, dann von einem Spammer gefunden
und missbraucht wird, jemand den Spamheader bei Spamcop submittet, die das
dann an ORBZ weiterreichen und dann schliesslich raus ist, dass der Kram
wirklich ueber ein offenes Relay kam.
Und wenn du als Admin dein offenes Relay geschlossen hast, kannst du es
selbst per http://relaytest.kundenserver.de/view.php sofort wieder
retesten lassen.
Das ganze ist einfach vom Prinzip her deutlich mehr realtime als andere
Realtime Blackhole Lists. Und weil ORDB mit den Ergebnissen gefuettert wird,
ist es auch fuer die Commons gut - ich kann dich da nicht so richtig
verstehen. Uebersehe ich da irgendwas?
Anders
--
http://sysiphus.de/
Michael Schierl
>On 14 Mar 2002 06:32:58 GMT, Anders Henke <anders...@sysiphus.de> wrote:
>
>>Dummerweise gibt es da auch ein paar tausend Reseller, die ihren Endkunden
>>smtp-auth beibringen muessen und viele Leute, die smtp-auth einfach
>>nicht in ihren Mailclient einkonfiguriert bekommen oder es einfach nicht
>>machen ("tut ja auch so"). Und solange das nicht halbwegs geklaert ist,
>>kann man eben auch nicht einfach das halboffene Relay abschalten.
>
>Das Dumme ist, dass es mit "Beibringen" nicht getan ist, weil Netscape Messenger
>das Passwort zur Anmeldung am SMTP-Auth-Server nicht speichert, so dass es immer
>wieder erneut eingeben werden muss.
Es gibt doch heute auf jeder Shareware-Seite
"Dialogbeantwortungstools" zum Runterladen. Die meisten davon können
auch Textboxen ausfüllen. Dann übernimmt das Eingeben des Passworts
derjenige, der das eh am besten kann: der Computer.
Oder man nimmt gleich den Hamster.
Und außerdem bietet (fast) jeder Provider auch einen Mailserver an,
der keine Authentifizierung (außer über IPs) erfordert.
Und spätestens wenn Mozilla final ist (und stabil läuft), hat der
Netscape bei mir eh ausgedient.
Michael
--
http://smsoft.ixy.de/ SMsoft Freeware Download Page:
Smart Dialog Anrufbeantworter für Dialogfelder
ContentsSaver Fensterinhalte abkopieren
Smart Macro Makrorekorder
Andreas Ferber
>>Die Server von schlund sind wohl zu dem so asozial eingestellt, dass
>>sie solange zu fremden Servern weitere Connects aufmachen
>>(ohne auf den ersten connects mehr als den SMTP-Header losgeworden
>>zusein), bis diese Server platt sind. Das stört die Schlund-Server
>>aber garnicht, denn dann machen sie ebend die MXe auch noch platt...
> Diesen Vorwurf möchtest Du belegen. IIRC kann man einen exim gar nicht
> so konfigurieren.
Du musst AFAIK nur entsprechend viele parallel laufende Queue-Runner
zulassen, Option queue_run_max. Verglichen auch
http://www.exim.org/FAQ.html#SEC23
Wenn sie bei Schlund häufige Queue-Runs mit vielen parallelen Prozessen
konfiguriert haben, kann ich mir durchaus vorstellen, daß es zu dem von
Rainer beschriebenen Effekt kommt (siehe Punkt 1 in der FAQ-Antwort
oben).
Ausserdem könnten sie natürlich den Exim auch entsprechend gepatcht
haben, wobei das natürlich wieder Aufwand bedeutet, was die Sache
unwahrscheinlich macht :->.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Rainer Zocholl
>Du hast den Rest vergessen zu quoten:
>
>---cut
>I'd like to use your list for my own server.
> This list is not for public usage.
>
> If you want to use a RBL for your mail system, please take a look
> at these sites:
> http://orbz.org/
> http://www.ordb.org/
> http://relays.visi.com/
Ab ---hier habe ich dann nicht mehr weiter gelesen. Was
sollte auch noch kommen?
> We're also sending out daily bulk-submits to ordb as well as other
> RBLs, so the public RBLs get to know of our findings and there's no need
> for you to add our RBLs.
Ach, das ist natürlich ne Gute Sache(tm). (Hab's wirklich nicht gelesen.
sorry. (Vielleicht den Absatz vielleicht vor die RBL liste?)
>Ich finde die Idee der relaytest.kundenserver.de einfach gut: es wird
>einfach gnadenlos jeder Rechner getestet, der bei Schlund Mails
>einliefern will.
Ja, ich war auch schon drauf und dran so was zu bauen, als die Probleme
mit den offenen Proxies begannen. Diese waren in den
den meisten listen nicht vertreten, und bl.spmcop.net will
man nicht wirklich zum blocken nutzen.
Welche Software wird da verwendet?
Gibt's da was freies?
>Und weil da eben ganz Puretec drueber geht, sind das
>eben auch entsprechend viele Rechner, die da getestet werden, sobald
>sie auch nur einmal probieren, eine Mail zu verschicken.
>Dadurch bekommt man natuerlich offene Relays viel schneller raus als
>wenn eine Kiste erst zwei Wochen am Netz haengt, dann von einem
>Spammer gefunden und missbraucht wird, jemand den Spamheader bei
>Spamcop submittet, die das dann an ORBZ weiterreichen und dann
>schliesslich raus ist, dass der Kram wirklich ueber ein offenes Relay
>kam.
Ausser es ist ein Multilevel relay...
Da must Du ja erstmal man den Einlieferungspunkt finden
oder den Muell annehmen, hoffen das der Server loggt und
analysieren.
Das Problem ist natürlich:
Wenn jeder Rechner einen Relaytest macht hast Du mehr Traffic.
Wenn ich an einen gross provider denke, der wird schon sauer
werden, wenn jeder sch* host an den er eine eMail liefern will erstmal
einen kompletten Relaytest fährt... (Wobei rechtlich einwandfrei, oder?)
Wie oft willst Du testen?
bei jeder email?
Wenn nicht bei jeder email musst Du eine Datenbank fahren.
Wie oft wiederholen?
Jede Woche?
Willst Du nur Rechner checken die Einliefern
oder auch an die man selbst ausliefert?
Wann gilt etwas als "relay"?
Doch erst wenn die test-eMail eingtroffen ist.
Was machst Du solange mit dem Server?
ich fürchte, das Verfahren scaliert nicht.
Rainer Zocholl
>* Marc Haber <mh+use...@zugschlus.de> schrieb:
>>>Die Server von schlund sind wohl zu dem so asozial eingestellt, dass
>>>sie solange zu fremden Servern weitere Connects aufmachen
>>>(ohne auf den ersten connects mehr als den SMTP-Header losgeworden
>>>zusein), bis diese Server platt sind. Das stört die Schlund-Server
>>>aber garnicht, denn dann machen sie ebend die MXe auch noch platt...
>> Diesen Vorwurf möchtest Du belegen. IIRC kann man einen exim gar
>> nicht so konfigurieren.
>Du musst AFAIK nur entsprechend viele parallel laufende Queue-Runner
>zulassen, Option queue_run_max. Verglichen auch
>http://www.exim.org/FAQ.html#SEC23
>Wenn sie bei Schlund häufige Queue-Runs mit vielen parallelen
>Prozessen konfiguriert haben, kann ich mir durchaus vorstellen, daß es
>zu dem von Rainer beschriebenen Effekt kommt (siehe Punkt 1 in der
>FAQ-Antwort oben).
Also: die Connects knallen im sub-sekunden bereich rein.
Ein server nach dem andere.
Jeder connect liefert nur eine einzige eMail ein (so sieht's jedenfalls
aus)
Klar das das Empfangs System "plättet",
denn ein "Connect" ist ja nun nicht gerade eine trivial Operation.
>Ausserdem könnten sie natürlich den Exim auch entsprechend gepatcht
>haben, wobei das natürlich wieder Aufwand bedeutet, was die Sache
>unwahrscheinlich macht :->.
naja, das das "Absicht" ist habe ich nicht gesagt! ;-)
Vielleicht ja "nur" Aroganz/Ignoranz?
Beispiel:
SMTP-HELOS:
MM:SS
09:48 from mout01.kundenserver.de(195.20.224.132)
09:50 from moutng0.kundenserver.de(212.227.126.170)
09:51 from moutng1.kundenserver.de(212.227.126.171)
09:51 from moutng1.kundenserver.de(212.227.126.171)
09:51 from mout02.kundenserver.de(195.20.224.133)
09:52 from mout01.kundenserver.de(195.20.224.132)
09:52 from moutng1.kundenserver.de(212.227.126.171)
09:53 from mout03.kundenserver.de(195.20.224.218)
09:53 from moutng0.kundenserver.de(212.227.126.170)
09:54 from mout04.kundenserver.de(195.20.224.89)
09:54 from mout04.kundenserver.de(195.20.224.89)
09:54 from moutng1.kundenserver.de(212.227.126.171)
09:55 from moutng0.kundenserver.de(212.227.126.170)
09:55 from mout03.kundenserver.de(195.20.224.218)
09:55 from mout02.kundenserver.de(195.20.224.133)
09:56 from mout04.kundenserver.de(195.20.224.89)
09:56 from mout02.kundenserver.de(195.20.224.133)
09:57 from mout03.kundenserver.de(195.20.224.218)
09:58 from mout02.kundenserver.de(195.20.224.133)
09:58 from mout04.kundenserver.de(195.20.224.89)
09:58 from moutng1.kundenserver.de(212.227.126.171)
09:58 from mout03.kundenserver.de(195.20.224.218)
09:59 from moutng0.kundenserver.de(212.227.126.170)
10:00 from mout04.kundenserver.de(195.20.224.89)
10:00 from mout03.kundenserver.de(195.20.224.218)
10:00 from mout01.kundenserver.de(195.20.224.132)
10:00 from moutng1.kundenserver.de(212.227.126.171)
10:02 from moutng1.kundenserver.de(212.227.126.171)
10:02 from moutng1.kundenserver.de(212.227.126.171)
10:03 from mout04.kundenserver.de(195.20.224.89)
10:03 from moutng1.kundenserver.de(212.227.126.171)
10:04 from mout02.kundenserver.de(195.20.224.133)
10:04 from moutng1.kundenserver.de(212.227.126.171)
10:05 from mout02.kundenserver.de(195.20.224.133)
10:05 from mout04.kundenserver.de(195.20.224.89)
10:06 from mout04.kundenserver.de(195.20.224.89)
10:07 from mout01.kundenserver.de(195.20.224.132)
10:07 from mout03.kundenserver.de(195.20.224.218)
10:07 from mout04.kundenserver.de(195.20.224.89)
10:08 from mout02.kundenserver.de(195.20.224.133)
10:08 from mout02.kundenserver.de(195.20.224.133)
10:10 from mout03.kundenserver.de(195.20.224.218)
10:10 from moutng0.kundenserver.de(212.227.126.170)
10:11 from mout02.kundenserver.de(195.20.224.133)
10:11 from mout02.kundenserver.de(195.20.224.133)
10:11 from moutng1.kundenserver.de(212.227.126.171)
10:12 from moutng1.kundenserver.de(212.227.126.171)
10:12 from mout03.kundenserver.de(195.20.224.218)
etc.
Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
-lange- weiter so)
"Nettes" Verhalten nicht wahr?
(Ob da schon die MX einbezogen werden weiss ich nicht, könnte
aber sein).
Immer schön "Round robin", nach uns die Sinnflut...
Was kümmert es, das der erste Server man gerade den HELO
abgeliefert hat?
Warum sollten wir die eMails sammeln und in einem einzigen Connect
abkippen?
Ist doch nicht unser Server, Hauptsache unser spool wird schnell
leer. (Wird er SO natürlich nicht, weil sich die Verbindungen hier
gegenseitig auf den Füssen stehen.)
Irgendwo bei ca. 100 Connects (pro deren Server!) ist dann wohl
auch Schlund am Ende? (Schwer zusagen was da wirklich am Ende ist)
Aber: Reichlich spät...
Jeder dieser Connects erzeugt schliesslich eine 500er Fehlermeldung.
"Eigentlich" müssten nach max. 15 minuten die Alarmglocken
bei Schlund schrillen "Server Missbrauch". Tun sie aber nicht.
Es geht so stundenlang(!) weiter. Am Tage! Während der
normalen Arbeits.
Joachim Deckers
> (Joachim Deckers) 13.03.02 in /de/admin/net-abuse/mail:
> >Hendrik Weimer schrieb:
> >> Zu Unrecht? mrvdom.kundenserver.de ist ein offenes Relay.
>
> >Das nervt, ja. Habe mich deswegen als 1&1-Kunde auch mehrfach
> >ergebnisfrei bei 1&1 und Schlund beschwert.
>
> BTW:
> Bekommst Du eigentlich ne Fehlermeldung von Schlund, oder
> kommt die eMail "einfach nur nicht an"?
Wieso Fehlermeldung? 1&1 hat auf die letzte Beschwerde hin ohne
Anerkennung einer Rechtspflicht eine Monatsgebühr erstattet. (Hatte
wegen des Blockens des Auth-SMTP-Servers allerdings auch real Kosten, da
eine wichtige Absprache so nicht überkam...) Bei Schlund hatte ich mich
telefonisch beschwert - wie ich an die Nummer kam, weiß ich nicht, aber
derjenige am anderen Ende war ziemlich fit...
Gruß
Joachim
Thomas Hochstein
> Warum sollten wir die eMails sammeln und in einem einzigen Connect
> abkippen?
Die Mails werden aller Wahrscheinlichkeit einzeln (von einem Script -
formmail.pl?) eingeliefert. Demnach kann der MTA sie auch nur einzeln
ausliefern.
Andreas Ferber
>
> Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
> -lange- weiter so)
> "Nettes" Verhalten nicht wahr?
Hmm, die Erklärung dürfte recht einfach sein (der wichtige Hinweis ist
das offenbar beteiligte form2mail-Script):
Der Spammer hat offenbar seine Adressenliste nach Domains sortiert,
deswegen kippt er innerhalb kürzester Zeit jede Menge Mails an euch in
das formmail-Script. Dieses startet jeweils einmal /usr/lib/sendmail
(oder whatever), das die Mail nicht erst spoolt sondern direkt eine
Delivery zu den mout*-Servern macht. Dort kommt die SMTP-Connection vom
Webserver rein, exakt eine Mail wird übertragen, und danach forkt exim
und startet direkt ein Delivery-Versuch, diesmal zu euch, bevor die Mail
in der Queue landet. Dadurch kommen die Connects bei euch in der
Geschwindigkeit rein, wie der Spammer die Mails ins formmail-Script
kippt.
Wenn die Mails einmal in der Queue liegen und vom periodischen
Queue-Runner abgearbeitet werden, bemüht exim sich, nach Möglichkeit
SMTP-Connections zu recyclen, nur landen sie bei der Konstellation eben
erstmal nicht in der Queue.
> Irgendwo bei ca. 100 Connects (pro deren Server!) ist dann wohl
> auch Schlund am Ende? (Schwer zusagen was da wirklich am Ende ist)
> Aber: Reichlich spät...
Da schlägt dann irgendwann wahrscheinlich das queue_only_load-Setting
zu, das festlegt, ab welchem Server-Load neue Mails nur noch gequeued
werden, anstatt eine direkte Auslieferung zu versuchen. Für euch zum
Problem wird es deswegen, weil Schlund ein paar mehr Server als ihr
habt, und sich die Load auf deren Seite dann natürlich verteilt.
Die Load vom forken der ganzen Delivery-Prozesse klingt aber relativ
schnell wieder ab, und dann fängt exim wieder an, direkt auszuliefern.
Du kannst ja mal bei Schlund anfragen, ob sie ein "queue_smtp_domains
deine.domain" in ihre exim-Config einbauen ;-)
Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen will
oder nicht, wenn du mehr Connections gleichzeitig annimmst als du
verkraften kannst, dann ist das erstmal /dein/ Problem, nicht ihres.
Mit dem iplimit-Match von iptables z.B. ist es auch kein Problem, da
wirksam Abhilfe zu schaffen.
> Jeder dieser Connects erzeugt schliesslich eine 500er Fehlermeldung.
> "Eigentlich" müssten nach max. 15 minuten die Alarmglocken
> bei Schlund schrillen "Server Missbrauch". Tun sie aber nicht.
Naja, wahrscheinlich haben sie permanent eine recht hohe Load auf ihren
Servern, daher fällt das auf ihrer Seite nicht unbedingt auf. Und wenn
sich Schlund alle SMTP-Fehler ansehen wollte, die sie bekommen, dann
hätten sie sicher /viel/ zu tun ;-)
> Es geht so stundenlang(!) weiter. Am Tage! Während der
> normalen Arbeits.
IOW, solange der gerade aktive Spammer Mails an euch abkippt.
Marc Haber
>Usenet...@zocki.toppoint.de (Rainer Zocholl) scripsit/wrote:
>> Warum sollten wir die eMails sammeln und in einem einzigen Connect
>> abkippen?
>
>Die Mails werden aller Wahrscheinlichkeit einzeln (von einem Script -
>formmail.pl?) eingeliefert. Demnach kann der MTA sie auch nur einzeln
>ausliefern.
Theoretisch könnte man den exim auf dem sendenden System auf "queue
only" stellen und oft genug queue runners starten.
Marc Haber
>Also: die Connects knallen im sub-sekunden bereich rein.
>Ein server nach dem andere.
>Jeder connect liefert nur eine einzige eMail ein (so sieht's jedenfalls
>aus)
>Klar das das Empfangs System "plättet",
>denn ein "Connect" ist ja nun nicht gerade eine trivial Operation.
Es ist natürlich Dein Vorrecht, so viele Connects in so kurzer Zeit
nicht anzunehmen. Wer seine Software konfigurieren kann, hat dieses
Problem mit grossen Sites nicht.
Marc Haber
>(Anders Henke) 15.03.02 in /de/admin/net-abuse/mail:
>> RBLs, so the public RBLs get to know of our findings and there's no need
>> for you to add our RBLs.
>
>Ach, das ist natürlich ne Gute Sache(tm). (Hab's wirklich nicht gelesen.
>sorry. (Vielleicht den Absatz vielleicht vor die RBL liste?)
Hey. Du gibst einen Fehler zu, das habe ich noch nie gesehen.
Normalerweise hätte ich jetzt erwartet, dass Du unterstellst, man
hätte diesen Absatz schnell als Reaktion auf Deine Beschwerde
dazugeschrieben.
Anders Henke
>> We're also sending out daily bulk-submits to ordb as well as other
>> RBLs, so the public RBLs get to know of our findings and there's no need
>> for you to add our RBLs.
> Ach, das ist nat?rlich ne Gute Sache(tm). (Hab's wirklich nicht gelesen.
> sorry. (Vielleicht den Absatz vielleicht vor die RBL liste?)
Hmmm. Du willst keine drei Zeilen weiterscrollen?
Schicke Verbesserungsvorschlaege doch an postm...@relaytest.kundenserver.de
(postmaster muss ja existieren).
>>Ich finde die Idee der relaytest.kundenserver.de einfach gut: es wird
>>einfach gnadenlos jeder Rechner getestet, der bei Schlund Mails
>>einliefern will.
>
> Ja, ich war auch schon drauf und dran so was zu bauen, als die Probleme
> mit den offenen Proxies begannen. Diese waren in den
> den meisten listen nicht vertreten, und bl.spmcop.net will
> man nicht wirklich zum blocken nutzen.
>
> Welche Software wird da verwendet?
> Gibt's da was freies?
Ich kenne nichts, was in der Richtung arbeitet. Die meisten
Antispam-Fallen wollen einfach fleissig die Webfrontends und
Trap-Adressen von orbz mit allen IPs zumuellen, die irgendein
Procmail-Skript in als "Spam" deklarierten Mails definiert
oder in irgendwelchen Logfiles aufgetrieben werden.
Aktive Antispam-Tools sind mir nicht bekannt, insofern duerfte
es irgendeine Eigenentwicklung sein.
>>Und weil da eben ganz Puretec drueber geht, sind das
>>eben auch entsprechend viele Rechner, die da getestet werden, sobald
>>sie auch nur einmal probieren, eine Mail zu verschicken.
>>
>>Dadurch bekommt man natuerlich offene Relays viel schneller raus als
>>wenn eine Kiste erst zwei Wochen am Netz haengt, dann von einem
>>Spammer gefunden und missbraucht wird, jemand den Spamheader bei
>>Spamcop submittet, die das dann an ORBZ weiterreichen und dann
>>schliesslich raus ist, dass der Kram wirklich ueber ein offenes Relay
>>kam.
>
> Ausser es ist ein Multilevel relay...
Wirklich offene Multilevel-Relays sind praktisch nur sehr schwer
von Smarthosts zu unterscheiden.
Selbst, wenn du als ISP mit x Mio Kunden ueber authentifizierte Verbindungen
Mails annimmst und ein einzelner Kunde dann ein offenes Relay baut,
das aber alle Mails authentifiziert weiterschickt, gibt es einfach
mit heutigen Mitteln keine reale Chance, dieses vorher zu entdecken.
Wenn du das aber nicht tust, kann dir ein einziger Kunde dein gesamtes
Mailsystem in wenigen Sekunden bei einer Reihe von RBLs listen:
"Punishing the ISP for setting up a correctly configured smarthost
which has been used by a single not-so-well-informed customer is a
bad idea, as this would also block all of its customers because of
a single customers misconfiguration.
It may even become a method for 'striking down' an ISP: just dial
into their network, open up a relay and make common RBLs list
their smarthost.
After this, it takes weeks to get the smarthost unlisted at the
various RBLs."
(aus der FAQ von relaytest.kundenserver.de)
Auch ORDB listet daher nur inputs und keine outputs.
Der Schaden, den man mit output-Listings anrichten kann, ist enorm;
solange die meisten offenen Relays sind ja auch input=output sind,
ist es kein Problem, nur inputs zu listen.
> Da must Du ja erstmal man den Einlieferungspunkt finden
> oder den Muell annehmen, hoffen das der Server loggt und
> analysieren.
Und was machst du bei gefakten Headern? Ich habe letzt erst Korea-Spam
bekommen, der angeblich von einem .nl-Dialup zu yahoo, von dort per
asmtp zu hotmail, von dort aus dann ohne Received-Zeile zu GMX, die
das dann angeblich nach Korea geschickt haben. Und die haben dann
schliesslich auf meinem regulaeren MX ausgeliefert.
Ich sehe aber auch keinen Grund, warum die fuer relaytest.kundenserver.de
sowie fuer spamblock.kundenserver.de eingesetzte Software nicht auch auf die
eigenen Smarthosts angesetzt werden sollte und darueber Kunden-IPs
temporaer sperrt, wenn
-es sich bei ihnen um offene Relays handelt oder
-der Sender mehr als x Mails pro Minute verschickt hat
Das heisst, einen Grund gibt es: Personal Firewalls, die bei jedem
unkritischen Krams die Alarmsirene laeuten und darueber dann zu
Beschwerden fuehren.
Ganz ehrlich: wenn du als Kunde bei Puretec ueber auth.smtp.puretec.de eine
Mail verschickst und dich dann so ein "kundenserver.de"-Rechner
"per SMTP angreift", kommst du da sofort auf die Idee, dass es sich
dabei um eine redliche Sache handelt?
Im naechsten Moment googlest du mal etwas herum, siehst, dass
"kundenserver.de" ein boeser Spammerladen ist und du schleppst natuerlich
sofort deine duerftigen Firewalllogs zur Beschwerde weg.
Aber cool waere es schon, wenn man auch die einliefernden Kunden testen
wuerde.
> Das Problem ist nat?rlich:
> Wenn jeder Rechner einen Relaytest macht hast Du mehr Traffic.
> Wenn ich an einen gross provider denke, der wird schon sauer
> werden, wenn jeder sch* host an den er eine eMail liefern will erstmal
> einen kompletten Relaytest f?hrt... (Wobei rechtlich einwandfrei, oder?)
Wenn die Ergebnisse geshared und lange in einer Datenbank gecached
werden, ist dagegen eigentlich nichts zu sagen.
Was sagst du aber gegen Spammer, die einfach versuchen, auf jedem
Host in deinem Netz ihren Spam zum Relaying einzuliefern? Fahre eine
noch nie verwendete IP hoch und warte einfach mal einen Tag - danach hast
du doch dutzendweise Relayversuche von irgendwelchen Dialup-IPs.
Das duerfte ein viel groesseres Problem sein.
> Wie oft willst Du testen?
Synchron zur Maileinlieferung: unmoeglich.
Also asynchron ueber ein Queue-System.
> bei jeder email?
Noe, wie bei dem relaytest auch: sobald mir ein Rechner eine Mail
schicken moechte, von dem ich noch nie zuvor etwas gehoert habe.
Da man asynchron testen muss, kann die Information gleich mit in
das Queue-System.
> Wenn nicht bei jeder email musst Du eine Datenbank fahren.
apt-get install mysql-server.
Fuer diese Aussage brauchst du doch nur eine Tabelle mit ip, letztem Status
und einem lastcheck-Datum. Wenn man sich anstrengt und fleissig lockt,
bekommt man die Informationen auch in einem DBM-File verwaltet.
Wo ist das Problem?
SQL wurde urspruenglich fuer kaufmaennische Angestellte entwickelt und
die Grundlagen "select, insert, update, delete" sind doch in zehn
Minuten schnell gelernt. Eine Datenbank ist da nicht das Problem.
> Wie oft wiederholen?
> Jede Woche?
Geclosete Sachen so selten wie moeglich (alle ein-zwei Monate), offene
Relays ruhig oefter (um aktuell zu bleiben).
Bei dem Prinzip "jeden einliefernden Rechner testen" kann man sich
allerdings ein richtig einfaches Design leisten: offene Relays werden
jede Woche noch einmal verifiziert, die IPs von gesicherten Systemen wirft
man nach ein paar Wochen weg. Sobald ein gesicherter Rechner wieder
auftaucht, wird er auch gleich wieder getestet und hat dann wieder
die naechsten Wochen Ruhe.
Auf diese Weise enthaelt die Datenbank dann nur noch relevante Hosts.
Wenn dir jemand ein Jahr lang keine Mail schickt, musst du dir auch
nicht merken, dass er kein offenes Relay ist. Offene Relays willst
du dir aber solange merken, solange sie offen sind - weil sie ja irgendwann
missbraucht werden koennen.
Und wer ein offenes Relay hat, sollte sich ueber Test-Traffic nur
schwer beschweren koennen ...
> Willst Du nur Rechner checken die Einliefern
> oder auch an die man selbst ausliefert?
Ersteres ist kein Problem, letzteres kann ein Problem werden.
Wenn ein Kunde eine SMTP-Queue bei dir hat, wird er auch von deinen
Rechnern Mail annehmen. Ob er sie durch dumm-Konfig dann auch relayed,
ist dann eine andere Sache (es handelt sich dann um ein gegenueber dir
offenes Relay, aber nicht fuer die Allgemeinheit).
Ebenso wird jede Kiste, ueber die du selbst auslieferst gelistet.
(wenn du bei Puretec einen Mailforward konfigurierst, geht die Mail ja
auch lt. Header auf einem MX-Host rein, wird an einen MOUT-Host verschickt
und dann von dem erst ausgeliefert. In der Folge muesste der Schlundsche
Tester auch die eigenen MOUTs und MXe testen, die aber jede Mail aus ihrem
eigenen Netz annehmen und durchschleusen werden).
Daher muss man eigentlich auch die eigenen IP-Allocations von Tests
ausnehmen. Und wenn das ganze kompliziert wird, weil du dabei auch
noch wechselnde Kunden-IPs hast, kann man es eh' vergessen.
> Wann gilt etwas als "relay"?
> Doch erst wenn die test-eMail eingtroffen ist.
Solange es Groupwise, Lotus Notes und halb-dumm konfigurierte Exchanges gibt:
auf jeden Fall. Die nehmen Mail erst einmal an, wuerfeln sie durch einen
lokalen Filter und schmeissen sie dann weg. Geruechteweise kann man
Notes auch so konfigurieren, dass es die Mails gar nicht erst annimmt,
gesehen habe ich aber noch keine Doku dazu.
Les noch einmal die FAQ zur relaytest.kundenserver.de.
Rufe eine der hier im Thread genannten X-RBL-Warning-URLs auf.
Da wird recht klar gesagt, dass genau auf das Eintreffen der Testmail
gecheckt wird und man kann die Testmail auch inklusive Header anschauen.
Auf der http://relaytest.kundenserver.de/stats.php gibt es ja auch eine
Uebersicht ueber die Datenbank und ueber die Testergebnisse.
Schlund spielt da mit erstaunlich offenen Karten, hilft mit einem
"stillen" Relaytester den Commons und macht die Testergebnisse komplett
oeffentlich abruf- und verifizierbar. Wenn du ein offenes Relay sofort
retesten lassen moechtest, geht das ueber die View-Seite und fuenf
Minuten spaeter ist das Testergebnis fertig.
Das sollte man foerdern und nicht darauf herumhacken.
> Was machst Du solange mit dem Server?
Letzten Status beibehalten.
Wenn der Test schnell genug ablaeuft und nur wenige Minuten dauert, kann
man auch damit leben, den Server waehrend des Tests nicht zu listen.
Das macht das Datenbankdesign enorm einfach :-)
> ich f?rchte, das Verfahren scaliert nicht.
Warum nicht?
Die Datenbank enthaelt alle fuer dich relevanten Hosts und nicht mehr.
Wenn du die bei dir als "relayed" gefundenen Hosts an ordb submittest und
deine "recently fixed"-Liste ebenso veroeffentlichst, haben auch andere
was davon und man kann damit dann dafuer sorgen, dass
-die existierenden RBLs effektiver werden
-quasi "distributed" nach offenen Relays gescannt wird und
"Relaytest-Blocker" enttarnt werden.
Mit den Relaytest-Blockern ist das auch so eine Sache - interessant wird
es, wenn du eine IP hast, die bei ORBZ als "clean" bezeichnet wird, aber
bei relaytest.kundenserver.de nicht. Gestern bekam so etwas bei mir an:
http://relaytest.kundenserver.de/point.php?ip=62.116.137.130
http://ordb.org/lookup/?host=62.116.137.130
(auch bei ORBZ, Osirusoft und den anderen ueber ordb abfragbaren
Listen steht der Rechner als "clean" drin!)
Ganz ehrlich - wenn Schlund seine Testnachricht nach zwei Sekunden
zurueckbekommt (steht im Header!), ordb selbst nach fast einer Woche
noch keinen Relay-Beweis hat und ich auch von meinem Shellaccount
bei einem manuellen Test in wenigen Sekunden meine Mail bekomme,
ist da etwas faul:
---cut
mupfel:anders {101} telnet 62.116.137.130 25
Trying 62.116.137.130...
Connected to 62.116.137.130.
Escape character is '^]'.
220 neunes.internetx.de ESMTP Sendmail 8.10.2/8.10.2/SuSE Linux
8.10.0-0.3; Sat, 16 Mar 2002 11:12:30 +0100
helo blah
250 neunes.internetx.de Hello [194.121.21.248], pleased to meet you
mail from: and...@sysiphus.de
250 2.1.0 and...@sysiphus.de... Sender ok
rcpt to: and...@infra.de
250 2.1.5 and...@infra.de... Recipient ok
data
354 Enter mail, end with "." on a line by itself
blah
.
250 2.0.0 g2GACcH08617 Message accepted for delivery
quit
221 2.0.0 neunes.internetx.de closing connection
Connection closed by foreign host.
---cut
Return-Path: <and...@sysiphus.de>
Received: from neunes.internetx.de ([62.116.137.130])
by base.infra.de (8.12.1/8.12.1/INFRa) with ESMTP id g2GACkfi009983
for <and...@infra.de>; Sat, 16 Mar 2002 11:12:48 +0100 (CET)
Received: from blah ([194.121.21.248])
by neunes.internetx.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with
SMTP id g2GACcH08617
for and...@infra.de; Sat, 16 Mar 2002 11:12:43 +0100
Date: Sat, 16 Mar 2002 11:12:43 +0100
From: anders...@sysiphus.de
Message-Id: <200203161012...@neunes.internetx.de>
X-Authentication-Warning: neunes.internetx.de: Host [194.121.21.248]
claimed to be blah
To: undisclosed-recipients:;
X-UIDL: 80b4727056fc6d278f5e88e2c73b18ab
blah
---cut
Und an der Stelle wird der relaytest.kundenserver.de zu einer
enorm starken Sache: offene Relays koennen sich nicht mehr so leicht
verstecken.
Selbst, wenn diese dann anfangen, relaytest.kundenserver.de einfach
zu rejecten, koennte Schlund seine Relaytests so umbauen, dass Retests
von den normalen Outgoing-Hosts des Schlund-Mailsystems ausgefuehrt
werden.
Und das dann dumm zu blocken, duerfte fuer die offenen Relays ziemlich
fatal sein - schliesslich schneiden sie sich dann von ein paar
Millionen deutschen Internet-Usern ab, um ganz eindeutig Spammer zu
schuetzen. Fuer einen Relaytest-Blocker mag es ja einfach sein, einfach
orbz.org zu blocken, wenn aber neben den Relaytests auch sehr viel
erwuenschte Mail von den Hosts kommt, muessten sie ihre Rechner
zumindest soweit gegen Relaying absichern, damit Schlund nicht ueber
sie relayen kann.
Und an der Stelle wird sich doch jeder halbwegs normal denkende Mensch
ueberlegen, ob man das offene Relaying nicht gleich ganz wegkonfiguriert,
wenn man doch schon einmal die richtige Stelle im Konfigfile gefunden hat.
Any comments?
Anders
--
http://sysiphus.de/
Sebastian Niehaus
[...]
> > Ich schlage vor, daß genau einer für das, was in der Mail so steht
> > verantwortlich ist.
> >
> > Nämlich *Du*.
>
> Genau, und da hat kein Server eine weitere Mailadresse
> reinzuschreiben.
In den Header schreibt der Server das rein, was der Provider will. Die
Auswahl des Providers obliegt Dir. Nicht der Text und die Schriftart,
Farbe und die Flash-Version der Headerzeilen. Das Argument war mehr
als /indirekte/ Wahlmöglichkeit zu sehen.
> > Es zwingt Dich keiner, T-Online zu nutzen. Wenn Dir der Service
> > nicht passt, solltest Du über einen Wechsel nachdenken.
>
> Anders hat geschrieben das smtp.puretec.de wichtig war als TOL noch
> nicht relayed hat,
Das mag sein. Aber der implizit vorwurfsvolle Ton (und der kam in der
Tat nicht von Dir) ging in die Richtung: Puretec ist böse, weil sie
mich zu kaputter Software wie Netscape zwingen. Dein Einwand hörte
sich dann an wie "und Puretec muß man nehmen, weil T-Online schlimme
Sachen in den Header schreibt".
Soviel dazu.
> Wieviel Spam hast Du denn über Schlund bekommen?
Ich habe es nicht gezählt. Ich habe bei diversem Spam, der bei mir
aufgeschlagen ist jedoch deren Server im Header gesehen. Und das
vermutlich bei dem Teil, der nicht automatisch im Müll gelandet
ist. Framstags "spamblock" vergibt ja zumindest einen negativen
"Score" auf Mails von dort.
> Bevor die Spammer sich auf die kundenserver.de stürzen müßten
> erstmal sämtliche offenen Relays in Asien dicht sein, solange da
> alles Sperrangelweit offen ist brauchen die keine Ratespiele bei den
> Schlund- Servern zu spielen.
kundenserver.de hat stabil administrierte Server. Auf Asien filtert
inzwischen fast jeder abendländische Trottel-ISP, bei Kundenserver
macht es niemand (weil "man" es sich nich glaubt erlauben zu können,
Mails von einem der großen un DE verwerfen zu können).
> Wieso Schlund nicht von Anfang an SMTP-after-POP und/oder SMTP-Auth
> benutzt hat ist ein anderes Thema, bei GMX hat es ja auch
> funktioniert und die haben auch nicht gerade wenig Kunden.
>
> > Wenn dann [...] keinen vernünftigen Provider hat, hat er eben
> > Pech.
>
> Da stellt sich die Frage ob TOL als größter Provider in D in dieser
> Hinsicht ein "vernünftiger Provider" ist oder nicht. IMO eher nicht.
Eben. Zumindest, wenn einem wichtig ist, keinen X-Sender mitzuliefern.
Sebastian
Rainer Zocholl
>* Rainer Zocholl <Usenet...@zocki.toppoint.de> schrieb:
>>
>> Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
>> -lange- weiter so)
>> "Nettes" Verhalten nicht wahr?
>Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen
>will oder nicht, wenn du mehr Connections gleichzeitig annimmst als du
>verkraften kannst, dann ist das erstmal /dein/ Problem, nicht ihres.
Wie viele Rechner soll ich denn hinstellen?
20 30 100?
>Mit dem iplimit-Match von iptables z.B. ist es auch kein Problem, da
>wirksam Abhilfe zu schaffen.
Erzähl bitte mehr.
In dem Moment wo der Server blockiert wird, geht er auf den MX.
Also MXe abschalten?
Keine gute Idee....?
Gibt ne bessere.
Vielleicht würde ja "traffic shaping" funktionieren,
oder reduzieren der TCP-Fenster auf 3..4 bytes.
Aber bei dieser massiv parallelen Einlieferung
wohl eher nicht.
>> Jeder dieser Connects erzeugt schliesslich eine 500er Fehlermeldung.
>> "Eigentlich" müssten nach max. 15 minuten die Alarmglocken
>> bei Schlund schrillen "Server Missbrauch". Tun sie aber nicht.
>Naja, wahrscheinlich haben sie permanent eine recht hohe Load auf
>ihren Servern, daher fällt das auf ihrer Seite nicht unbedingt auf.
Es kommen aber tausende von Bounces an EINE Addresse!
Innerhalb von Sekunden.
Das fällt nur dann nicht auf, wenn die Addresse auf /dev/null landet.
Auch entschuldigt das nicht das "NichtAntworten" aus "Prinzip".
>Und wenn sich Schlund alle SMTP-Fehler ansehen wollte, die sie
>bekommen, dann hätten sie sicher /viel/ zu tun ;-)
Es reicht die cgi-Fehler anzusehen, die alle auf einem -system-
Account landen.
Denn nur dort findet derzeit der massive Missbrauch statt.
>> Es geht so stundenlang(!) weiter. Am Tage! Während der
>> normalen Arbeits.
>IOW, solange der gerade aktive Spammer Mails an euch abkippt.
Oder die Quue bei Schlund noch voll ist...und die nix merken...
Sascha Kimmel
news:8Kvgk...@zocki.toppoint.de...
> Virtual hosting geht ja wohl auch bei port 25?
Nein, geht nicht, da SMTP immer nur IP-basiert läuft, d.h. es gibt nicht wie
bei HTTP 1.1 den "Host"-Header, der mitgesendet wird.
Wenn Du ein TELNET auf Port 25 eines Servers startest, löst das
TELNET-Programm die IP für die angegebene Domain auf. Es ist dem
angesprochenen SMTP-Server aber NICHT möglich zu wissen, WIE er angesprochen
wurde, denn es gibt wie gesagt keinen "Host"-Header wie bei HTTP 1.1.
Siehe auch RFC 821.
Grüße
Sascha
Marc Haber
>(Andreas Ferber) 16.03.02 in /de/admin/net-abuse/mail:
>>will oder nicht, wenn du mehr Connections gleichzeitig annimmst als du
>>verkraften kannst, dann ist das erstmal /dein/ Problem, nicht ihres.
>
>Wie viele Rechner soll ich denn hinstellen?
>20 30 100?
Einen. Sinnvoll konfiguriert.
>In dem Moment wo der Server blockiert wird, geht er auf den MX.
Du redest wirr.
Rainer Zocholl
>Rainer Zocholl <Usenet...@zocki.toppoint.de> wrote:
>>> We're also sending out daily bulk-submits to ordb as well as other
>>> RBLs, so the public RBLs get to know of our findings and there's no
>>> need for you to add our RBLs.
>> Ach, das ist nat?rlich ne Gute Sache(tm). (Hab's wirklich nicht
>> gelesen. sorry. (Vielleicht den Absatz vielleicht vor die RBL
>> liste?)
>Hmmm. Du willst keine drei Zeilen weiterscrollen?
Nein, aber der Absatz sieht so aus, als sei er rangeklatscht worden
und sei etwas anderes.
>Schicke Verbesserungsvorschlaege doch an
>postm...@relaytest.kundenserver.de (postmaster muss ja existieren).
Nein, muss nicht. Nur wenn relaytest.kundenserver.de
eMails annehmen kann (ja, Marc, das ist vereinfacht dargestellt
und stimmt hier nicht ;-))
>> Ja, ich war auch schon drauf und dran so was zu bauen, als die
>> Probleme mit den offenen Proxies begannen. Diese waren in den
>> den meisten listen nicht vertreten, und bl.spmcop.net will
>> man nicht wirklich zum blocken nutzen.
>>
>> Welche Software wird da verwendet?
>> Gibt's da was freies?
>Ich kenne nichts, was in der Richtung arbeitet. Die meisten
>Antispam-Fallen wollen einfach fleissig die Webfrontends und
>Trap-Adressen von orbz mit allen IPs zumuellen, die irgendein
>Procmail-Skript in als "Spam" deklarierten Mails definiert
>oder in irgendwelchen Logfiles aufgetrieben werden.
>Aktive Antispam-Tools sind mir nicht bekannt, insofern duerfte
>es irgendeine Eigenentwicklung sein.
Naja, von orbd kann man sich deren Software runterladen.
>> Ausser es ist ein Multilevel relay...
>Wirklich offene Multilevel-Relays sind praktisch nur sehr schwer
>von Smarthosts zu unterscheiden.
Ja.
>Selbst, wenn du als ISP mit x Mio Kunden ueber authentifizierte
>Verbindungen Mails annimmst und ein einzelner Kunde dann ein offenes
>Relay baut, das aber alle Mails authentifiziert weiterschickt, gibt es
>einfach mit heutigen Mitteln keine reale Chance, dieses vorher zu
>entdecken.
Doch: Wenn Du fremde Server auf relayfestigkeit testest,
warum nicht auch die Kundenrechner?
Auch ist es hilfreich die Kundenrechner gegen die anderne RBLs
zu checken, da nicht alle Listen synchron arbeiten.
>Wenn du das aber nicht tust, kann dir ein einziger Kunde
>dein gesamtes Mailsystem in wenigen Sekunden bei einer Reihe von RBLs
>listen:
Jepp. Kenn ich.
>Auch ORDB listet daher nur inputs und keine outputs.
>Der Schaden, den man mit output-Listings anrichten kann,
Emm, die Listung(!) ist nicht gefährlich
Gefährlich ist der unqualizierte Gebrauch der Listen!
>> Da must Du ja erstmal man den Einlieferungspunkt finden
>> oder den Muell annehmen, hoffen das der Server loggt und
>> analysieren.
>Und was machst du bei gefakten Headern?
Steht da doch: "Hoffen" ;-)
>Ich habe letzt erst Korea-Spam bekommen, der angeblich von
>einem .nl-Dialup zu yahoo, von dort per
>asmtp zu hotmail, von dort aus dann ohne Received-Zeile zu GMX, die
>das dann angeblich nach Korea geschickt haben.
Sind sie nicht süss? ;-))
Aber: Die Kiste war evtl. ein offener Proxy.
Und: Wenn Du den .nl getestest hättest wäre der Test
wohl nicht durchgegangen.
>Ich sehe aber auch keinen Grund, warum die fuer
>relaytest.kundenserver.de sowie fuer spamblock.kundenserver.de
>eingesetzte Software nicht auch auf die eigenen Smarthosts angesetzt
>werden sollte und darueber Kunden-IPs temporaer sperrt, wenn
>-es sich bei ihnen um offene Relays handelt oder
>-der Sender mehr als x Mails pro Minute verschickt hat
ACK.
Das mit den "x Mails pro sekunde" knaste vergessen,
da die Spammer die eMails auf viele relays verteilen
damit es nicht auffällt.
>Das heisst, einen Grund gibt es: Personal Firewalls, die bei jedem
>unkritischen Krams die Alarmsirene laeuten und darueber dann zu
>Beschwerden fuehren.
Weist Du, hier kam vor einiger Zeit eine böse Mail eines
"Security Consultants", unser (mail!)Server würde Portscans machen.
Als "Beleg" kam dann ein Log file das einige fehgeschlagene
Connects auf Port 113 im Minuten-Abstand zeigte.
Da der Herr "Security Consultant" keine Angaben über den
Zeitoffset machte, mussten wir suche und fanden dann einen
regen Mail Verkehr eines unserer User mit einem seinem.
Und unser Mail server machte -aus historischen Gründen- immer
einen Identd Zugriff...
Also: Das schimpfen auf "PFW" bringt nix, auch Fachleute
sind manchmal mit ihren IDS-Logfiles überfordert.
>Ganz ehrlich: wenn du als Kunde bei Puretec ueber auth.smtp.puretec.de
>eine Mail verschickst und dich dann so ein "kundenserver.de"-Rechner
>"per SMTP angreift", kommst du da sofort auf die Idee, dass es sich
>dabei um eine redliche Sache handelt?
Ein Frage der Pressearbeit.
Benachrichtig Schlund eigentlich seine Kunden, wenn sie
eMails für ihn abgelehnt haben?
Weil:
Auch ein offenes relay kann legal genutzt werden!
(ist sogar die Regel)
>Im naechsten Moment googlest du mal etwas herum, siehst, dass
>"kundenserver.de" ein boeser Spammerladen ist und du schleppst
>natuerlich sofort deine duerftigen Firewalllogs zur Beschwerde weg.
Klar. Das hat man eh vorher gemacht ;-)
>Aber cool waere es schon, wenn man auch die einliefernden Kunden
>testen wuerde.
Naja, diese Diskussion gab es vor ca. 2a schon mal.
Es wurde abgelehnt.
>Was sagst du aber gegen Spammer, die einfach versuchen, auf jedem
>Host in deinem Netz ihren Spam zum Relaying einzuliefern? Fahre eine
>noch nie verwendete IP hoch und warte einfach mal einen Tag
Ein Tag? So lang?
>- danach hast du doch dutzendweise Relayversuche von irgendwelchen Dialup-IPs.
>Das duerfte ein viel groesseres Problem sein.
>> Wenn nicht bei jeder email musst Du eine Datenbank fahren.
>apt-get install mysql-server.
;-))
>Fuer diese Aussage brauchst du doch nur eine Tabelle mit ip, letztem
>Status und einem lastcheck-Datum. Wenn man sich anstrengt und fleissig
>lockt, bekommt man die Informationen auch in einem DBM-File verwaltet.
Ich mag diese Aussagen: "das sind doch nur 3 Zeilen Code" ;-)
>Wo ist das Problem?
Das es mit den 3 Zeilen meist doch nicht getan ist...
>SQL wurde urspruenglich fuer kaufmaennische Angestellte entwickelt und
>die Grundlagen "select, insert, update, delete" sind doch in zehn
>Minuten schnell gelernt. Eine Datenbank ist da nicht das Problem.
>Und wer ein offenes Relay hat, sollte sich ueber Test-Traffic nur
>schwer beschweren koennen ...
:-)
Der merkt beides nicht!
Die Spammer nutzen die offenen relays oft nur für
ein paar eMails und gehen dann weiter.
>Daher muss man eigentlich auch die eigenen IP-Allocations von Tests
>ausnehmen. Und wenn das ganze kompliziert wird, weil du dabei auch
>noch wechselnde Kunden-IPs hast, kann man es eh' vergessen.
Das war das was ich mit den "3 Zeilen Code" meinte..
Solche Fallen stecken da noch mehr drin.
>Auf der http://relaytest.kundenserver.de/stats.php gibt es ja auch
>eine Uebersicht ueber die Datenbank und ueber die Testergebnisse.
>Schlund spielt da mit erstaunlich offenen Karten, hilft mit einem
>"stillen" Relaytester den Commons
Du siehst mich völlig verwundert.
Das liegt vielleicht daran, das ich vor ein paar
Jahren eine eMail von einem gewisse Rainer Schlund bekommen habe,
in dem er singemäss schrieb, dsa ihn egal sei was seine Kunden
machen solange sie zahlen, das sie die eMails ihrer Kunden nicht
öffnen dürften (was ja auch keiner verlangt hatte. Die "(junk) eMails hatte
ich denen schon geöffnet geschickt..)
>und macht die Testergebnisse
>komplett oeffentlich abruf- und verifizierbar. Wenn du ein offenes
>Relay sofort retesten lassen moechtest, geht das ueber die View-Seite
>und fuenf Minuten spaeter ist das Testergebnis fertig.
>Das sollte man foerdern und nicht darauf herumhacken.
Naja, ich dachte mehr an eine DNS-Zone...
>> ich f?rchte, das Verfahren scaliert nicht.
>Warum nicht?
Weil immer mehr Server andere Server testen.
>Die Datenbank enthaelt alle fuer dich relevanten Hosts und nicht mehr.
Ja, "meine" Datenbank.
>Mit den Relaytest-Blockern ist das auch so eine Sache
Klar. Wenn der Relay-text von mout*.kundenserver.de käme
hätten einige Admins ein herbes Problem...
Insofern ist es (doch) wirklich sinnvoll, das soviele
Hosts wie möglich den Relay test machen.
>- interessant wird es, wenn du eine IP hast, die bei ORBZ als
>"clean" bezeichnet wird, aber bei relaytest.kundenserver.de nicht. Gestern bekam so etwas
>bei mir an:
>http://relaytest.kundenserver.de/point.php?ip=62.116.137.130
>Ganz ehrlich - wenn Schlund seine Testnachricht nach zwei Sekunden
>zurueckbekommt (steht im Header!), ordb selbst nach fast einer Woche
>noch keinen Relay-Beweis hat und ich auch von meinem Shellaccount
>bei einem manuellen Test in wenigen Sekunden meine Mail bekomme,
>ist da etwas faul:
Klar.
>Und an der Stelle wird der relaytest.kundenserver.de zu einer
>enorm starken Sache: offene Relays koennen sich nicht mehr so leicht
>verstecken.
100% ACK.
>Selbst, wenn diese dann anfangen, relaytest.kundenserver.de einfach
>zu rejecten, koennte Schlund seine Relaytests so umbauen, dass Retests
>von den normalen Outgoing-Hosts des Schlund-Mailsystems ausgefuehrt
>werden.
Jepp.
Vielleicht ist Schlund pervers genug die Scripte in
OpenSource zu stellen?
>Und das dann dumm zu blocken, duerfte fuer die offenen Relays ziemlich
>fatal sein - schliesslich schneiden sie sich dann von ein paar
>Millionen deutschen Internet-Usern ab, um ganz eindeutig Spammer zu
>schuetzen.
Naja, "deutschen"... spamcop hatte sogar gmx gelistet
und orbd nahm nomierungen via gmx, web an...
Woher sollen sie es auch wissen?
>Fuer einen Relaytest-Blocker mag es ja einfach sein,
>einfach orbz.org zu blocken, wenn aber neben den Relaytests auch sehr
>viel erwuenschte Mail von den Hosts kommt, muessten sie ihre Rechner
>zumindest soweit gegen Relaying absichern, damit Schlund nicht ueber
>sie relayen kann.
>Und an der Stelle wird sich doch jeder halbwegs normal denkende Mensch
>ueberlegen,
Diese Admins und Spamme denken nicht!
>ob man das offene Relaying nicht gleich ganz
>wegkonfiguriert, wenn man doch schon einmal die richtige Stelle im
>Konfigfile gefunden hat.
Nein, dann kommt der Geschäftführer und sagt:
"meine vertriebsmitarbeiter muessen von überall auf der
Welt eMails einliefern können"
Du: "SSL, SSH, VPN, smtp-auth..."
Er: "Was ist das? Kostet das irgendwie Geld oder Zeit?
Macht es die Benutzung/Konfiguration komplzierter?"
Du: Ja
Er: Dann vergessen Sie es.
Du: Dann kündige ich.
Er: Dann kündigen Sie ebend.
Also bleibt die Kiste offen.
Entweder von Dir offen gelassen, oder der nächste
Admin wird so ausgesucht das er sie offen lässt,
wenn nicht der GF selbst diesen trivialen Job macht.
>Any comments?
Schon lange nicht mehr so einen konstruktiven Beitrag hier gelesen.
Marc Haber
>Nein, geht nicht, da SMTP immer nur IP-basiert läuft, d.h. es gibt nicht wie
>bei HTTP 1.1 den "Host"-Header, der mitgesendet wird.
>Wenn Du ein TELNET auf Port 25 eines Servers startest, löst das
>TELNET-Programm die IP für die angegebene Domain auf. Es ist dem
>angesprochenen SMTP-Server aber NICHT möglich zu wissen, WIE er angesprochen
>wurde, denn es gibt wie gesagt keinen "Host"-Header wie bei HTTP 1.1.
Du könntest ohne weiteres für jede IP einen eigenen Prozess starten.
Rainer Zocholl
>"Rainer Zocholl" <Usenet...@zocki.toppoint.de> schrieb im
>Newsbeitrag news:8Kvgk...@zocki.toppoint.de...
>> Virtual hosting geht ja wohl auch bei port 25?
>Nein, geht nicht, da SMTP immer nur IP-basiert läuft, d.h. es gibt
>nicht wie bei HTTP 1.1 den "Host"-Header, der mitgesendet wird.
Ja. Ich hätte ""Virtual hosting"" in """ schreiben sollen.
>Wenn Du ein TELNET auf Port 25 eines Servers startest, löst das
>TELNET-Programm die IP für die angegebene Domain auf.
Es ging um den Namen in dem HELO-String, wenn Du Dir
Ausgangsfrage ansiehst.
Wäre die 7 Mail-out von Schlund ein Rechner mit einem SMTPD,
so würde der Helo-String bei allen 7 natürlich derselbe sein.
Es ist aber nicht derselbe.
Nur: Das muss nicht heissen, das das verschiedene Rechner sind.
(Genauso wenig wie man sagen kann, wenn der HELO gleich ist,
ist es nur ein Rechner der sich unter verschiedenen IP meldet...logo)
>Es ist dem angesprochenen SMTP-Server aber NICHT möglich zu wissen,
>WIE er angesprochen wurde,
Aber sicher weiss er, auf welche IP-Nummer der Connect gekommen ist
und könnte seinen HELO so anpassen.
So könnte man seinen Kunden/Konkurrent/Analysten
mehr Server vortäuschen als wirklich vorhanden.
Warum man das tun sollte?
>denn es gibt wie gesagt keinen "Host"-Header wie bei HTTP 1.1.
>Siehe auch RFC 821.
Das ist das flasche Layer.
"virutal hosting" ist das falsche Wort dafür.
Gib ein besseres.
Rainer Zocholl
>Usenet...@zocki.toppoint.de (Rainer Zocholl) wrote:
>>(Andreas Ferber) 16.03.02 in /de/admin/net-abuse/mail:
>>>Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen
>>>will oder nicht, wenn du mehr Connections gleichzeitig annimmst als
>>>du verkraften kannst, dann ist das erstmal /dein/ Problem, nicht
>>>ihres.
>>
>>Wie viele Rechner soll ich denn hinstellen?
>>20 30 100?
>Einen. Sinnvoll konfiguriert.
Erzähl mehr.
>>In dem Moment wo der Server blockiert wird, geht er auf den MX.
>Du redest wirr.
Du meinst, du kannst mir nicht folgen? ;-)
Du bewirbst Dich nicht gerade für den "Mitdenker-Preis 2002"?
Du hättest wenig Chancen, nach dem was Du hier die letzten Tage ablässt.
"den MX" meint hier natürlich "Fallback MX", das sollte
aus dem Kontext klar sein.
Muss man gewissen Leuten denn wirklich jedes Wort vorkauen?
Sebastian Niehaus
> >> Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
> >> -lange- weiter so)
> >> "Nettes" Verhalten nicht wahr?
>
> >Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen
> >will oder nicht, wenn du mehr Connections gleichzeitig annimmst als du
> >verkraften kannst, dann ist das erstmal /dein/ Problem, nicht ihres.
>
> Wie viele Rechner soll ich denn hinstellen?
> 20 30 100?
Du könntest Dir was bauen.
Ohne es im Einsatz zu haben:
,----=[ man couriertcpd ]=---
|
|
| [...]
|
| -maxperip=n
| maximum number of connections accepted from the
| same IP address. Use both the -maxperc and -max-
| perip options to fine tune connection limits. For
| example, when couriertcpd is listening on the SMTP
| port it makes sense to set an upper limit on the
| number of connections from the same C block.
| Domains that send a large amount of mail often have
| multiple servers sending outbound mail from the
| same C block, so it makes sense to set limits on
| individual C blocks. On the other hand, if couri-
| ertcpd is listening on the POP3 port it makes more
| sense to set limits on individual IP addresses. If
| a C block of addresses is assigned to a dialup
| modem pool, it is certainly possible to have many
| IP addresses within the same C block have connec-
| tions to the POP3 server at the same time.
|
| [...]
|
`----
Sebastian Niehaus
[Quoting umgestellt]
[...]
> "den MX" meint hier natürlich "Fallback MX", das sollte
> aus dem Kontext klar sein.
Nun ja.
Nur so aus Interesse: hat sich schoneinmal jemand getraut, Dich das
Wort "Mailserver" buchstabieren zu lassen?
> Muss man gewissen Leuten denn wirklich jedes Wort vorkauen?
Ja.
> Erzähl mehr.
q.e.d
Se "man couriertcpd" bastian
Andreas Ferber
> oder reduzieren der TCP-Fenster auf 3..4 bytes.
> Aber bei dieser massiv parallelen Einlieferung
> wohl eher nicht.
Lass von jeder IP aus maximal n (n so gewählt, daß du auch verkraftest,
wenn Schlund aus allen Rohren gleichzeitig lospustet) Connections
gleichzeitig zu, fertig. Wo ist das Problem?
>>Und wenn sich Schlund alle SMTP-Fehler ansehen wollte, die sie
>>bekommen, dann hätten sie sicher /viel/ zu tun ;-)
> Es reicht die cgi-Fehler anzusehen, die alle auf einem -system-
> Account landen.
Was meinst du, wie viele Bounces bei einer Million gehosteten Domains
pro Stunde auf diesem Account aufschlagen? Und da wird sicher nicht
jemand bei Schlund sitzen und den ganzen Tag nur auf die Mailbox
starren, um die durchflirrenden Bounces zu lesen. Rein technisch sind
das alles "normale" Vorgänge, deren System scheint auch nicht drunter zu
leiden, also werden da auch nicht irgendwelche Alarmglocken angehen.
Rainer Zocholl
>Usenet...@zocki.toppoint.de (Rainer Zocholl) writes:
>>>> Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
>>>> -lange- weiter so)
>>>> "Nettes" Verhalten nicht wahr?
>>
>>>Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen
>>>will oder nicht, wenn du mehr Connections gleichzeitig annimmst als
>>>du verkraften kannst, dann ist das erstmal /dein/ Problem, nicht
>>>ihres.
>>
>> Wie viele Rechner soll ich denn hinstellen?
>> 20 30 100?
>Du könntest Dir was bauen.
>Ohne es im Einsatz zu haben:
>,----=[ man couriertcpd ]=---
>|
>|
>| [...]
>|
>| -maxperip=n
>| maximum number of connections accepted from the
>| same IP address.
Nuschle ich so oder ist wirklich so schwer zu begreifen?
Wenn unser Mailer das Zeug nicht abnimmt, also
keine Verbindungen mehr zu lässt, dann geht der einleifernde
Server auf unseren Fallback MX. Natürlich.
Er muss ja glauben der Mailserver ist down, oder?
Damit ist also NICHTS gewonnen, nein, es wird sogar noch
schlimmer:
Jetzt kommt das Zeug noch von den MXen rein.
>Use both the -maxperc and -max-
>| perip options to fine tune connection limits. For
>| example, when couriertcpd is listening on the SMTP
>| port it makes sense to set an upper limit on the
>| number of connections from the same C block.
Wenn man keine Fallback MX hat oder einen eigenen, ist das natürlich
ne Möglichkeit.
Aber mir so einer TRIVIAL-Frage würde ich mich doch nicht
in an diese Gruppe wenden.
Nein, ich kann natürlich keinen Einfluss auf die Fallback-MXe nehmen.
Ausserdem: Warum sollte man den kundenserver auf IP Ebene sperren?
Wie soll den User gesagt werden, das -legitime(!)- eMail für
sie abgelehnt worden ist?
Ja, es gibt server die KEINEN 2. Versuch machen, wenn der
Ziel server nicht meldet. Besonders Billig-Provider machen sich
nicht die Mühe es ein weiteres aml zu versuchen, logo.
Es ist ja auch kein "must". (Und die Kunden merken es eh nicht,
da man Fehlermeldungen den Kunden garnicht erst zu kommen lässt.
Die email ist halt "verschwunden". Der Kunde glaubt es.)
>| Domains that send a large amount of mail often have
>| multiple servers sending outbound mail from the
>| same C block, so it makes sense to set limits on
>| individual C blocks.
Anscheindend ist "Fallback MX" ein Fremdword geworden?
Rainer Zocholl
>Usenet...@zocki.toppoint.de (Rainer Zocholl) writes:
>[Quoting umgestellt]
>[...]
>> "den MX" meint hier natürlich "Fallback MX", das sollte
>> aus dem Kontext klar sein.
>Nun ja.
>Nur so aus Interesse: hat sich schoneinmal jemand getraut, Dich das
>Wort "Mailserver" buchstabieren zu lassen?
Dir anscheindend nicht mal da ;-)
>> Muss man gewissen Leuten denn wirklich jedes Wort vorkauen?
>Ja.
>> Erzähl mehr.
>q.e.d
>Se "man couriertcpd" bastian
See man fallback MX
Wenn wir keinen Connect machen gehen die Schlund-Server auf
unsere MXe.
Dort musste die Connect-Sperre auch erstmal greifen!
Ausserdem:
Bei uns diese "DenailOfService" Möglichkeit unter Einsatz der
Schlund-Mail+Webserver aufgefallen.
Bei vielen Systemen wird das nicht aufgefallen sein und diese
einer DOS-Attacke völlig schutzlos ausgeliefert sein.
Es sind ja nicht nur die Server, sondern vorallem die
offenen CGI-Scripte die Schlund nicht in den Griff bekommt!
Sebastian Niehaus
Crosspost & Followup-To: de.comm.software.mailserver, deshalb
großzügiges Quoting.
Usenet...@zocki.toppoint.de (Rainer Zocholl) writes:
> (Sebastian Niehaus) 16.03.02 in /de/admin/net-abuse/mail:
>
> >Usenet...@zocki.toppoint.de (Rainer Zocholl) writes:
>
> >>>> Das waren "kurzmal" 48 Connects in 24sec (und es geht noch
> >>>> -lange- weiter so)
> >>>> "Nettes" Verhalten nicht wahr?
> >>
> >>>Ob man jetzt allerdings das Verhalten der Schlund-Server gutheissen
> >>>will oder nicht, wenn du mehr Connections gleichzeitig annimmst als
> >>>du verkraften kannst, dann ist das erstmal /dein/ Problem, nicht
> >>>ihres.
> >>
> >> Wie viele Rechner soll ich denn hinstellen?
> >> 20 30 100?
>
> >Du könntest Dir was bauen.
>
> >Ohne es im Einsatz zu haben:
>
>
> >,----=[ man couriertcpd ]=---
> >|
> >|
> >| [...]
> >|
> >| -maxperip=n
> >| maximum number of connections accepted from the
> >| same IP address.
>
>
> Nuschle ich so oder ist wirklich so schwer zu begreifen?
Du bist schwer zu begreifen.
> Wenn unser Mailer das Zeug nicht abnimmt, also
> keine Verbindungen mehr zu lässt, dann geht der einleifernde
> Server auf unseren Fallback MX. Natürlich.
> Er muss ja glauben der Mailserver ist down, oder?
Ja. Dann geht er auf dem Fallback-MX. Ist der schlecht konfiguriert
oder wo ist nun das Problem?
Lässt der sich auch plattmachen?
> Damit ist also NICHTS gewonnen, nein, es wird sogar noch
> schlimmer:
> Jetzt kommt das Zeug noch von den MXen rein.
Also: Gegeben sei eine Anzahl von Mails, die von Schlund zu Deinen
Servern zugestellt werden soll. Was ist jetzt plötzlich so schlimm
daran, wenn das über deinen Backup-MX reinkommt? Was ist daran "sogar
noch schlimmer"?
BTW: 'man könnte' ja auch für den Backup-MX eine geeignete
Konfiguration finden. Spätestens, wenn Schlund die Maik nicht in der
ersten Attacke los wird, greifen ja andere Mechanismen...
> >Use both the -maxperc and -max-
> >| perip options to fine tune connection limits. For
> >| example, when couriertcpd is listening on the SMTP
> >| port it makes sense to set an upper limit on the
> >| number of connections from the same C block.
>
> Wenn man keine Fallback MX hat oder einen eigenen, ist das natürlich
> ne Möglichkeit.
Und wer zwingt Dich, auf einem momentan überlasteten Mailserver noch
armdicke Datenströme vom Backup-MX zu schlucken?
Also, wenn Du die Mail irgendwann haben willst, bist Du im Vorteil,
wenn Du sie in Dein System lässt. Sonst kannst Du Schlund gleich
komplett abklemmen.
> Aber mir so einer TRIVIAL-Frage würde ich mich doch nicht
> in an diese Gruppe wenden.
Nun ja.
> Nein, ich kann natürlich keinen Einfluss auf die Fallback-MXe nehmen.
Dann eben auf Deinen eigenen Server. "man couriertcpd" gilt immernoch
als Anregung.
> Ausserdem: Warum sollte man den kundenserver auf IP Ebene sperren?
Wer sprach davon? Bei Deinem Problem (Kundenserver macht mit vielen
Verbindungen das eigene System platt) ist das wohl eine sinnvolle
Option.
> Wie soll den User gesagt werden, das -legitime(!)- eMail für
> sie abgelehnt worden ist?
Hallo? Noch jemand zu Hause? Es geht nicht um Ablehnen, sondern darum,
den Server nicht von kometenhaft hochschnellenden Parallelverbindungen
plattmachen zu lassen. Es geht darum, Lastspitzen zu entzerren. Ist
das so schwer zu begreifen?
> Ja, es gibt server die KEINEN 2. Versuch machen, wenn der
> Ziel server nicht meldet. Besonders Billig-Provider machen sich
> nicht die Mühe es ein weiteres aml zu versuchen, logo.
Namen? Bitte jetzt nicht Bulkmailer-Dial-up Pro[tm]
Du willst nicht alle Verbindungen gleichzeitig haben, aber die Mail
beim ersten Versuch bekommen, aber komplett.
Sagmal, machst Du in Deiner Firma irgendwas mit Computern, oder ist
das mehr so Hobby. Nur falls mich 'mal jemand um eine Meinung oder
Empfehlung bitten sollte...
> Es ist ja auch kein "must". (Und die Kunden merken es eh nicht,
> da man Fehlermeldungen den Kunden garnicht erst zu kommen lässt.
Kannst Du solche Behauptungen 'mal belegen? Danke.
Daß Mailserver so konfiguriert sind, daß sic nach einem Mal aufgeben,
wäre endlich mal einen Neuigkeit hier.
> Die email ist halt "verschwunden". Der Kunde glaubt es.)
Jaja. Nicht nur der....
> >| Domains that send a large amount of mail often have
> >| multiple servers sending outbound mail from the
> >| same C block, so it makes sense to set limits on
> >| individual C blocks.
>
> Anscheindend ist "Fallback MX" ein Fremdword geworden?
Nein. Wo war jetzt der Zusammenhang?
Sebastian
Rainer Zocholl
>* Rainer Zocholl <Usenet...@zocki.toppoint.de> schrieb:
>>
>> Vielleicht würde ja "traffic shaping" funktionieren,
>> oder reduzieren der TCP-Fenster auf 3..4 bytes.
>> Aber bei dieser massiv parallelen Einlieferung
>> wohl eher nicht.
>Lass von jeder IP aus maximal n (n so gewählt, daß du auch
>verkraftest, wenn Schlund aus allen Rohren gleichzeitig lospustet)
>Connections gleichzeitig zu, fertig. Wo ist das Problem?
Das die Schlund-Server das nicht weiter stört:
Sie sehen: aha MX A reagiert nicht, aber wir haben da
ja noch den Fallback MX B oder den MX C.
Dann hängt das Zeug auf den MXen, klasse.
Und die dürfen dann auch so einen Schlund-Buster einbauen...
kann irgendwie nicht sinn der Übung sein.
(Für schlund schon. So haben andere die Kosten und die Arbeit
sich von den DOA-attacken der Schlund-Systeme zu schützen,
Schlund spart aber die Arbeit, seine cgi-scripte relayfest zu machen.).
>>>Und wenn sich Schlund alle SMTP-Fehler ansehen wollte, die sie
>>>bekommen, dann hätten sie sicher /viel/ zu tun ;-)
>> Es reicht die cgi-Fehler anzusehen, die alle auf einem -system-
>> Account landen.
>Was meinst du, wie viele Bounces bei einer Million gehosteten Domains
>pro Stunde auf diesem Account aufschlagen?
Keine? Weil "normaleweise" eMails an die richtigen Addressen
gehen, nur Spam nicht.
>Und da wird sicher nicht jemand bei Schlund sitzen
Heisst Du im RL evtl. "Rainer Schlund"? ;-)
Der schrieb auch immer so seltsame absurde Sachen,
um sich zu rechtfertigen ala "Wir dürfen die emails unserer
Kunden nicht öffenen". Ja, das hatte auch keiner gefordert.
>und den ganzen Tag nur auf die Mailbox
>starren, um die durchflirrenden Bounces zu lesen.
Würde viele arbeitslose Informatiker beschäftigen ;-))
Aber:
Dazu gibt es perl oder andere nette Programmiersprachen, die
GENAU dazu gedacht waren, aus der Notwendigkeit entwickelt wurden
"unhandliche" Logfiles zu analysieren.
Aber klar: Das kostet Schlund Geld. Und die werden
sicherlich keine ManPower investieren, um weniger Umsatz zu produzieren:
Den Dreck via den CGI-Muellscripten (die wohl von Schlund
seinen Kunden vorgegeben werden, oder wieso ist da immer derselbe
Env From drin?) bezahlen ja die Kunden, deren scripte missbraucht wurden.
>Rein technisch sind das alles "normale" Vorgänge,
Tausende(!) (i.W. T A U S E N D E ) von Bounces "User Unknown"
von EINEM System in wenigen Stunden an eine Addresse bezeichnest
Du als "normalen" Vorgang?
Andere Leute bezeichnen das als DialOfService.
Die Telekom^W Bundespost hatte so einen Spammer vor den
Kadi zerren können, der einfach an alle Telefon-Nummern via BTX
eMails geschickt hat. Gekillt hatte das email-BTX gatway nicht der
Spam, sondern die Fehlermeldungen! (Also "connect abzählen" hätte nix
genutzt" Für 2 Tage.
Nur hier wird das schwierig, da Schlund
natürlich keinerlei Kooperations-Bereitschaft zeigt (natürlich)
und -natürlich- auch kein Interesse hat den Umsatz zu reduzieren.
Deren System macht das ja nix aus, wie Du ganz richtig feststellst.
Was sind 5000 emails bei 5 Mio täglich?
Gerade mal Promille. "Peanuts".
Sorry, da kann etwas nicht stimmen, das sich im Internet
nur noch Grosskampfmachinen befinden dürfen, weil
ein einzeler Herr meint, seinen Kunden keine relay festen
Scripte zumuten zu dürfen.
>deren System scheint auch nicht drunter zu leiden,
Ne, logo. Sie verdienen ja auch an jeder relayten cgi-mail.
Denn diese dem Eigner zuzuordenen wird sicherlich möglich sein.
>also werden da auch nicht irgendwelche Alarmglocken
>angehen.
Ne, das ist das Problem:
Es leiden nur andere Systemen darunter. sigh.
Und wenn man will, das der Konkurrent sein Angebot nicht
einliefern kann, benutzt man kurz und kostenlos(!) die
Infrastruktur von Schlund für eine DOS Attacke.
Gute Sache von Schlund, echt nett von denen solche dicken
Systeme in Netz zustellen und dann sich selbst zu überlassen
und nur auf das Accounting zu achten.
(Ich weiss nicht wieviele Leute bisher auch die Idee gekommen
sind die Anzahl der Connects pro host zu reduzieren.
Vorallem: Ich weiss auch nicht wie der Schlundserver reagiert,
wenn er keinen MX einer Domain errechen kann.
Ich habe Zweifel das er es 5 Tage lang versuchen wird,
denn DAS kostet Schlund wieder -unnötig- Geld.
Denn: Es sind ja nicht nur Junk mails die von Schlund kommen.
Ein blocken auf IP-Ebene würde aber auch legale eMails unterbinden!
Anders Henke
>>Schicke Verbesserungsvorschlaege doch an
>>postm...@relaytest.kundenserver.de (postmaster muss ja existieren).
> Nein, muss nicht. Nur wenn relaytest.kundenserver.de
> eMails annehmen kann (ja, Marc, das ist vereinfacht dargestellt
> und stimmt hier nicht ;-))
Gut, dann von der anderen Argumentation her frei nach RFC2821 Abschnitt
4.5.1 ("Minimum Implementation"):
Any system that includes an SMTP server supporting mail relaying or
delivery MUST support the reserved mailbox "postmaster" as a case-
insensitive local name. This postmaster address is not strictly
necessary if the server always returns 554 on connection opening (as
described in section 3.1).
Es wird versucht, an rel...@relaytest.kundenserver.de Mail zu relayen.
MX fuer relaytest.kundenserver.de ist relaytest.kundenserver.de.
Also matcht bereits "delivery".
Damit ist postm...@relaytest.kundenserver.de primaerer Adressat, falls
mit dem Betrieb dieser Kiste irgendwelche Mail-Probleme verbunden sind.
Da es auf den Webseiten keine Kontaktadresse gibt, ist es die einzige
fuer mich ersichtliche Adresse - also nehme ich die solange, bis in die
Webseiten eine Kontaktmoeglichkeit kommt.
>>Selbst, wenn du als ISP mit x Mio Kunden ueber authentifizierte
>>Verbindungen Mails annimmst und ein einzelner Kunde dann ein offenes
>>Relay baut, das aber alle Mails authentifiziert weiterschickt, gibt es
>>einfach mit heutigen Mitteln keine reale Chance, dieses vorher zu
>>entdecken.
> Doch: Wenn Du fremde Server auf relayfestigkeit testest,
> warum nicht auch die Kundenrechner?
-Dialups: du musst die IPs sehr schnell wieder expiren, sonst triffst du
die falschen Leute.
Da ein Dialup von sich aus aber recht selten Mail schickt, ist die Gefahr zu
hoch, dass ein Eintrag expired, bevor der Dialup tatsaechlich
zum Relaying missbraucht wird. Nutzen: gegen null.
-Reseller: "kundenserver.de" wird fuer Reseller benutzt (um einfachen
whois-Kuenstlern gegenuber zu verschleiern, dass Schlund dahintersteckt).
Daher muesste man entweder die Verschleierung aufgeben und zugeben,
dass Schlund/Puretec dahintersteckt, damit man nicht zu sehr von
irgendwelchen PFW-Leuten zugemuellt wird.
Gibt man das aber zu, springen einem die ganzen Reseller ab.
Eine andere Secondlevel-Domain dafuer zu nehmen, waere natuerlich
auch moeglich; dann ist aber schlecht ersichtlich, dass dieses System
zur Absicherung eines recht grossen Providers benutzt wird.
> Auch ist es hilfreich die Kundenrechner gegen die anderne RBLs
> zu checken, da nicht alle Listen synchron arbeiten.
Also gilt es dazu, die Listen zu synchronisieren und untereinander
Abgleiche zu ermoeglichen. Dazu braucht man im Prinzip nur zwei
Messages vom Typ
-"Ich habe ein offenes Relay gefunden, check du es auch mal"
-"Ein offenes Relay wurde geschlossen, check du es auch mal"
Auf diese Weise werden offene Relays so schnell wie moeglich
weitergegeben, jede RBL verifiziert weiterhin nach den eigenen
Kriterien (und bleibt damit autonom) und gleichzeitig die "guten"
Admins belohnt, die offene Relays schliessen (indem sie nicht
manuell auf ein paar Dutzend RBLs jeweils darum betteln duerfen,
dass man sie austraegt).
Es steigert sicherlich auch die Akzeptanz von RBLs, da die Ergebnisse
eben von verschiedenen Stellen des Netzes zusammengetragen, gemeinsam
genutzt und ueberall nachvollziehbar werden. Und du musst nicht mehr
gegen ein Dutzend RBLs checken, sondern im duemmsten Fall nur noch
gegen eine oder zwei.
>>Auch ORDB listet daher nur inputs und keine outputs.
>>Der Schaden, den man mit output-Listings anrichten kann,
> Emm, die Listung(!) ist nicht gef?hrlich
> Gef?hrlich ist der unqualizierte Gebrauch der Listen!
Indirekt fordert orbz doch dazu auf, die outputs zu nehmen:
"Keep in mind that you may see relay spam coming from an ISP's
mail server. If we can discover the multi-stage relays, so
can spammers. However, for most users, the cost of using
outputs as well as inputs far outweighs the benefits."
(http://www.orbz.org/io.php).
Unqualifiziert? Ja. Aber dann koennte man genausogut auch auf
die inputs verzichten, schliesslich raet Orbz doch auch zur Nutzung ...
>>Ich habe letzt erst Korea-Spam bekommen, der angeblich von
>>einem .nl-Dialup zu yahoo, von dort per
>>asmtp zu hotmail, von dort aus dann ohne Received-Zeile zu GMX, die
>>das dann angeblich nach Korea geschickt haben.
> Sind sie nicht s?ss? ;-))
Die im Received stehenden IPs waren nicht einmal fuer den richtigen
Kontinent halbwegs richtig beschrieben (irgendein IP-Range eines
kleinen US-Providers fuer chello.nl? Das ist mal dynamisches
Dialup-Peering :-)), erst auf der letzten Received-Zeile Korea->MX
war das Zeug nachvollziehbar.
> Aber: Die Kiste war evtl. ein offener Proxy.
> Und: Wenn Du den .nl getestest h?ttest w?re der Test
> wohl nicht durchgegangen.
Inwiefern sollte ich den .nl testen? Nach dem angegebenen Hostnamen
war das angeblich ein Dialin bei chello.nl und selbst, wenn yahoo
das Ding angenommen hat, haette yahoo doch einen MX-Lookup gemacht
und direkt auf meinen MX zugestellt, statt per asmtp die Mail
an Hotmail weiterzustellen. Wer kaeme auch auf die Idee, dass Yahoo
zu Hotmail smtp-auth faehrt? Und selbst Hotmail haette doch sofort
einen MX-Delivery machen muessen. Stattdessen ist die Mail lt. Received
irgendwie auf die Rechner von GMX diffundiert, von wo aus sie nach Korea
geschickt wurden.
Meine Sysiphus.de liegt bei Schlund. Schlund hat ein Peering zu GMX.
Wenn GMX statt der billigen Peering-Leitung und wider der MX-Eintraege
es vorzieht, meine Mail ueber Korea zu routen, hat da doch irgendjemand
bei GMX ganz grossen Mist gebaut oder der Header ist einfach wilde Phantasie
eines Spammers.
>>Ich sehe aber auch keinen Grund, warum die fuer
>>relaytest.kundenserver.de sowie fuer spamblock.kundenserver.de
>>eingesetzte Software nicht auch auf die eigenen Smarthosts angesetzt
>>werden sollte und darueber Kunden-IPs temporaer sperrt, wenn
>>-es sich bei ihnen um offene Relays handelt oder
>>-der Sender mehr als x Mails pro Minute verschickt hat
> ACK.
> Das mit den "x Mails pro sekunde" knaste vergessen,
> da die Spammer die eMails auf viele relays verteilen
> damit es nicht auff?llt.
Wenn du Korea meinst: das sind in den meisten Faellen nicht
einmal offene Relays. Lt. Whoiseintraegen sind das dann irgendwelche
Schulen; IP pingt, aber Connections auf Port 25 werden refused.
Entweder ist da ein Profispammer mit gefakten Whois-Eintraegen
unterwegs oder da schafft es jemand, TCP-Verbindungen zentral
genug zu spoofen. In jedem Fall Grund genug fuer grosse Netblocks.
Spammer sind normalerweise dumm. Die versuchen ihre Mails so schnell
wie moeglich abzuwerfen. Wenn eine Kiste eine Mails mit einem
Bcc aus 100000 Zeilen akzeptiert, wird sie auch zum Spammen genutzt.
Und selbst, wenn sich jemand die Muehe macht: direkte MX-Deliveries
sind viel einfacher zu machen als nach offenen Relays zu suchen, die
dann jeweils eine Handvoll relayen sollen.
> Also: Das schimpfen auf "PFW" bringt nix, auch Fachleute
> sind manchmal mit ihren IDS-Logfiles ?berfordert.
Consultants sind keine Fachleute, sondern Ablass-Aussteller.
Wenn du fuer groessere Firmen irgendwelche Internetdienste erbringen
willst, bekommst du inzwischen oft erst einmal einen Wisch, auf dem
du unterzeichnen musst, dass z.B. alle aktuellen Securityfixes auf
deinen Rechnern eingespielt sind, das Root-Passwort nicht jedem in die
Hand gedrueckt wird und auch, dass deine Systeme regelmaessig von einer
externen Firma geauditet werden.
So, was macht die externe Firma? Portscans, einen Saint-Lauf und
danach wird alles rot markiert, was auch nur eine Debug-Ausgabe
ist. Auf jeder Puretec-Domain ist z.B. lt. Portscan Telnet offen.
Was meint freundlicher Consultant? "Telnet ist ein Sicherheitsrisiko".
Tatsaechlich kommt auf dem Port aber nur ein Riesen-Banner
"hier gibt es kein Telnet, nimm gefaelligst SSH".
Cool.
Ein Bekannter hat in seinem Musikstudium jahrelang Oboe gelernt und
danach mit am Tag zuvor ausgeliehenen Buechern der Stadtbuecherei
an der Volkshochschule Computerkurse gegeben.
Solange nicht eindeutig definiert ist, was ein Security Consultant alles
mindestens draufhaben muss, dieses "Minimum" auch von den Profis wirklich
akzeptiert wird und man die Consultants darauf verklagen kann, wirst du
solche Leute auch als Security Consultants finden.
>>Ganz ehrlich: wenn du als Kunde bei Puretec ueber auth.smtp.puretec.de
>>eine Mail verschickst und dich dann so ein "kundenserver.de"-Rechner
>>"per SMTP angreift", kommst du da sofort auf die Idee, dass es sich
>>dabei um eine redliche Sache handelt?
> Ein Frage der Pressearbeit.
Siehe oben: kundenserver.de=Verschleierung gegenueber Resellern.
Das kann man schlecht per Pressearbeit aufdecken, da einem sonst
die Reseller auf der Matte stehen :-)
> Benachrichtig Schlund eigentlich seine Kunden, wenn sie
> eMails f?r ihn abgelehnt haben?
Wahrscheinlich nicht. Sie rejecten aber auch nicht, sondern bauen
eben stattdessen diesen X-RBL-Warning-Header ein. Aber selbst bei
Rejects kann man diese noch RFC-konform konfigurieren (und z.B. Mail
an postm...@domain.tld durchlassen).
> Weil:
> Auch ein offenes relay kann legal genutzt werden!
> (ist sogar die Regel)
Lies noch einmal den Text hinter dem Link, der in der X-RBL-Warning
steht:
The mail you received has been sent via an unsecured relay host.
This means that the sending host can be easily abused for sending
anyone's mail and maybe it already has been abused for sending out
spam/UBE.
If you received usual (non-UBE) mail via such an host, please ask the
sender's server administrator to fix his mail server and close his
'open relay' configuration.
Detailed information on how to do this can be found at
http://mail-abuse.org/tsi/ar-fix.html.
Sprich: man fordert die Kunden auf, ueber die regulaeren Nutzer der
offenen Relays den Betreibern der Relays Druck zu machen, sobald sie ueber
diese Relays erwuenschte, regulaere Mail bekommen.
Das ist auch die einzig sinnvolle Argumentationsmoeglichkeit: nur vom
eigenen Kunden laesst sich ein ISP sagen, was er zu tun hat. Wenn sich
Schlund jede Woche per Cronjob bei den ISPs beschwert, landet die Mail
doch auf irgendeinem Supportdesk, der sie als "unwichtig" wegwirft oder
man ignoriert sie "habt ihr sonst keine Probleme".
Wenn sich aber die eigenen Kunden beschweren, sieht das anders aus.
Und wenn man erst einmal die grossen "erlaubten" offenen Relays dicht hat,
kann sich Schlund immer noch dazu entscheiden, die Nachrichten zu
rejecten. Der Absender bekommt dann eben sofort einen Bounce mit dem
Text, der sonst in der X-RBL-Warning steht und kann sich bei seinem
ISP dafuer bedanken.
>>Aber cool waere es schon, wenn man auch die einliefernden Kunden
>>testen wuerde.
> Naja, diese Diskussion gab es vor ca. 2a schon mal.
> Es wurde abgelehnt.
Schade.
>>Was sagst du aber gegen Spammer, die einfach versuchen, auf jedem
>>Host in deinem Netz ihren Spam zum Relaying einzuliefern? Fahre eine
>>noch nie verwendete IP hoch und warte einfach mal einen Tag
> Ein Tag? So lang?
Natuerlich kommt bereits nach zwei Minuten der erste Sprint-Dialin an,
ich rede von einer Tagesstatistik :-)
>>Fuer diese Aussage brauchst du doch nur eine Tabelle mit ip, letztem
>>Status und einem lastcheck-Datum. Wenn man sich anstrengt und fleissig
>>lockt, bekommt man die Informationen auch in einem DBM-File verwaltet.
> Ich mag diese Aussagen: "das sind doch nur 3 Zeilen Code" ;-)
Anscheinend ist es genau so einfach, sonst haette Schlund es doch
wohl nicht gemacht.
>>Wo ist das Problem?
> Das es mit den 3 Zeilen meist doch nicht getan ist...
Richtig, nun muss Schlund noch seine Kunden dazu bekommen, per smtp-auth
zu verschicken, sonst ist der ganze Krams fuer den Eimer.
Diese Woche ist aber Cebit und da wird sich doch kein Marketing-Fuzzi
darauf einlassen, gerade in der letzten Hochdruckphase der
Cebit-Vorbereitung etwas zu machen, was nicht als neues Feature
angepriesen werden koennte und nicht auf der Cebit herumzulungern.
Und smtp-auth ist erst einmal ein negativ-Feature ("warum soll ich
das aendern, schliesslich kann ich doch auch so Mail verschicken").
Also kommt sowas traditionell erst nach der Cebit.
>>Und wer ein offenes Relay hat, sollte sich ueber Test-Traffic nur
>>schwer beschweren koennen ...
> :-)
Ernsthaft. Es gibt offene Relays, die sooo platt sind, dass sie
eine Woche brauchen, um ihre Mails loszuwerden. Es gibt sogar offene Relays,
die sich mit "451 Disk space exhausted" verabschieden und daher auch
nicht mehr bei orbz gelistet werden :-)
> Der merkt beides nicht!
> Die Spammer nutzen die offenen relays oft nur f?r
> ein paar eMails und gehen dann weiter.
Naja, es kommt beides vor. In beiden Faellen duerfte der Betreiber aber
darueber froh sein, wenn er getestet und ueber das Testergebnis
informiert wird, bevor seine Kiste plattgezogen wird.
>>Daher muss man eigentlich auch die eigenen IP-Allocations von Tests
>>ausnehmen. Und wenn das ganze kompliziert wird, weil du dabei auch
>>noch wechselnde Kunden-IPs hast, kann man es eh' vergessen.
> Das war das was ich mit den "3 Zeilen Code" meinte..
> Solche Fallen stecken da noch mehr drin.
use Net::Netmask;
next if (findNetblock($ip,$myalloc));
Ok, um zwei Zeilen ueberboten :-)
>>Schlund spielt da mit erstaunlich offenen Karten, hilft mit einem
>>"stillen" Relaytester den Commons
>>und macht die Testergebnisse
>>komplett oeffentlich abruf- und verifizierbar. Wenn du ein offenes
>>Relay sofort retesten lassen moechtest, geht das ueber die View-Seite
>>und fuenf Minuten spaeter ist das Testergebnis fertig.
>>Das sollte man foerdern und nicht darauf herumhacken.
> Naja, ich dachte mehr an eine DNS-Zone...
Gerade der "stille" Teil ist doch praktisch (kein Relaytest-Blocker kann
sich mehr verstecken) und durch eine "oeffentlich bekannte" DNS-Zone
wuerde man genau das verhindern.
Wie gesagt: relays.bl.kundenserver.de ist oeffentlich querybar, solange
es keiner merkt und keinen stoert. Wenn der Server deswegen aber in
die Knie geht, wird sich das wohl aendern.
>>> ich f?rchte, das Verfahren scaliert nicht.
>>Warum nicht?
> Weil immer mehr Server andere Server testen.
Ok; wenn die RBLs es schaffen, sich untereinander abzustimmen und man
vielleicht sogar Testergebnisse shared, sind alle RBLs irgendwann mal
sinnvoll nutzbar und es stellt sich nicht mehr die Frage nach "wie viele
duerfen testen, damit man sinnvolle RBLs bekommt" und das ganze wird
sich von alleine einpendeln. Einen Relaytester zu unterhalten kostet
ja auch Geld und Traffic ...
Ansonsten bleibt eben noch "Scoring": in drei RBLs gelistet, also block.
Dafuer muesste man aber die MTAs erweitern oder einen Wrapper bauen, der
das beherrscht.
Wenn ersteres nicht funktioniert, ist ein Veroeffentlichen der Software
auch nicht sinnvoll, denn genau dann passiert das "jeder testet jeden".
Und das ist sinnfrei.
>>Die Datenbank enthaelt alle fuer dich relevanten Hosts und nicht mehr.
> Ja, "meine" Datenbank.
Eben darum "Data-Sharing" mit den Commons.
>>Mit den Relaytest-Blockern ist das auch so eine Sache
> Klar. Wenn der Relay-text von mout*.kundenserver.de k?me
> h?tten einige Admins ein herbes Problem...
> Insofern ist es (doch) wirklich sinnvoll, das soviele
> Hosts wie m?glich den Relay test machen.
Schau mal auf die IP der relaytest.kundenserver.de.
Und dann schau mal auf die IPs von der 212.227.126.156 an an bis auf
die .135 an runter: du siehst das halbe Schlund-Mailsystem. Wer darauf
einen Netzblock machen will, um nicht mehr als Relay gelistet zu werden,
schiesst sich damit ziemlich laut selbst in den Fuss :-)
>>Und das dann dumm zu blocken, duerfte fuer die offenen Relays ziemlich
>>fatal sein - schliesslich schneiden sie sich dann von ein paar
>>Millionen deutschen Internet-Usern ab, um ganz eindeutig Spammer zu
>>schuetzen.
> Naja, "deutschen"... spamcop hatte sogar gmx gelistet
> und orbd nahm nomierungen via gmx, web an...
> Woher sollen sie es auch wissen?
Dann lernen die "deutschen" ISPs schnell genug, dass man den Betreibern
dieser RBLs beibringen muss, was ausser AOL und hotmail noch "gross"
sein kann. Sogar Netcraft hat bemerkt, dass .de die meisten
Domainregistrierungen in ganz Europa hat und sich dort zwei Drittel des
Markts auf genau zwei Firmen verteilen. Wenn man als Betreiber einer RBL
solche Sachen ignoriert, muessen einem einfach die User abspringen.
Vielleicht baut auch mal jemand eine "good, bad and ugly"-Liste der
grossen RBLs. Osirusoft braucht lt. eigener FAQ eine Woche bis hin
zu einem Monat, um einen Rechner zu retesten. Es werden Netzblocks
ueber Netze verhaengt, die auch nur authentifizierende Mailsysteme
enthalten. Wohin ich sie einsortieren wuerde, ist mir schon klar ...
>>ob man das offene Relaying nicht gleich ganz
>>wegkonfiguriert, wenn man doch schon einmal die richtige Stelle im
>>Konfigfile gefunden hat.
>
> Nein, dann kommt der Gesch?ftf?hrer und sagt:
> "meine vertriebsmitarbeiter muessen von ?berall auf der
> Welt eMails einliefern k?nnen"
> Du: "SSL, SSH, VPN, smtp-auth..."
> Er: "Was ist das? Kostet das irgendwie Geld oder Zeit?
> Macht es die Benutzung/Konfiguration komplzierter?"
> Du: Ja
> Er: Dann vergessen Sie es.
> Du: Dann k?ndige ich.
> Er: Dann k?ndigen Sie ebend.
Wenn du als einziger Admin fuer den Support von Systemen verantwortlich bist,
ueber die du keine Konfig-Hoheit hast, laeuft ohnehin genuegend falsch
und du solltest eine Kuendigung schon zum Selbstschutz in Erwaegung
ziehen.
Die Vertriebler bekommen natuerlich vorkonfigurierte Notebooks in die
Hand und dort sind smtp-auth oder gleich ip/sec bereits fertig konfiguriert,
so dass der Vertriebler keinen Unterschied mehr sieht. Und wenn das
wegkonfiguriert werden kann, hast du deinen Job nicht gut genug gemacht
und der Vertriebler sich selbst zuzuschreiben, dass "was nicht mehr
geht".
Im Prinzip doch ganz einfach - man muss es nur durchsetzen. Und das geht
schnell genug, wenn du einfach alle neuen Notebooks genau so vorkonfigurierst
und die Vertriebler im Jahrestakt nach den neuen GHz-Prozessoren lechzen :-)
> Also bleibt die Kiste offen.
> Entweder von Dir offen gelassen, oder der n?chste
> Admin wird so ausgesucht das er sie offen l?sst,
> wenn nicht der GF selbst diesen trivialen Job macht.
Dann kommt der Buchhalter irgendwann mit der Traffic-Rechnung vorbei.
Im ersten Schritt wird "privates Surfen streng verboten". Im Folgemonat
stellt sich heraus, dass noch mehr Traffic angefallen ist. Dann wird
herausgesucht, wer denn da so viel Traffic zieht und es kommt heraus,
dass halb China ueber die Kiste spammt und die US-Spammer auch die Kiste fuer
sich entdeckt haben.
Und dann steht GF vor der Wahl: Relay dichtmachen oder massiv mit Hardware,
Netzanbindung und Geld werfen.
Wenn mal ein ISP mit vollen Errorlogs gemerkt hat, dass man mit nur wenig
Umkonfiguration dafuer sorgen kann, dass man Delivery-Errors nicht lokal
in die Queue laufenlassen muss, sondern diese auch auf eine
andere Kiste umleiten kann, werden offene Relays richtig lustig.
Damit koennte man dann doch auch die offenen China-Relays aergern:
wer der Meinung ist, dass eine "elektronische Visitenkarte" ueber offene
Relays vollkommen in Ordnung ist und man doch so gerne mit eigenen Ressourcen
andere Leute sponsort, verschicken wir eben alle Delivery-Errors ueber euch
und ihr duerft euch mit unseren Bounces herumaergern :-)
>>Any comments?
> Schon lange nicht mehr so einen konstruktiven Beitrag hier gelesen.
Mist. Jetzt muessen wir irgendwie das Niveau absenken.
Anders
--
http://sysiphus.de/
Marc Haber
>Wenn wir keinen Connect machen gehen die Schlund-Server auf
>unsere MXe.
Die Schlund-Server gehen _IMMER_ auf einen MX. Wenn einer da ist, wird
er benutzt. Bitte lerne die Grundlagen Deines Geschäfts oder drücke
Dich wenigstens ansatzweise korrekt aus.
>Dort musste die Connect-Sperre auch erstmal greifen!
Und? Ist das Dein Problem, wie Dein Fallback-MX konfiguriert ist?
Marc Haber
>Wenn unser Mailer das Zeug nicht abnimmt, also
>keine Verbindungen mehr zu lässt, dann geht der einleifernde
>Server auf unseren Fallback MX. Natürlich.
>Er muss ja glauben der Mailserver ist down, oder?
Ja und?
>Damit ist also NICHTS gewonnen, nein, es wird sogar noch
>schlimmer:
>Jetzt kommt das Zeug noch von den MXen rein.
Die Fallback-MXe werden nicht für jede Mail eine eigene Verbindung
aufmachen, sondern die Mails schön brav seriell - am besten noch unter
Recycling der SMTP-Verbindung - abliefern. Und damit hast Du Dein Ziel
erreicht. Du musst zwar jede Mail noch einzeln ablehnen, aber Du hast
keine so starke Lastspitze mehr.
>Wenn man keine Fallback MX hat oder einen eigenen, ist das natürlich
>ne Möglichkeit.
Und warum bitte ist es keine Möglichkeit, wenn man einen fremden
Fallback-MX hat? Der wird ja wohl von jemandem betrieben, der im
Gegensatz zu Dir Ahnung von der Materie hat.
>Nein, ich kann natürlich keinen Einfluss auf die Fallback-MXe nehmen.
Na und?
Marc Haber
>Dann hängt das Zeug auf den MXen, klasse.
>Und die dürfen dann auch so einen Schlund-Buster einbauen...
>kann irgendwie nicht sinn der Übung sein.
Die Konfiguration eines Mailservers behinhaltet immer, dass er so
eingestellt ist, nicht mehr Verbindungen anzunehmen als er in der Lage
ist zu verarbeiten. Bei manchen Mailservern kann man sogar einstellen,
dass ab einer bestimmten Last nur noch gequeued wird, die aufwendigen
Arbeiten also auf den nächsten queue run vertagt werden.
>(Für schlund schon. So haben andere die Kosten und die Arbeit
>sich von den DOA-attacken der Schlund-Systeme zu schützen,
>Schlund spart aber die Arbeit, seine cgi-scripte relayfest zu machen.).
Du redest hanebüchenen Schwachsinn.
>>Was meinst du, wie viele Bounces bei einer Million gehosteten Domains
>>pro Stunde auf diesem Account aufschlagen?
>
>Keine? Weil "normaleweise" eMails an die richtigen Addressen
>gehen, nur Spam nicht.
Mein Mailserver ist MX für rund tausend Domains, die meisten davon
Karteileichen. Bounces pro Tag? Etwa zweihundert. Nun rechne das bitte
mal hoch.
>Den Dreck via den CGI-Muellscripten (die wohl von Schlund
>seinen Kunden vorgegeben werden, oder wieso ist da immer derselbe
>Env From drin?) bezahlen ja die Kunden, deren scripte missbraucht wurden.
Envelope From wird vom Mailserver gesetzt. Egal, von wem das CGI
kommt. Du kennst Dich ja nicht nur mit Mailserver nicht aus, sondern
hast auch keine Ahnung von Webservern?
>>Rein technisch sind das alles "normale" Vorgänge,
>
>Tausende(!) (i.W. T A U S E N D E ) von Bounces "User Unknown"
>von EINEM System in wenigen Stunden an eine Addresse bezeichnest
>Du als "normalen" Vorgang?
Ja, das ist völlig normal. Ab einer bestimmten Grössenordnung.
>Die Telekom^W Bundespost hatte so einen Spammer vor den
>Kadi zerren können, der einfach an alle Telefon-Nummern via BTX
>eMails geschickt hat. Gekillt hatte das email-BTX gatway nicht der
>Spam, sondern die Fehlermeldungen! (Also "connect abzählen" hätte nix
>genutzt" Für 2 Tage.
Das war vor fünf Jahren.
>Sorry, da kann etwas nicht stimmen, das sich im Internet
>nur noch Grosskampfmachinen befinden dürfen, weil
>ein einzeler Herr meint, seinen Kunden keine relay festen
>Scripte zumuten zu dürfen.
Beweise, Watson, Beweise. Und nun hör mal auf zu geifern und fahr
endlich in Urlaub.
>Ne, logo. Sie verdienen ja auch an jeder relayten cgi-mail.
>Denn diese dem Eigner zuzuordenen wird sicherlich möglich sein.
Du weisst, wie Puretec-Domains abgerechnet werden? Welchen Teil von
"Pauschalpreis" hast Du nicht verstanden? Offene Relays machen Arbeit,
auch bei Schlund. Und da Mehrarbeit nicht mit Mehrumsatz verbunden
ist, will man die offenen Relays schliessen.
Das Problem ist, dass die Webdesigner sich mit ihrem Geschäft noch
weniger auskennen als Du Dich mit Mailservern.
>Es leiden nur andere Systemen darunter. sigh.
Andere Systeme leiden, wenn sie unsinnig konfiguriert sind.
>(Ich weiss nicht wieviele Leute bisher auch die Idee gekommen
>sind die Anzahl der Connects pro host zu reduzieren.
Das ist völlig üblich. Üblicher allerdings ist, die Anzahl der
Connects anhand der lokalen Load zu reduzieren. Ist die Load über
Schranke A, wird nicht mehr sofort verarbeitet, sondern nur in die
queue weggeschrieben. Ist die Load über Schranke B, werden keine neuen
SMTP-Connects angenommen. Ist die Load über Schranke C, werden
laufende queue runs abgebrochen. Und irgendwann normalisiert sich die
Lage wieder.
>Vorallem: Ich weiss auch nicht wie der Schlundserver reagiert,
>wenn er keinen MX einer Domain errechen kann.
>Ich habe Zweifel das er es 5 Tage lang versuchen wird,
>denn DAS kostet Schlund wieder -unnötig- Geld.
Das wird er. Warum sollte er nicht?
Marc Haber
>Nein, muss nicht. Nur wenn relaytest.kundenserver.de
>eMails annehmen kann (ja, Marc, das ist vereinfacht dargestellt
>und stimmt hier nicht ;-))
relaytest.kundenserver.de hat einen MX, nimmt also am Mailverkehr
teil. Ergo muss postmaster existieren. Das hat Schlund früher auch mal
anders gesehen, und weiss nicht, ob man es heute immer noch tut.
Marc Langer
> Envelope From wird vom Mailserver gesetzt. Egal, von wem das CGI
> kommt.
Und wenn das CGI ein "sendmail -f" macht?
Oder per SMTP einliefert?
Marc
Jens Wahnes
> Am Sun, 17 Mar 2002 08:09:32 +0100 schrieb Marc Haber:
>> Envelope From wird vom Mailserver gesetzt. Egal, von wem das CGI
>> kommt.
> Und wenn das CGI ein "sendmail -f" macht?
X-Authentication-Warning
> Oder per SMTP einliefert?
identd
Jens
michael hufnagl
Usenet...@zocki.toppoint.de (Rainer Zocholl) wrote in news:8KvH-
F06...@zocki.toppoint.de:
>>> Ich habe keine feste IP-Adresse, da ich weder einen Web- noch einen
>
>>freilich hat man gewoehlich eine dyn. IP. aber diese stammt immer aus
>>dem pool des zugangsproviders. es spricht nichts dagegen, wenn der
>>zugangsprovider seine smtp-server fuer diese IP-range ganz auf macht.
>>kein smtp-auth, kein smtp-after-pop3, kein pseudoschutz ala 'domain im
>>from'. wozu aus? der zugangsprovider kann sich jederzeit anhand der
>>uhrzeit und der IP den user greifen und gegebenenfalls verhauen.
>
> Klasse.
> Und wenn der liebe Kunde einen Offenen Proxy ("WinProxy" ist ja sooooo
> einfach zu installieren) installiert hat, oder mit Suse rumgespielt
> hat und ein offenes Relay gebaut hat, weil seine Leute im LAN
> auch mails verschicken sollten, geht der Spam erstmal stundenlang raus!
waere das mit smtp-auth anders? imho nein. ich betreibe ein offenes relay
und verwende fechmail inkl. smtp-auth fuer den connect zum smarthost. der
spam geht erstmal stundenlang raus.
sowas kannst du nur durch einen schnell reagrierenden abuse-desk
eindaemmen. smtp-auth ist imho nur deswegen wichtig, damit der betreiber
des servers grundsaetzlich die moeglichkeit hat seine schwarzen schafe zu
schlachten. wenn zugangsprovider = smtpserverprovider dann sollte es diese
moeglichkeit auch ohne smtp-auth geben.
> Klingt nicht unkritisch. (Für den Empfänger der Junk mails).
schlafendes abuse-team ist nie unkritisch...
cu
micha
Marc Langer
>> Und wenn das CGI ein "sendmail -f" macht?
>
> X-Authentication-Warning
Nur wenn der Webserver-User nicht als Trusted eingetragen ist.
>> Oder per SMTP einliefert?
>
> identd
Kann auch ausgeschaltet sein.
Marc
Marc Haber
>Am Sun, 17 Mar 2002 08:09:32 +0100 schrieb Marc Haber:
>> Envelope From wird vom Mailserver gesetzt. Egal, von wem das CGI
>> kommt.
>
>Und wenn das CGI ein "sendmail -f" macht?
Dann muss - bei exim - der User, unter dem der Webserver läuft, in
"trusted users" stehen.
>Oder per SMTP einliefert?
Dann muss der lokale Host relayen dürfen.
Andreas Ferber
>>verkraftest, wenn Schlund aus allen Rohren gleichzeitig lospustet)
>>Connections gleichzeitig zu, fertig. Wo ist das Problem?
> Das die Schlund-Server das nicht weiter stört:
> Sie sehen: aha MX A reagiert nicht, aber wir haben da
> ja noch den Fallback MX B oder den MX C.
> Dann hängt das Zeug auf den MXen, klasse.
Na und? Die nehmen auch n Connections an und machen dann dicht. Wenn
alle durch sind, fängt Schlund an, die Mails bei sich zu queuen, und
liefert sie dann später schön brav eine nach der anderen bei dir ab.
> Und die dürfen dann auch so einen Schlund-Buster einbauen...
> kann irgendwie nicht sinn der Übung sein.
Wieso "Schlund-Buster"? Dafür zu sorgen, daß man nicht mehr Verbindungen
gleichzeitig annimmt als man verkraften kann, gehört zu den elementaren
Grundvoraussetzungen. Ansonsten kann /jeder/ dir mal eben im
Vorbeigehen deinen Mailserver abschiessen, dazu braucht es kein Schlund
mit zig Servern.
> (Für schlund schon. So haben andere die Kosten und die Arbeit
> sich von den DOA-attacken der Schlund-Systeme zu schützen,
> Schlund spart aber die Arbeit, seine cgi-scripte relayfest zu machen.).
Wieso "seine cgi-scripte"? Das sind Scripte von /Kunden/. Du glaubst
doch nicht ernsthaft, daß die bei einer Million gehosteten Domains jedes
popelige kleine CGI-Script, das ein Kunde aufspielen möchte, auditen
könnten, selbst wenn sie wollten.
Zur Kundeninformation könnten sie vielleicht etwas mehr machen (die
wenigsten werden absichtlich verwundbare CGIs aufspielen), das wars aber
schon.
> Heisst Du im RL evtl. "Rainer Schlund"? ;-)
> Der schrieb auch immer so seltsame absurde Sachen,
> um sich zu rechtfertigen ala "Wir dürfen die emails unserer
> Kunden nicht öffenen". Ja, das hatte auch keiner gefordert.
Nein, aber ich kenne die Probleme, mit denen man als Hostingprovider
konfrontiert ist, zur genüge selbst. Zwar in sehr deutlich kleinerem
Masstab, aber davon kann man extrapolieren.
> Dazu gibt es perl oder andere nette Programmiersprachen, die
> GENAU dazu gedacht waren, aus der Notwendigkeit entwickelt wurden
> "unhandliche" Logfiles zu analysieren.
Bis heute hat es aber auch mit Perl noch keiner geschafft, eine KI zu
bauen.
Nimm die Zahl von Marc (bei mir sieht es ähnlich aus, was das Verhältnis
Domains zu Bounces angeht) und rechne das hoch. Macht mehr als 200.000
Bounces /am Tag/. 5.000 Bounces mehr oder weniger fallen da wirklich
nicht auf.
> Aber klar: Das kostet Schlund Geld. Und die werden
> sicherlich keine ManPower investieren, um weniger Umsatz zu produzieren:
> Den Dreck via den CGI-Muellscripten (die wohl von Schlund
> seinen Kunden vorgegeben werden,
Wär mir neu, zumindest in den "gehobeneren" Paketen sind AFAIK auch
eigene CGIs enthalten.
> oder wieso ist da immer derselbe
> Env From drin?)
Weil das der User ist, unter dem der Webserver und die CGIs laufen?
> bezahlen ja die Kunden, deren scripte missbraucht wurden.
man Pauschalpreis
>>Rein technisch sind das alles "normale" Vorgänge,
> Tausende(!) (i.W. T A U S E N D E ) von Bounces "User Unknown"
> von EINEM System in wenigen Stunden an eine Addresse bezeichnest
> Du als "normalen" Vorgang?
Ja, bei einem System dieser Grösse, über das Kunden ihre Mails
verschicken, /ist/ das normal. Du müsstest mal die postmaster-Mailbox
hier sehen, dann würdest du deine Meinung wahrscheinlich auch ändern.
Berücksichtige auch, daß es für irgendein etwaiges automatisches
Überwachungssystem keine Möglichkeit gibt, deine Site von z.B. AOL zu
unterscheiden. Ich möchte wetten, daß bei Schlund jeden Tag "User
Unknown"-Bounces von AOL in vier- bis fünfstelliger Anzahl aufschlagen.
> Andere Leute bezeichnen das als DialOfService.
Wenn die Auslieferungsversuche von Schlund bei dir Probleme bereiten,
dann musst du dich zuerstmal an die eigene Nase fassen. /Du/ bist
derjenige, der ihnen überhaupt erst die Möglichkeit geboten hat, dich zu
DoSen.
> Die Telekom^W Bundespost hatte so einen Spammer vor den
> Kadi zerren können, der einfach an alle Telefon-Nummern via BTX
> eMails geschickt hat. Gekillt hatte das email-BTX gatway nicht der
> Spam, sondern die Fehlermeldungen! (Also "connect abzählen" hätte nix
> genutzt" Für 2 Tage.
Die Post hat den /Spammer/ verklagt. Schlund tut in deinem Szenario aber
nichts weiter, als sich nach den einschlägigen Standards zu richten.
Das Verhalten der Schlund-Server ist unhöflich, darin stimmen wir
überein. Aber unhöfliches Verhalten ist nicht verboten, und strafbar
schon garnicht.
> Sorry, da kann etwas nicht stimmen, das sich im Internet
> nur noch Grosskampfmachinen befinden dürfen, weil
> ein einzeler Herr meint, seinen Kunden keine relay festen
> Scripte zumuten zu dürfen.
Das Spielchen läuft so: Schlund schickt dir eine höfliche Anfrage (SYN),
ob sie mit dir momentan gerade in Verbindung treten dürfen. Wenn du
darauf mit einem "Nur zu" (SYN ACK) antwortest, obwohl du überlastet
bist, dann hast /du/ etwas flasch gemacht.
> Und wenn man will, das der Konkurrent sein Angebot nicht
> einliefern kann, benutzt man kurz und kostenlos(!) die
> Infrastruktur von Schlund für eine DOS Attacke.
"Ich will meine Haustür aber nicht abschliessen, sollen doch die
Stadtwerke dafür sorgen, daß kein Einbrecher mehr mit der Strassenbahn
in mein Viertel fahren kann"
> (Ich weiss nicht wieviele Leute bisher auch die Idee gekommen
> sind die Anzahl der Connects pro host zu reduzieren.
> Vorallem: Ich weiss auch nicht wie der Schlundserver reagiert,
> wenn er keinen MX einer Domain errechen kann.
> Ich habe Zweifel das er es 5 Tage lang versuchen wird,
Die Mails nach einem einzigen Versuch wegzuwerfen kann sich nichtmal
Schlund leisten. Spätestens nachdem die MXe von GMX, T-Online oder AOL
mal kurz nicht erreichbar waren (was durchaus vorkommt), würden denen
die Kunden die Hölle heissmachen.
> Denn: Es sind ja nicht nur Junk mails die von Schlund kommen.
> Ein blocken auf IP-Ebene würde aber auch legale eMails unterbinden!
Mit dem mehrfach vorgeschlagenen Connection-Limit hast du das Problem
aber nicht. Die Mailauslieferung wird serialisiert und damit der Load
auf deinem Server reduziert. Legitime Mails werden evtl. ein wenig
verzögert, wenn sie mitten zwischen den Junkmails in der Queue hängen,
verloren gehen sie deswegen aber nicht.
Rainer Zocholl
>* Rainer Zocholl <Usenet...@zocki.toppoint.de> schrieb:
>Wieso "seine cgi-scripte"? Das sind Scripte von /Kunden/. Du glaubst
>doch nicht ernsthaft, daß die bei einer Million gehosteten Domains
>jedes popelige kleine CGI-Script, das ein Kunde aufspielen möchte,
>auditen könnten, selbst wenn sie wollten.
Ich war -anscheinend irrtümlich- davon ausgegangen das Schlund,
um ebend dies zu vermeiden, gewisse scripte vorschreibt/gewisse Operationen
verbietet. Ich hätte wirklich nicht gedacht das Schlund seinen Kunden
volle Narrenfreiheit gewährt, aber die die cgi-bounces dann
selbst einsammelt.
>Zur Kundeninformation könnten sie vielleicht etwas mehr machen (die
>wenigsten werden absichtlich verwundbare CGIs aufspielen), das wars
>aber schon.
>> Dazu gibt es perl oder andere nette Programmiersprachen, die
>> GENAU dazu gedacht waren, aus der Notwendigkeit entwickelt wurden
>> "unhandliche" Logfiles zu analysieren.
>Bis heute hat es aber auch mit Perl noch keiner geschafft, eine KI zu
>bauen.
Das ist kein "KI", das ist simple Statistik das Datenvolumen
zu reduzieren. Natürlich ist mehr als eine Halbtagskraft nötig
um die Logfiles von 5Mio sites zu kontrollieren.
Das sollte aber bei den Millioen einnahmen eigentlich drin sein, oder?
Aber, spätestens wenn es von aussen Beschwerden gibt, sollte/kann
man zumindest von sich hören lassen, oder?
Klar, wenn "abuse" auch auf /dev/null landet,
weil ja eh soooo viele user soooo viele Beschwerden auslösen,
die man ja eh garnicht berarbeiten könnte, ist das zuviel verlangt.
>Nimm die Zahl von Marc (bei mir sieht es ähnlich aus, was das
>Verhältnis Domains zu Bounces angeht) und rechne das hoch. Macht mehr
>als 200.000 Bounces /am Tag/. 5.000 Bounces mehr oder weniger fallen
>da wirklich nicht auf.
Das heisst also: Man muss nur genug Domains hosten und schon
braucht man sich nicht mehr zu kümmern, braucht keine
Sorge mehr zu tragen, wie man denn der Logfileflut her
werden kann?
Sorry, das kann's wohl wirklich nicht sein.
>> oder wieso ist da immer derselbe Env From drin?)
>Weil das der User ist, unter dem der Webserver und die CGIs laufen?
Emm, das ist "cgi-maile...@kundenserver.de" ?
Klingt irgendwie nicht so.
Und: Warum steht da nicht die Addresse des Script-Inhabers?
Würde doch irgendwie mehr Sinn machen, diesen zu informieren,
das "sein" feedback-formular an andere geschickt werden sollte?
>> bezahlen ja die Kunden, deren scripte missbraucht wurden.
>man Pauschalpreis
man trafficlimits/staffelung.
>Ja, bei einem System dieser Grösse, über das Kunden ihre Mails
>verschicken, /ist/ das normal.
Ist es "normal" das man die Logfiles nicht mehr auswertet?
Das man dDoS-attacken fahren kann?
>Du müsstest mal die postmaster-Mailbox
>hier sehen, dann würdest du deine Meinung wahrscheinlich auch ändern.
Ich sehe unsere. Ich wäre froh wenn es nur 200 bonces protag
wären. Aber wir haben scripte die die Datenflut auf ein massreduzieren,
das man mit einem Blick sehen kann: Da stimmt was nicht.
Aber dsa geht natürlich nur, wenn man die Fehlermeldungen auswertet
und nicht nach /dev/null schickt, weil es ja sooooooo viele sind.
>Berücksichtige auch, daß es für irgendein etwaiges automatisches
>Überwachungssystem keine Möglichkeit gibt, deine Site von z.B. AOL zu
>unterscheiden.
Das sie nicht "AOL" heisst?
Man könnte ja einfach einen Quotienten bilden: Bounce mail zu
zugegestellter mail, dann geht das fast automagisch.
Aber das mus man nachtürlich machen wollen, weil das kostet Geld
udn Rechnenzeit. /dev/null ist billiger, selbst wenn man es
vordem löschen noch zippt.
>Ich möchte wetten, daß bei Schlund jeden Tag "User
>Unknown"-Bounces von AOL in vier- bis fünfstelliger Anzahl
>aufschlagen.
Aber es werden auch entsprechend viele emails
nicht gebounct.
>Die Post hat den /Spammer/ verklagt. Schlund tut in deinem Szenario
>aber nichts weiter, als sich nach den einschlägigen Standards zu
>richten.
Offene cgi-relay sind Standard?
In welchen RfC?
Wie gesagt: das Argument mit der "Anzahl" *kann* nicht zählen.
>Das Verhalten der Schlund-Server ist unhöflich, darin stimmen wir
>überein. Aber unhöfliches Verhalten ist nicht verboten, und strafbar
>schon garnicht.
Das Verhalten ist ja nachvoll ziehbar, nur die URSACHE
nicht.
>> Sorry, da kann etwas nicht stimmen, das sich im Internet
>> nur noch Grosskampfmachinen befinden dürfen, weil
>> ein einzeler Herr meint, seinen Kunden keine relay festen
>> Scripte zumuten zu dürfen.
>Das Spielchen läuft so: Schlund schickt dir eine höfliche Anfrage
>(SYN), ob sie mit dir momentan gerade in Verbindung treten dürfen.
>Wenn du darauf mit einem "Nur zu" (SYN ACK) antwortest, obwohl du
>überlastet bist, dann hast /du/ etwas flasch gemacht.
Wenn ich die Antwort nicht scchicke sagt Schlund:
Nun denn gut, frage ich beim nächsten MX an.
Und das möchte ich vermeiden, weil ich den MX den ganzen Dreck
nicht zumuten will.
>> Und wenn man will, das der Konkurrent sein Angebot nicht
>> einliefern kann, benutzt man kurz und kostenlos(!) die
>> Infrastruktur von Schlund für eine DOS Attacke.
>"Ich will meine Haustür aber nicht abschliessen, sollen doch die
>Stadtwerke dafür sorgen, daß kein Einbrecher mehr mit der Strassenbahn
>in mein Viertel fahren kann"
Eher "Ich baue mir ne Alarmanlage ein, so das nur bei meine Nachbarn
eingebrochen werden kann".
Das ist aber ebend nicht meine Art. (Was hier auf völliges
Unverständnis zu stossen scheint, das jemand "Rücksicht auf andere"
nehmen will)
>> Denn: Es sind ja nicht nur Junk mails die von Schlund kommen.
>> Ein blocken auf IP-Ebene würde aber auch legale eMails unterbinden!
>Mit dem mehrfach vorgeschlagenen Connection-Limit hast du das Problem
>aber nicht. Die Mailauslieferung wird serialisiert
Wenn schlund nicht sofort auf den MX geht:
ACK, wäre eine wunderbar einfache, unkomplizierte Lösung.
Nur:
Wäre ich schlund, würde ich nach dem ersten Fehlconnect auf
den zweiten MX gehen (Und da evtl. erstmal bleiben). Warum auch nicht?
>und damit der Load auf deinem Server reduziert.
Ja, aber auf dem FB-MX erhöht.
Jens Wahnes
Es ging doch darum, daß der Mailserver feststellen kann, daß die Mail
von einem CGI ausgeht. Wenn der Serverbetreiber das will, ist das
jedenfalls möglich; wenn es ihn nicht interessiert, lässt er es halt
bleiben.
Jens
Sebastian Niehaus
[...]
> >Das Spielchen läuft so: Schlund schickt dir eine höfliche Anfrage
> >(SYN), ob sie mit dir momentan gerade in Verbindung treten dürfen.
> >Wenn du darauf mit einem "Nur zu" (SYN ACK) antwortest, obwohl du
> >überlastet bist, dann hast /du/ etwas flasch gemacht.
>
> Wenn ich die Antwort nicht scchicke sagt Schlund: Nun denn gut,
> frage ich beim nächsten MX an.
Das ist wohl vermutlich dessen Sinn.
> Und das möchte ich vermeiden, weil ich den MX den ganzen Dreck nicht
> zumuten will.
Dann nimm' ihn nicht als MX. Oder konfigurier' ihn gescheit. Oder
lass' das machen. Zur Abwechslung auch mal von jemandem, der die
Folgen von dem, was er tut abschätzen kann.
> Eher "Ich baue mir ne Alarmanlage ein, so das nur bei meine Nachbarn
> eingebrochen werden kann".
"Nicht alles, was Hinkt, ist ein Vergleich"
Wenn Du die Leute als MX einträgst, werden sie vermutlich auch Arbeit
davon bekommen.
> Das ist aber ebend nicht meine Art. (Was hier auf völliges
> Unverständnis zu stossen scheint, das jemand "Rücksicht auf andere"
> nehmen will)
Abgesehen davon, daß wir nun alle wissen, was für ein Gutmensch Du
bist: Ein erster Schritt der Rücksichtnahme wäre die Änderung Deines
MX-Eintrages im DNS.
[...]
> >Mit dem mehrfach vorgeschlagenen Connection-Limit hast du das
> >Problem aber nicht. Die Mailauslieferung wird serialisiert
>
> Wenn schlund nicht sofort auf den MX geht: ACK, wäre eine wunderbar
> einfache, unkomplizierte Lösung. Nur: Wäre ich schlund, würde ich
> nach dem ersten Fehlconnect auf den zweiten MX gehen (Und da
> evtl. erstmal bleiben).
Dann solltest Du Deinem vielfach zitiertem Rainer Schlund eine
Großpackung Filzpantoffeln spendieren, damit er beim Gehen nicht so
häßliche Kratzer auf den Rechnergehäusen der Dir ohnehin nicht
gehörenden Rechner hinterlässt.
Wenn sich dann untenrum alles warm und weich anfühlt, kannst Du 'mal
darüber nachdenken, ob nicht genau diese Verhalten so gedacht ist.
Das absolute Bonuspack wäre natürlich eine Kiste, die erstmal die Mail
entgegennimmt und sie dann weiterverarbeitet (und an Deinen jetzigen
Rechner weiterleitet), wenn die Welle etwas abgeflaut ist.
> Warum auch nicht?
Eben.
So allmählich wird das aber alles ein wenig langweilig, ich habe den
Verdacht, daß hier mehrfach von verschiedenen Seiten alles gesagt
wurde, was es zu sagen gibt. Im Falle von neuen Gesichtspunkten 'kann
man ja mal' die Sache erneut aufwärmen.
Crosspost & Followup-To: de.comm.software.mailserver
Sebastian
Michael Schierl
>Nimm doch einfach den Relayserver deines Einwahlproviders.
>Dein Einwahlprovider kann anhand der IP eindeutig "der darf relayen"
>feststellen und hat damit das einfachste wie sicherste Mittel, um
>eindeutig Relaykontrolle zu betreiben. Abgesehen davon sind auch die Wege
>zum Smarthost deines Einwahlproviders kuerzer als zu jedem anderen Host ...
>Selbst die grossen Callbycall-Anbieter bieten einem einen Smarthost an,
>lediglich ein paar Billigheimer verweisen stattdessen gerne auf
>oeffentliche Newsserver (statt einem eigenen) oder irgendwelche offenen
>Relays (statt einem eigenen, sicherem Relay). Und solche Schmarotzer-ISPs
>wirst du doch nicht ernsthaft foerdern wollen?
Nee, will ich nicht fördern. Meine CbC-Provider (je nach Tageszeit und
"Überlastung"):
Talknet (solange es das noch gibt, mail.talknet.de)
Compuserve (mail.compuserve.de)
Arcor (bin ich erst seit 2 Wochen, Mailserver noch nicht gesucht)
Freenet (dito)
Ud du glaubst ernsthaft, der "defekte" MUA, der keine SMTP-AUTH
hinbekommt, kann über 4 verschiedenen Mailserver mailen (autodetected,
oder alle durchprobieren)? (Ich weiß oft, wenn ich eine Mail schreibe,
noch nicht, wann ich das nächste mal online gehe - wenn die Mail nicht
so wichtig ist; Genauso wie ich dieses Posting um 17:08 verfasse und
noch nicht weiß, wann ich es sende.) Oder soll ich dafür Zusatztools
verwenden? Da ist es wohl noch einfacher, Mail outgoing über den
Hamster mit SMTP-AUTH laufen zu lassen. (Incoming kann ich sie ja
weiterhin direkt abholen).
Aber wie gesagt, ich benutze GMX und WEB.DE mit SMTP-AUTH, und mich
stört das nicht, ab und zu mein Passwort einzugeben.
Micha '15-30h/Monat online' el
Marc Langer
>>> identd
>> Kann auch ausgeschaltet sein.
>
> Es ging doch darum, daß der Mailserver feststellen kann, daß die Mail
> von einem CGI ausgeht. Wenn der Serverbetreiber das will, ist das
> jedenfalls möglich; wenn es ihn nicht interessiert, lässt er es halt
> bleiben.
Am besten schreibt Marc wohl selbst, worum es ging, ich hatte ihn
so verstanden, dass er die Aussage "Envelope-From wird vom Script
gesetzt" als grundsätzlich falsch angesehen hat (und damit den
Vorwurf der Unkenntnis von Mail-/Webservern im Allgemeinen verbunden
hat).
Marc
Hanno Wagner
Am 16 Mar 2002 19:48:00 +0200 meinte Rainer Zocholl:
>>Se "man couriertcpd" bastian
>
> See man fallback MX
>
> Wenn wir keinen Connect machen gehen die Schlund-Server auf
> unsere MXe.
> Dort musste die Connect-Sperre auch erstmal greifen!
Ich wuerde empfehlen genau da Teergruben einzusetzen. Wuerde
vermutlich Eure Load sinken lassen.
> Es sind ja nicht nur die Server, sondern vorallem die
> offenen CGI-Scripte die Schlund nicht in den Griff bekommt!
Da gebe ich Dir recht. Strato hat das Gleiche Problem; was wir
gerade zusammen mit Strato versuchen einzudaemmen. Wir finden viele
potentielle zu missbrauchende Skripte, aber natuerlich erst wenns zu
spaet ist... aber wir haben Ideen wie wir das hinbiegen koennen.
Ciao, Hanno
--
Computer. Unendliche Rechenpower. Wir schreiben das Jahr 1997. Dies sind die
Abenteuer des Raumschiffs Usenet, das mit seiner gegen unendlich strebenden
Besatzung unterwegs ist, neuen Blödsinn zu verbreiten, rumzuflamen und News-
reader zu vermurksen. Das Usenet dringt dabei in Galaxien vor, die nie ein
Mensch zuvor gesehen hat. - (Thomas Köhler in de.alt.arnooo)
Marc Haber
>Ich war -anscheinend irrtümlich- davon ausgegangen das Schlund,
>um ebend dies zu vermeiden, gewisse scripte vorschreibt/gewisse Operationen
>verbietet. Ich hätte wirklich nicht gedacht das Schlund seinen Kunden
>volle Narrenfreiheit gewährt, aber die die cgi-bounces dann
>selbst einsammelt.
Wenn ein CGI den Absender nicht explizit setzt (was kaum ein
DAU-Script tut), _MUSS_ der Webserverbetreiber die Bounces selbst
einsammeln.
>Klar, wenn "abuse" auch auf /dev/null landet,
>weil ja eh soooo viele user soooo viele Beschwerden auslösen,
>die man ja eh garnicht berarbeiten könnte, ist das zuviel verlangt.
Hör endlich mit den Unterstellungen auf. Das ist ja eklig.
>Und: Warum steht da nicht die Addresse des Script-Inhabers?
Weil das das Script setzen müsste. Hast Du irgendwann schon einmal
einen Webserver aus der Nähe gesehen?
>>> bezahlen ja die Kunden, deren scripte missbraucht wurden.
>
>>man Pauschalpreis
>
>man trafficlimits/staffelung.
Bei den heutzutage üblichen Trafficlimits kommt es auf ein paar
Megabyte Mail gar nicht mehr an.
>>Ja, bei einem System dieser Grösse, über das Kunden ihre Mails
>>verschicken, /ist/ das normal.
>
>Ist es "normal" das man die Logfiles nicht mehr auswertet?
Ja.
>>Die Post hat den /Spammer/ verklagt. Schlund tut in deinem Szenario
>>aber nichts weiter, als sich nach den einschlägigen Standards zu
>>richten.
>
>Offene cgi-relay sind Standard?
Natürlich nicht. Andreas meint, dass Schlund sich beim Aufbau der
SMTP-Verbindungen genau an die Standards hält. Aber das willst Du ja
nicht verstehen.
>Und das möchte ich vermeiden, weil ich den MX den ganzen Dreck
>nicht zumuten will.
Dann trag sie aus. Dafür sind sie da.
Sascha Kimmel
"Marc Haber" <mh+use...@zugschlus.de> schrieb im Newsbeitrag
news:<a6vhhc$1p9q$1...@innferno.news.tiscali.de>...
> "Sascha Kimmel" <sendn...@tricos.biz> wrote:
> >Nein, geht nicht, da SMTP immer nur IP-basiert läuft, d.h. es gibt nicht
wie
> >bei HTTP 1.1 den "Host"-Header, der mitgesendet wird.
> >Wenn Du ein TELNET auf Port 25 eines Servers startest, löst das
> >TELNET-Programm die IP für die angegebene Domain auf. Es ist dem
> >angesprochenen SMTP-Server aber NICHT möglich zu wissen, WIE er
angesprochen
> >wurde, denn es gibt wie gesagt keinen "Host"-Header wie bei HTTP 1.1.
>
> Du könntest ohne weiteres für jede IP einen eigenen Prozess starten.
Virtual Hosting = 1 IP für mehrere Domains, damit nicht möglich.
Grüße
Sascha
Marc Haber
>Virtual Hosting = 1 IP für mehrere Domains, damit nicht möglich.
"virtual hosting" ist ein Marketingbegriff, und damit mindestens
dreimal belegt. In diesem Thread geht es aber eindeutig darum, dass
Rainer Schlund unterstellt, das angeblich auf einem einzigen Rechner
laufende Mailsystem so konfiguriert zu haben, dass es aussieht wie
mehrere unabhängige Rechner.
Rainer Zocholl
>Hallo,
>was soll das denn nettes?
>Kühne Mission im Sinne aller Internetnutzer
>oder irgendein Selbstzweck, der mir noch nicht bekannt geworden ist?
Vermutlich: Pures Marketing! (Das Schlund etwas "selbstlos" tut,
was sein Geld kostet, wäre ungewöhnlich.).
Die wollen vermutlich ihren Kunden zeigen das es viele offene Relays gibt
und sie selbst daher die ihren nicht zu schliessen brauchen.
Du siehst ja wie einige leichgläubige (und schwer begreifende) hier
plötzlich einen Lanze FÜR Schlund brechen. Insofern
hat sich die Aktion für Schlund schon gelohnt.
<XX>>Mar 12 15:44:34 sendmail[29935]: g2CEiY629935: ruleset=check_rcpt,
>arg1=<rel...@relaytest.kundenserver.de>,
>relay=relaytest.kundenserver.de [212.227.126.156], reject=550 5.7.1
><rel...@relaytest.kundenserver.de>... SMTP relay denied, authenticatevia POP/IMAP first
Vorallem:
Wie oft wollen die denn -ohne Veranlassung- testen?
Anscheinend min. täglich!
Oder testen die, weil von unserem System so viele eMails
kommen für "cgi-b...@kundenserver.de", weil deren Server
gerade von Spammer kostenlos für dDoS missbraucht werden
darf?
Sehr "witzig".
Die sollen mal lieber ihre eigenen Dreckschleudern
(offene Third party relays und offene formmail-scripte sind
nicht als "gottgegeben" hinzunehmen, EGAL wie gross ein Provider ist!!!)
dicht machen anstatt -sinnlos- andere zu testen und deren
log file voll zu muellen.
Nein, mich stört es nicht wenn ORBZ & Co einen relay test
macht.
Diese betreiben schliesslich auch selbst keine offenen Relays
und testen max. einmal pro Woche.