SMTP spam reduzieren

[Tom]

Hello,

um aus dem email-Header überhaupt noch eine verwertbare Information zu ziehen über den Absender-Daemon, welche Zeile bzw. Eintragung ist die wichtigste?

Return-Path: [e-mail]
Delivered-To: [e-mail]
Received: (qmail 21203 invoked by uid 89); 4 Apr 2007 19:21:58 -0000
Delivered-To: [e-mail]
Received: (qmail 21201 invoked by uid 89); 4 Apr 2007 19:21:58 -0000
Received: from eu99-101-175.clientes.euskaltel.es (HELO euskaltel.es) (62.99.101.175)
  by v005.my-vserver.net with SMTP; 4 Apr 2007 19:21:58 -0000
Date: Thu, 05 Apr 2007 05:10:32 +0900
Reply-To: "Eva Kopyra" [e-mail]
From: "Eva Kopyra" [e-mail]
MIME-Version: 1.0
To: [e-mail]
Subject: Geld verdienen - Tipp an
Content-Type: text/plain;
 charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ich w+ürde jetzt mal raten

Received: from eu99-101-175.clientes.euskaltel.es (HELO euskaltel.es) (62.99.101.175)

Wobei noch festzustellen wäre, ob die hinter HELO genannte Domain sich tatsächlich an der genannten IP befindet, oder frei erfunden ist.

Ist das richtig verstanden?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

um aus dem email-Header überhaupt noch eine verwertbare Information zu ziehen über den Absender-Daemon, welche Zeile bzw. Eintragung ist die wichtigste?

Ich w+ürde jetzt mal raten

Received: from eu99-101-175.clientes.euskaltel.es (HELO euskaltel.es) (62.99.101.175)

Der unterste Received-Header ist per Definition immer der des ursprünglichen Senders.
Alle weiteren MTAs, über die die Mail auf ihrem Weg zum Empfänger weitergeleitet wird, setzen ihre eigene Received-Zeile darüber.

"Per Definition" - weil dir natürlich auch in MTA in der Kette vorgaukeln könnte, die Mail sei vorher schon über X andere Stationen gegangen, bevor sie bei ihm eintrudelte.
Eine Verifizierung dieser Angaben ist im Protokoll nicht vorgesehen, auch vom technischen Ablauf her kaum möglich.

gruß,
wahsaga

[Tom]

Hello,

"Per Definition" - weil dir natürlich auch in MTA in der Kette vorgaukeln könnte, die Mail sei vorher schon über X andere Stationen gegangen, bevor sie bei ihm eintrudelte.
Eine Verifizierung dieser Angaben ist im Protokoll nicht vorgesehen, auch vom technischen Ablauf her kaum möglich.

Also müsste der letzte in der Kette noch die IP drinstehen haben, von der er abgesandt wurde? Oder muss ich dafür tatsächlich den SMPT-Server umprogrammieren?

Der letzte Eintrag ist doch dann von meinem eigenen angefertigt mit der Absender-IP... oder?

Und solange ich erkennen kann, dass die Weiterleitung intern passiert ist, kann ich zurückgehen?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

um aus dem email-Header überhaupt noch eine verwertbare Information zu ziehen über den Absender-Daemon, welche Zeile bzw. Eintragung ist die wichtigste?

Wie wahsaga erwähnte: Die Received-Zeilen geben im Grundsatz Auskunft.

Allerdings sind sie auch Bestandteil der eingelieferten Mail, also ist ihnen gegenüber eine kritische Würdigung angesagt. Wirklich vertrauenswürdig sind nur die Zeilen deines eigenen Mailservers, nichts darüber hinaus. Außer du kennst das einliefernde System und dein Mailserver bestätigt, dass es tatsächlich eingeliefert hat - dann kannst du auch diesen Zeilen noch vertrauen.

Da die Received-Zeilen immer oben an die Mail angehängt werden, stehen die vertrauenswürdigen Zeilen also immer zuoberst, und je weiter nach unten man sich durcharbeitet, desto vertrauensunwürdiger wird es - wie gesagt, eigentlich schon schlagartig nach der letzten Zeile des eigenen Mailservers.

