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

[Volker Grabsch]

Jan-Benedict Glaw <jbglaw at lug-owl.de> schrieb:
> On Thu, 2009-07-23 12:49:56 +0200, Volker Grabsch <vog at notjusthosting.com> wrote:
> > 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.

Wie genau handhabst du diese drei Stufen? Was davon speicherst du,
was wird sofort verworfen, etc?

> 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.

Lass uns bitte sachlich bleiben. Wenn deine Aussage so krass zutreffen
würde, dann dürfte dein Provider nicht einmal RBLs einsetzen, weil die
ja von Leuten gepflegt werden, auf die du keinen Einfluss hast.

Und die gezielte Auswahl der derzeit guten RBLs, die will man doch
lieber einem erfahrenen Mailadmin anvertrauen, oder?

> >     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.

Auch hier: Bitte sachlich bleiben.

> >     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.

Auch hier: Bitte sachlich bleiben. Einen fehlerfreien Spamfilter
habe ich nicht vorausgesetzt.

> Oder dabei ggf. in Kauf nehmt, daß legitime Sender auch mal 'ne Mail
> nicht ausgeliefert bekommen.

Was ist denn die Alternative? Dass der Absender gar nicht merkt,
dass seine Mail als Spam klassifiziert wurde, und die Mail dann
im Spamordner des Empfängers untergeht und irgendwann automatisch
gelöscht wird? Dann dauert es viel länger, bis das Problem auffällt.
Was ist daran besser?

Wenn der Empfänger die E-Mail erwartet, wird er irgendwann stutzig
und wühlt im Spam-Ordner. Anderenfalls fällt das Problem womöglich
nie auf.

Ich finde es viel freundlicher, wenn mir als Absender sofort gesagt 
wird: Hey, deine E-Mail wurde als Spam klassifiziert. Oder: Hey,
deine IP-Adresse liegt auf RBL-soundso. Dann weiß ich, woran ich bin.

> > 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ß

Es gibt klare Definitionen von SPAM, oder besser gesagt UBE.
Aber das ist eigentlich nebensächlich, weil die Filter sowieso
nicht perfekt sind. So oder so: Falsche Positive gibt es immer.

>   (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?

Wer auf SPAM-E-Mails steht, der sollte nicht zu uns kommen.
Auf solche Kunden verzichten wir gerne, das stellt absolut kein
geschäftliches Problem dar. Leute, die Spammer finanzieren, sind
ohnehin nicht unsere Zielgruppe. Siehe auch:
http://www.spamdontbuyit.org/

Oder meinst du Leute, die irgendwo einen Newsletter abonniert
haben? Das ist natürlich etwas Anderes. Seriöse Newsletter (mit
Double-Opt-In) landen aber gar nicht auf Blacklisten und kommen
somit bei uns durch.

> Und im Fall von SPAM'schen
> Wackel-Kandidaten: Der Absender hat seine Arbeit getan. Nun soll der
> Empfänger in Aktion treten.

Jede E-Mail, die durchkommt, erhält trotzdem die üblichen X-Spam-*-
Header. Verworfen werden nur die krassen Fälle. Falsche Positive
kann man nie ausschließen, aber in diesem unwahrscheinlichen Fall
weiß der Absender dann sofort bescheid.

Eine weitere Filterung (wahrscheinlicher/unwahrscheinlicher Spam)
kann der User selbst vornehmen, entweder anhand der X-Spam-Header,
oder mit dem eigenen Junkfilter. Da machen wir keine Vorgaben.

Ich persönlich mache übrigens keine weitere Sortiernug. Die paar
Spams, die durchrutschen, kriege ich schnell per Hand entfernt
- manchmal sende ich auch eine entsprechende Beschwerde an den
Provider raus. Bei den Spams, die durchkommen, "lohnt" es sich ja.
Ob der Provider den Spamm rauswirft, ist natürlich ne andere Frage,
aber zumindest weiß er schonmal bescheid.

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

"Gesichtskontrolle" ist gängig.

*) Viele Mailserver überprüfen die Mails auf formale Korrektheit.
   Wenn krasse Verstöße gegen geltene Standards auftreten, dann
   wird eine Mail von den allermeisten Mailservern zurückgewiesen
   - obwohl auf SMTP-Ebene alles okay war.

*) RBLs greifen oft noch vor dem DATA-Part, d.h. Mails werden
   vor Kenntnisname des Inhalts verbannt, wenn sie von bekannten
   pathologischen Spamschleudern, offenen Proxies/Relays oder von
   nicht-authentifizierten dynamischen IP-Adressen kommen.

*) Je früher ein Spam-Kriterum im SMTP-Dialog greift, umso mehr
   Traffic und Rechenzeit spart es.

*) Wenn die Mailbox des Users voll ist, wird eine E-Mail abgewiesen.
   Mit entsprechender Fehlermeldung, versteht sich.

*) Die Uni, an der ich studiere, setzt viel stärkere Spamfilter ein
   als wir in der Firma. Die RBLs nicht vom Benutzer konfigurierbar
   (geht auch nicht, wenn sie der Senkung des Traffics dienen sollen):
   http://www.cms.hu-berlin.de/dl/kommunikation/email/SPAM

   Lediglich der nachfolgende Inhalts-Scan, den nur noch ein Bruchteil
   der E-Mail durchlaufen, ist konfigurierbar, zumindest in der Mathe-
   Fakultät:
   http://www.math.hu-berlin.de/~gehne/aktuelles.html#SpamFilter


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR