[linux-l] Vermeidung von Spam-Bounces (was: Ich habe einen Wurm)

[Jan-Benedict Glaw]

On Thu, 2009-07-23 12:49:56 +0200, Volker Grabsch <vog at notjusthosting.com> wrote:
> 1. Dein Spam-Scanner arbeitet schnell.
> 
>     Dann lehnst du den Spam schon in der SMTP-Sitzung ab, spätestens
>     nach dem DATA-Part. Einige Leute glauben, man könne eine Mail nur
>     _vor_ dem DATA-Part ablehnen, doch das ist Humbug. [1]
> 
>     Wenn die E-Mail zu Unrecht als Spam erkannt wurde, weiß der
>     Mailserver des Absenders sofort bescheid. _Dieser_ erzeugt dann
>     einen korrekten Bounce, sodass der Absender sofort bescheid weiß
>     und entweder die E-Mail abändern kann oder sich auf anderem Wege
>     mit dem Empfänger in Verbindung setzen kann.

All das setzt eine sehr genaue Kenntnis davon voraus, was SPAM denn
eigentlich ist. Bei etlichen Mails kann man sicher schnell breiten
Konsens finden; bei anderen ist das nicht so.

> 2. Dein Spam-Scanner ist überlastet.
[...]
> 
>     Die Konsequenz ist, dass die E-Mail entgegen genommen werden,
>     die SMTP-Sitzung mit "250 OK" beendet wurde. Erst viele
>     Minuten später stellt sich heraus, dass es Spam war.
> 
>     Das ist dann aber _dein_ Problem. Den Absender kannst du nicht
>     informieren, weil du damit gleichzeitig die 100fache Menge
>     an Leuten mit Spam-Bounces belästigen würdest.
>     
>     Also musst du deinem Kunden einen Spam-Ordner einrichten, sodass
>     _dieser_ dort im Zweifelsfall suchen kann. Aber wer hat schon
>     die Muße, ständig den Spam-Ordner zu durchsuchen? Spam-Ordner

Ich zum Beispiel. Genaugenommen hab' ich drei SPAM-Stufen. "Ziemlich
sicherer SPAM", "möglicherweise SPAM" und "vermutlich Nutzlast." Das
funktioniert für mich sehr gut.

Würde ein Email-Provider Mail, die für eingeht, einfach so ablehnen,
ohne daß /ich/ dazu die exakten Regeln festlegen kann, wär' das für
mich klar der Wink, daß ich da sofort und ganz schnell weg will.

>     sind benutzerfeindlich. Letztendlich merkt es der Empfänger
>     erst, wenn ihn Absender auf anderem Wege kontaktiert und fragt,
>     ob die E-Mail angekommen sei.

Mumpitz.

>     Ich finde es erstaunlich, wie gut es GMX & Co. schaffen, ihren
>     Kunden dieses Manko als Feature zu verkaufen. :-/
> 
>     Ich musste schon etlichen Neukunden erklären, wieso wir einen
>     Spamfilter aber keinen Spam-Ordner haben. Auf meine Frage, ob
>     sie Leute beim alten Provider jemals ihren Spam-Ordner durchsucht
>     hätten, kam durchweg die Antwort "Nein".

Ich finde es, sagen wir, "beeindruckend", daß Ihr es sicher und über
jeden Zweifel erhaben schafft, SPAM von Nicht-SPAM zu unterscheiden.
Oder dabei ggf. in Kauf nehmt, daß legitime Sender auch mal 'ne Mail
nicht ausgeliefert bekommen.

>     Spam-Ordner bringen keine Vorteile. Es dauert einfach nur länger,
>     bis der Absender merkt, dass seine E-Mail nicht ankam.

Bei der papier'nen Schneckenpost weißt Du auch nicht, wann der
Empfänger mal draufschaut...

> Ich frage mich, ob ich zu diesem Thema mal eine Animation bauen
> sollte. Ich finde das so einfach und naheliegend, dennoch muss
> ich das ständig irgendwem erklären. Ist meine Sichtweise wirklich
> so abwegig?

Sie setzt zumindest voraus, daß

  (a) Konsens darüber besteht, was "SPAM" eigentlich ist oder daß
  (b) ihr es für akzeptabel haltet, auch mal 'ne legitime Email
      nicht anzunehmen.

Ich seh' in SMPT ein Protokoll, daß für den Email-Versand gemacht
wurde; auf meinem eigenen Mailserver möchte ich zumindest
sicherstellen, daß der lauschende Daemon dahinter auch genau diese
Aufgabe erledigt. Die SPAM-Erkennung ist etwas, das vom User abhängig
ist. Vielleicht mag er chinesischen Spam? Oder Pozenzpillen? Woher
soll der Provider das wissen? Und im Fall von SPAM'schen
Wackel-Kandidaten: Der Absender hat seine Arbeit getan. Nun soll der
Empfänger in Aktion treten.

Laß SMTP bitte sein, was es ist: Das Simple Mail Transfer Protokol.
Gesichtskontrolle war bisher glaub' ich nicht Bestandteil des
Protokolles.

> SPF ist lediglich ein nettes Kriterium, um Spams schon _vor_ dem
> DATA-Teil zu erkennen. Das ist aber nicht notwendig. Man kann Spams
> auch _nach_ dem DATA-Teil sauber ablehnen.

...aber bitte nur, wenn man sich wirklich exakt 100%ig sicher sein
kann, daß das so auch im Sinne des menschlichen Empfängers ist.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:           Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second  :               Langsam möchte ich mal wieder weiterträumen können.
                             -- Maximilian Wilhelm (18. Mai 2005, #lug-owl.de)
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20090723/01d1ea93/attachment.sig>