Return-Path: [e-mail]
Delivered-To: [e-mail]
Received: (qmail 21203 invoked by uid 89); 4 Apr 2007 19:21:58 -0000
Delivered-To: [e-mail]
Received: (qmail 21201 invoked by uid 89); 4 Apr 2007 19:21:58 -0000
Received: from eu99-101-175.clientes.euskaltel.es (HELO euskaltel.es) (62.99.101.175)
  by v005.my-vserver.net with SMTP; 4 Apr 2007 19:21:58 -0000

Dieser Teil ist von deinem Mailserver. Der Rest ist durch den Spammer vorgegeben worden:

Date: Thu, 05 Apr 2007 05:10:32 +0900
Reply-To: "Eva Kopyra" [e-mail]
From: "Eva Kopyra" [e-mail]

Wobei noch festzustellen wäre, ob die hinter HELO genannte Domain sich tatsächlich an der genannten IP befindet, oder frei erfunden ist.

Das angegebene HELO ist "bogus". Ein vernünftiger Mailserver würde sich niemals mit "HELO example.com" melden, wenn er der Mailserver für @example.com ist, sondern seinen eigenen FQDN nutzen, also beispielsweise "HELO mail.example.com".

Allerdings ist das so eine Sache, auf dieses Kriterium zu filtern. Ein FQDN im HELO muß sein, Dinge wie "HELO localhost" oder "HELO friend" sollte man scheitern lassen. Auch IP-Adressen haben im HELO nichts verloren. Der FQDN sollte im DNS auffindbar sein. Und selbstverständlich hat die eigene Domain bei reinkommenden Mails von fremden Servern nicht verwendet zu werden. Insgesamt kann man mit guter HELO-Filterung schon mal sehr gute Ergebnisse erzielen. Auf selfhtml.org filtere ich damit allein schon über 60% (34.000 von 56.000 im vergangenen Monat) aller insgesamt abgelehnten Mails raus (der Check ist der allererste in der Kette).

Insgesamt hätte es deine Mail vermutlich über meinen HELO-Filter geschafft. Aber meine Filterkette ist ja noch etwas länger. :)

- Sven Rautenberg

[Tom]

Hello Sven,
hello wahsaga,

Received: from eu99-101-175.clientes.euskaltel.es (HELO euskaltel.es) (62.99.101.175)
  by v005.my-vserver.net with SMTP; 4 Apr 2007 19:21:58 -0000

[...] Insgesamt kann man mit guter HELO-Filterung schon mal sehr gute Ergebnisse erzielen. Auf selfhtml.org filtere ich damit allein schon über 60% (34.000 von 56.000 im vergangenen Monat) aller insgesamt abgelehnten Mails raus (der Check ist der allererste in der Kette).

Das ist schon recht ermutigend. Es waren jetzt zum Schluss ca. 400 bis 500 Müll-Mails am Tag. Das nervt ganz schön. Die Spamfilter am Client sind auch nicht so berauschend. Außerdem wollte ich die Postfächer auf IMAP umstellen. Da hat das dann keinen Zweck am Client.

Insgesamt hätte es deine Mail vermutlich über meinen HELO-Filter geschafft. Aber meine Filterkette ist ja noch etwas länger. :)

Schade nur, dass Du ein anderes Mailprogramm benutzt ;-)
Vielleicht stelle ich das dann doch nochmal um, wenn ich den Server behalte.

Auf IP scheint der badmailfrom-Mechanismus aber sowieso nicht zu reagieren.

Ich denke, das ist das Stück Code...

int bmfcheck()
{
  int j;
  if (!bmfok) return 0;
  if (constmap(&mapbmf,addr.s,addr.len - 1)) return 1;
  j = byte_rchr(addr.s,addr.len,'@');
  if (j < addr.len) {
    if (constmap(&mapbmf,addr.s + j,addr.len - j - 1)) return 1;
    for (j++; j < addr.len; j++)
      if (addr.s[j] == '.') {
 if(constmap(&mapbmf,addr.s + j,addr.len - j - 1)) return 1;
      }
  }
  return 0;
}

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom