Hallo bobnoise, ein paar Kommentare von mir zu deinem Beitrag. Da du Profi bist, kann ich technisch schreiben: Zuerst: Was wirklich passiert Der ausgehende Verkehr über Port 25, welcher nicht an die bluewin.ch SMTP-Server gerichtet ist, wird auf einen SMTP-Proxy umgeleitet. Der kann kein ESMTP (ESMTP beinhaltet Zusätze zur SMTP, unter Anderem Authentisierung und das Arbeiten mit TLS). Das sollte er auch gar nicht können, weil das ziemlich heikel wäre, da hierbei u.A. sensible Daten wie Benutzernamen und Passwörter von anderen Systemen über ihn abgewickelt werden müssten und er somit zu einem Man-in-the-Middle würde. Wenn also kein ESMTP über Port 25 versucht wird, gibt der Proxy die Mails an den Spamfilter weiter, und was nicht als Spam erkannt wird geht unbehelligt raus. Wenn aber bspw. versucht wir, zu authentisieren, dann gibt der Proxy eine Fehlermeldung aus. Also kann hier von (Zitat) "vollständiger Blockade von Port 25" nicht die Rede sein, weder technisch, noch in der Wirkung. Verkehr über die anderen SMTP-Ports 587 (SUBMIT, Message Submission) und 465 (SSL) wird nicht an den Proxy umgeleitet und ist deshalb von der Massnahme nicht betroffen. Zur Fehlermeldung: Was daran, dass keine Authentisierung unterstützt würde, kryptisch sein soll, ist mir schleierhaft. Wenn das Mailprogramm versuchte, TLS zu verwenden, dann gibt der Mailclient ohne den Server eine Fehlermeldung aus, und daran kann die Swisscom nichts ändern. Manchmal funktioniert es nicht: Du meinst wahrscheinlich, nach dem Portwechsel. Es funktioniert dann nicht, wenn der verwendete SMTP-Server E-Mails nur auf Port 25 entgegen nimmt. SSL? Wer das Gerücht in Umlauf gesetzt hat, man müsste jetzt beim Verkehr über andere SMTP-Server als bluewin.ch SSL verwenden, weiss ich nicht. Mann kann jetzt in dieser Situation einfach nicht mehr Authentisierung oder TLS (selten, da relativ neu) über Port 25 abwickeln. Ein Server, welcher nach den aktuellen Standards konfiguriert ist, sollte das aber. Leider hinkt da die Praxis jedoch dem Standard (RFC 4409) hinterher. Nutzen Bei der Bekämpfung von Spam gibt es - wie bei der Bekämpfung von fast allem im realen Leben - keine endgültigen Lösungen. Aber diese scheint sehr erfolgreich zu sein und dürfte den Bot-Designern einiges an Kopfzerbrechen bereiten. Wenn sie, wie von dir angeregt, dazu übergehen würden, den Bot Mailbenutzernamen und -Passwort aus - sagen wir einmal Outlook - auszulesen und zu verwenden lassen, dann bliebe der Spam ganz einfach im ausgehenden Spamfilter des entgegen nehmenden Mailservers hängen oder würde aufgrund anderer anwendbarer Metriken bald als Botspam erkannt. Der - sich bis jetzt als Server ausgebende - Bot kann ja dann nicht mehr irgendeinen, von seinem Betreiber ausgewählten Zielserver verwenden, sondern muss den Server verwenden, wozu der Benutzername und das Passwort passen. Gegenüber der heutigen Praxis, dass der Provider des Anschlusses zuerst auf Reklamationen von Betreibern anderer Mailsysteme warten muss, um reagieren zu können und den spammenden Anschluss vom Netz zu trennen, der dann Monate später wieder eine kompromittierte Maschine im LAN hat, um das Spiel von vorne beginnen zu lassen, ist das schon ein beträchtlicher Vorteil. Gruss, Martin
Mehr anzeigen