Spam und UCE - die Provider

Die Provider sind eine Kernkomponente bei der Übertragung von Spam, denn Sie stellen nicht nur uns als Empfänger dieser Nachrichten eine Internetanbindung zu Verfügung und werden dafür bezahlt. Es gibt auch immer einen Provider, der den Spammer bedient. Der Versender von Spam-Nachrichten benötigt ebenso einen Zugang. Damit steht der Provider zwischen allen Stühlen, denn er verdient zum einen an jedem übertragenen Byte. Die meisten Firmen bezahlen für ihre Leitung nach Volumen oder die Provider haben eine Mischkalkulation. Auf der anderen Seite kostet Sie auch das Transfervolumen von Spammern aus anderen Netzen über das Peering. Zuletzt ist auch die unklare und je Staat unterschiedliche Rechtslage ein Problem, als Provider zu filtern, zu blockieren oder andere Maßnahmen durchzusetzen. Trotzdem haben auch Provider ihren Anteil am Spam und könnten mit einfachen Hilfsmitteln einigen unfug verhindern.

Relay-Missbrauch und Mailprovider

Viele Provider bieten für ihre Kunden einen Mailserver an. Hierzu zählen Firme wie GMX.de, WEB.de und andere ebenso wie die Webhoster puretec.de, strato.de und andere. Alle bieten für ihre Kunden POP3 Konten an und die Möglichkeit, per SMTP über deren Server Mails zu senden. Damit stellt sich für diese Firmen natürlich auch die Frage, wie die Systeme nur den eigenen Kunden zur Verfügung stehen und nicht jedermann. Das Problem dieser Provider ist, dass Sie nicht steuern können, von wo ihre Kunden im Internet kommt und keine eigene TCP/IP-Einwahlstruktur anbieten. Daher sind "Erlaubt-Regeln" auf Basis von Subnetzen nicht möglich. Leider gibt es schlechte Beispiele, die einfach alles erlauben. Aber sehr schnell wird die korrigiert, da auch diese Provider nach "Volumen" ihre Anbindung bezahlen müssen. Ideal ist natürlich die Authentifizierung des Anwenders. Die kann auf zwei Wege passieren

  • SMTP after POP
    Holt ein Anwender per POP3 seine Mails ab, dann erlaubt der Provider für eine bestimmte Zeit von eben dieser IP-Adresse ein Relay. Das ist relativ sicher, auch wenn eine Lücke besteht, aber es erspart dem Anwender die Konfiguration einer SMTP-Anmeldung. Nicht jede Software kann das.
  • Authenticated SMTP
    Jeder SMTP-Sender sollte auch eine Authentifizierung unterstützen. Sofern dies möglich ist, kann der Mailserver nach der Anmeldung die Nachrichten erfolgreich annehmen und weiterleiten.

Exchange 2000 bietet nur die Authentifizierung an, so dass ein Provider mit Exchange 2000 als Backend auf "SMTP after POP" verzichten muss. Fraglich ist hierbei auch immer die "Sicherheit" des Kennworts.

Es ist auf jeden Fall im Interesse der Provider, einen Missbrauch per Relay zu verhindern. Einige Provider beschränken sich aber nicht darauf, Absenderadressen per RBL, ORDB und anderen zu überprüfen, sondern fahren sogar eigene Tests:

Im Mail 2002 ist mit aufgefallen, dass der Mailserver von "kundenserver.de" mich aktiv "geprobed" hat, nachdem ich eine Mail an ein Postfach auf diesem Server gesendet habe. Das Transkript war:

Incoming SMTP call from 212.227.126.156 at 17:29:42.
<<< 220 Firma  ESMTP Receiver 0 Ready
>>> HELO relaytest.kundenserver.de
<<< 250 OK
>>> MAIL FROM:<devnull@kundenserver.de>
<<< 250 devnull@kundenserver.de OK
>>> RCPT TO:<relayed@rcv-relaytest.kundenserver.de>
<<< 501 This system is not configured to relay mail from <devnull@
    kundenserver.de> to <relayed@rcv-relaytest.kundenserver.de> für 212.227.126.156
>>> QUIT
<<< 221 localhost closing
Incoming SMTP call from 212.227.126.156 aborted at 17:29:42.

Natürlich erfolglos, aber man sieht, dass auch hier sich etwas tut.

Dial-UP Sperrlisten

Wenn nun alle Einzelpersonen ihre Mails über den Mailserver des Providers nach einer Autorisierung versenden können, dann könnten die Provider zumindest von den Wählzugängen den direkten Durchgriff auf den SMTP-Port (25/TCP) blockieren. Alternativ könnten die Empfänger eine Liste dieser IP-Adressen (Dial up List, DUL) führen und die direkte Zusendung unterbinden.

Dem entgegen spricht, dass immer mehr Firmen auch ihren Mailserver über dynamische Adressen aus diesen Nummernbereichen zum Versand anbinden und einige Sender lieber direkt den Empfängerserver erreichen möchte. Nur so können Sie feststellen, dass die Mail wirklich eingeliefert wurde und nicht beim Relay des Providers in der Warteschlange liegt.

Der Einsatz von solchen Sperren auf dynamische Adressen bedeutet:

  • "normale" Einzelnutzer haben keinen Nachteil von solchen Sperrlisten.
    Sie nutzen sowieso immer einen Mailserver mit ihrem Outlook Express, Mozilla etc.
  • Anwender sind eher geschützt gegenüber, und haben damit Vorteile.
    Theoretisch könne ich einen Anwender, der eine Mail zu mir senden will, über diese Verbindung auch angreifen. Das passiert nicht, wenn der Anwender seine Mail bei dem ihm "vertrauten" Relay abliegert.
  • "ehrliche" Mailsender haben Standleitungen mit festen IP-Adressen und verbergen sich nicht hinter Wählzugängen. Das stimmt leider nicht global, aber ehrliche Absender können sich anders positiv qualifizieren, z.B.: per DDNS. Er Mails aus einem dynamischen Anschluss sendet, wird meist auch Mails empfangen wollen. So könnte man Systeme über z.B. MX-Einträge doch zulassen
  • Sender mit Wählzugang können und sollen den Mailrelay ihres Providers nutzen, welche Authentifizierung nutzen kann.
    Damit kann der Provider den Zugang nachverfolgen aber viel wichtiger ist, dass Sie als Sender die Daten mit maximaler Geschwindigkeit beim Relay des Providers ablegen können. Gerade beim Einsatz nach Zeit abgerechneten Verbindungen spart dies Geld.

Für den Zugang zum Internet bleiben daher dann drei Wege 

  • Billigst:
    Call-by-Call Dial-Up mit dynamischer IP-Adresse und Nutzung des SMTP-Smarthost des Providers (Privatanwender). Darunter fällt z.B. auch ein T-DSL-Anschluss und die Nutzung von Einzelpersonen.
  • Mittel:
    Dial-Up mit fester IP-Adresse über einen Firmenprovider (Kleine Firma) oder einer dynamischen Adresse mit zusätzliche Qualifizierung (SPF, MX, DDNS)
  • Profi:
    Standleitung mit fester IP-Adresse über einen Firmenprovider.

Jeder bekommt das, was er zu bezahlen bereit sind. Ich sehe den Schutzbedarf von Mailservern (speziell AOL, T-Online und andere) höher, als eine "Verzögerung" eines "Privatanwender".

Alle anderen sehe ich eher als unseriös an. Als Privatkunde sollte ich auf jeden Fall auf einem Smarthost meines Provider bestehen und auch diese Nutzen. Warum sollte mein PC direkt an einen entfernten Mailserver eine Nachrichte senden wollen, was je nach Belastung der Internetverbindungen ein Vielfaches (lange Online) dauert und damit auch Kosten verursacht.