[Postfixbuch-users] T-Online whitelisten -- die Argumente

[Rico Koerner]

Am 23.09.2011 20:45, schrieb Igor Sverkos:
> Hallo,
> 
> Was ist, wenn ich Webhosting-Kunde bin? Ich weiß nicht wie vertraut ihr
> alle mit "shared hosting" seid, aber betrachten wir nur einmal ein
> einfaches LAMP-Hosting: Es braucht nicht viel um ein PHP-Skript zu
> schreiben, was via mail() eine Nachricht als
> "bill.gates at microsoft.invalid" an "steve.jobs at apple.invalid" sendet. Was
> passiert da? PHP ruft einen sendmail-Wrapper auf, welcher in der Regel
> die Mail bei localhost einliefert. Der lokale Mailserver kümmert sich
> dann um die Bearbeitung (das ist keine "Gefahr" die speziell von PHP
> ausgeht - bevor hier jemand meint gegen PHP schimpfen zu müssen).
> 
> Was wollt ihr gegen solche Nachrichten machen?

z.B. die Maileinlieferung auf diesem Wege nicht akzeptieren, auch hier
ist AUTH möglich. Sowas praktiziert HostEurope. Leider informiert(e) man
den Hostingkunden darauf nicht ausreichend. Ich hab damals mehrere Tage
gebraucht, bis herausgefunden hatte, wo es klemmte.
Für eine Anwendung, die man dahingehen nicht anpassen konnte, gab es
einen komplizierten Weg, das freizuschalten. Das schaft kaum ein Spammer.

> Selbst wenn der raussendende Mailserver weiß ob die Mail als
> microsoft.invalid gesendet werden darf - was im shared Hosting Bereich
> eher nicht der Fall sein dürfte - besteht das Problem: Diese Mail würde
> also evtl. zurück gehalten werden, aber wenn ein Absender gewählt wurde,
> für den der raussendende Mailserver auch verantwortlich ist...
> 
> Klärt mich auf: Was würdet ihr hier machen?

Der Absender allein reicht im obigen Fall nicht, ohne Auth nimmt es der
Mailserver erst gar nicht an.

> I: "Angebote? An wen senden sie die denn?
> K: "An meine Kunden...."
> I: "Wirklich ihre Kunden? Haben die solchen Mailings zugestimmt? Sie
>    wissen ja bestimmt, dass sie das nur dürfen, wenn..."
> K: "Na klar..."
> 
> ...ihr lasst euch sogar etwas unterzeichnen, wo er es noch einmal bestätigt.

das ist zwar theoretisch möglich, aber sicherlich nicht das aktuelle
Problem von T-Online. Als nicht ganz kleiner Provider steck ich solche
Kunden in ein eigenes Netz reduziere damit das Problem auf einen kleinen
Kreis.

> Wie will man sich dagegen schützen? Das kann einem kleinen Hoster mit
> einem Kunden passieren... oder eben T-Online mit Millionen von Kunden.

Beide können sich von solchen Kunden trennen oder ihm einen eigenen
(v)Server empfehlen, bei dem er das Problem selbst und allein spüren und
beheben darf. Seriöse Massenmailversender haben auch ein Interesse
daran, nicht auf der Blacklist zu landen.

Hab ich dem Kunden denn zugesagt 1000 Mails/min abzunehmen? Ich kann ihn
also drosseln. Den normalen Kunden stört das nicht, wenn das limitiert ist.

> Und um es noch zu erwähnen:
> In den Premium-Paketen der Telekom steckt dieses E-Mailpaket drinnen -
> manch einer mag es auch extra gebucht haben. U.a. ist da ein tolles
> Feature bei: Ein Relay-Host! Gegen 5€ im Monat kann ich bei der Telekom

Warum auch nicht, wenn die Spammer 5€ spenden, dürfen sie den Rest der
Welt belästigen. In dem Fall begibt sich die Telekom mindestens grob
fahrlässig, wenn nicht sogar vorsätzlich in die Störerhaftung.

Wenn ich als Betreiber eines ungesicherten WLANs anderen die Möglichkeit
verschaffe, Straftaten zu begehen, bin ich auch dran.
Dabei habe ich mich noch nicht mal daran bereichert. Es hilft mir nicht
mal, wenn ich davon keine Ahnung hab.

Die Telekom dagegen weiß von der Sicherheitslücke und verkauft sie sogar
noch.

> - Authentifizierung erfolgt über den Anschluss - beliebige Mails
> einwerfen und die Telekom stellt sie dann zu. Eine sehr nette Sache, die
> ich bspw. schon seit Jahren legitim nutze (es gab Zeiten, wo noch nicht
> jede Software die Mailbenachrichtigungen angeboten hat SMTP-Auth

Legitim - ist eine Frage des Blickwinkels. Es steht bestimmt auch
irgendwo geschrieben, daß ich das nicht mißbrauchen darf.

Zu diesen Zeiten gab es auch ein solches Spamaufkommen nicht (da wären
wir wieder beim Stand der Technik vor 10 Jahren)

> konnte). Manch einer wird sagen, "Ein gefährliches Features"... aber ich
> denke es ist nicht gefährlicher als reines SMTP-Auth über normale Accounts.

Doch, es ist gefährlicher, gar nichts zu tun als wenig zu tun.

Es gab mal eine Lösung POP-before-SMTP, nicht besonders sicher, aber
zumindest besser als nichts und wurde out-of-the-Box von allen
Mailclients unterstützt. Unverschlüsseltes SMTP-AUTH schützt wenigstens
vor Schadsoftware, die nicht in der Lage ist, den Netzwerktraffic
abzuhören, die bei POP-before-SMTP durchschlüpfen konnte.
Es geht nicht immer darum, es 100%ig abzusichern, aber jeder Schritt
hilft ein Stückchen weiter und man muß diese Schritte eben so mitgehen,
wie sich die Systeme entwickeln.


Gruß
Rico

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2308 bytes
Beschreibung: S/MIME Kryptografische Unterschrift
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20110923/a108fd21/attachment.p7s>