SMTP Kommando EXPN abschalten

[Tom]

Hello,

wir hatten da vor Kurzem mal einen Thread zum Thema eMail-Verifikation und die Gefahren dazu.

http://forum.de.selfhtml.org/archiv/2007/10/t161038/#m1048861

Nun brauche ich einen Tipp, wie ich das Kommando EXPN abschlaten kann, damit Mails an nicht vorhandene Empfänger einfach versickern...

Das smtp-Modul gehört zu Postfix. Ich kenne mich damit allerdings schon wieder nicht mehr aus :-((

Jedenfalls vermuten wir, dass Wörterbuchattacken gegen die bekannten Mailserver gefahren werden. Die Last steigt manchmal so an, dass man selber keine Mails mehr versenden kann.

Solange der Server immer brav antwortet, dass es den User nicht gibt, wird das auch nicht aufhören.

Wenn eine neue mailadresse mit Klarnamen (Vornamen) eingerichtet wurde, dauert es nur ein paar Tage, und es kommen reichlich Spammails.

Wie könnte man der Vermutung auf den Grund gehen?

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

Tom

[Sven Rautenberg]

Moin!

Solange der Server immer brav antwortet, dass es den User nicht gibt, wird das auch nicht aufhören.

Das muß er aber antworten. Und das hat nichts mit EXPN zu tun. Zumindest muß er mit permanentem Fehlerstatus antworten. Andernfalls geht Mail echt verloren im Nirvana.

Wenn eine neue mailadresse mit Klarnamen (Vornamen) eingerichtet wurde, dauert es nur ein paar Tage, und es kommen reichlich Spammails.

Das hielte ich für wenig verwunderlich. Spammails kommen sowieso. Die Frage ist, wie man dagegen vorgeht. Spams ablehnen ist eine sehr gute Idee, denn damit rettet man auch False Positives, denn der Sender kriegt ja von seinem Mailserver eine Unzustellbarkeitsnachricht.

Wie könnte man der Vermutung auf den Grund gehen?

Logfiles angucken, Serveraktivität auf der Shell beobachten, Erfahrung einbringen.

Werden jetzt schon irgendwelche Anti-Spam-Maßnahmen getroffen?

- Sven Rautenberg

[Tom]

Hello,

Logfiles angucken, Serveraktivität auf der Shell beobachten, Erfahrung einbringen.

Nun, bisher war da nur TOP -U postfix mein Freund und man kann dann in manchen Momenten ein erhebliches Anwachsen der Prozesse und der Last feststellen.

Werden jetzt schon irgendwelche Anti-Spam-Maßnahmen getroffen?

Das haben wir mal probiert (spamassassin) aber nicht wirklich hinbekommen. Ich scheitere da immer an dem blöden Confixx.

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

Tom

[Sven Rautenberg]

Moin!

Logfiles angucken, Serveraktivität auf der Shell beobachten, Erfahrung einbringen.

Nun, bisher war da nur TOP -U postfix mein Freund und man kann dann in manchen Momenten ein erhebliches Anwachsen der Prozesse und der Last feststellen.

Der SELFHTML-Mailserver hat solche Probleme eigentlich nicht.

Werden jetzt schon irgendwelche Anti-Spam-Maßnahmen getroffen?

Das haben wir mal probiert (spamassassin) aber nicht wirklich hinbekommen. Ich scheitere da immer an dem blöden Confixx.

Anti-Spam-Maßnahmen fangen viel viel früher an. Bei SELFHTML läuft gar kein Spamassassin oder sonst ein Inhaltsfilter, da werden ausschließlich strenge Regeln an das einliefernde SMTP-System gestellt, die von schlecht geschriebener Spam-Software nicht eingehalten werden.

Aber man könnt's ja auch mal mit dem "NiX-Spam"-System von der iX versuchen.

- Sven Rautenberg

[Tom]

Hello,

Anti-Spam-Maßnahmen fangen viel viel früher an. Bei SELFHTML läuft gar kein Spamassassin oder sonst ein Inhaltsfilter, da werden ausschließlich strenge Regeln an das einliefernde SMTP-System gestellt, die von schlecht geschriebener Spam-Software nicht eingehalten werden.

Ich erinnere mich auch dunkel daran, dass das hier schon mal ausführlicher diskutiert wurde.
Ich hatte mir damals die Essenz aus dem Thread als Vorgehensmuster beiseite gepackt und dann mal irgendwann zusammen mit dem Freund angefangen, das umzusetzen. Aber leider haben wir keinen Weg gefunden, dass Confixx die geänderte Konfiguration anerkennt oder in Ruhe lässt, ohne dass es "abkackt". Und einstellen konnte man es damit nicht, was ja dann der richtige Weg wäre.

Aber man könnt's ja auch mal mit dem "NiX-Spam"-System von der iX versuchen.

Schau ich mir an. Vielleicht nehme ich einen neuen Anlauf, wenn wir den Server neu aufgebaut haben.
Aber davor hat Der IT-Gott noch lesen - lesen - lesen gesetzt.

Ich möchte gerne die Suse loswerden und auf Debian umsteigen, aber das ist wahrscheinlich Geschmackssache. Compilieren wollten wir möglichset nicht selber und bisher war das auch nicht nötig (bis auf Zusatzmodule, wie z.B. phpize)

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

Tom

[Tom]

Hello,

Anti-Spam-Maßnahmen fangen viel viel früher an. Bei SELFHTML läuft gar kein Spamassassin oder sonst ein Inhaltsfilter, da werden ausschließlich strenge Regeln an das einliefernde SMTP-System gestellt, die von schlecht geschriebener Spam-Software nicht eingehalten werden.

Aber man könnt's ja auch mal mit dem "NiX-Spam"-System von der iX versuchen.

Ich habe mir das Script angeschaut.
Das ist schon sehr interessant, aber leider nur für procmail geeignet, wenn ich es richtig sehe.
Wir haben postfix.
Aber es bleibt im Gedächtnis. Wenn ich in der Script-Programmierung wieder fit bin, dann mache ich mal daran, darüber nachzusinnen, ob man die Ideen nicht auch für postfix nutzen kann. Das zugrundeliegende Protokoll ist schließlich dasselbe und genau in dieser Schicht setzt er ja an.

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

Tom

[Tom]

Hello Sven,

Der SELFHTML-Mailserver hat solche Probleme eigentlich nicht.

Verwendest Du für den SelfHTML-Mailserver auch Postfix? Das habe ich jetzt vergessen.

Wenn ja, könntest Du mir bitte einen Auszug von der Konfiguration zukommen lassen?
Ich habe mich da so leidlich reingewühlt. Es gab im Web eine halbgute Anleitung... und diverse Listen mit Mails zu Einstellungen, aber alle schon von 2002 und 2003.

Ich weiß jetzt nicht, wie ich headerchecks, mime_header_checks und body_checks anmelden und durchführen muss.

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

Tom

[Tom]

Hello,

so!
Ein paar einfache Header Checks habe ich jetzt auch drin.
Das reduziert die UCEs schon mal auf ca. 1/3.
Dass es so massiv wirkt, hätte ich nicht gedacht.

Wenn Du noch ein paar hübsche Muster für mich hättest, wäre das wirklich toll.

Welchen Unterschiet macht es, ob ich  pcre:  oder  regexp:  schreibe?

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

Tom

[Alexander (HH)]

Moin Moin!

Welchen Unterschiet macht es, ob ich  pcre:  oder  regexp:  schreibe?

Was steht denn dazu in der Doku?

Ich würde mal spontan tippen, dass pcre: eine Perl Compatible Regular Expression Engine auswählt, während regexp: eine andere Art von Regular Expression Engine oder die per Konfiguration als Standard festgelegte Engine auswählt.

Alexander

[Tom]

Hello,

Welchen Unterschiet macht es, ob ich  pcre:  oder  regexp:  schreibe?

Was steht denn dazu in der Doku?

Hab ich noch nicht gefunden.

Dafür aber eine extre agile Forumsseite zu Postfix
http://listi.jpberlin.de/pipermail/postfixbuch-users/

Ich würde mal spontan tippen, dass pcre: eine Perl Compatible Regular Expression Engine auswählt, während regexp: eine andere Art von Regular Expression Engine oder die per Konfiguration als Standard festgelegte Engine auswählt.

Die pcre macht was ulkiges, bzw. verstehe ich es wahrscheinlich falsch.

/^Subject:.*man.*lebt.*nur.*einmal/i    REJECT   ## funktioniert

/^Subject:.*man.*lebt.*nur.*einmal.*/i    REJECT   ## lässt durch:

Subject: Probieren Sie es - Mann Lebt nur einmal

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

Tom

[Tom]

Hello,

frei nach dem Motto "Einer kam durch"...

Das war zwar ein (Anti-)Kriegsfilm, wo der Durchkommer der Gute war, aber im Krieg gegen den Spam fühle ich mich auch. Und es gibt immer noch welche, die trotz Regeln durchkommen.

Ich habe header_checks vereinbart und die werden auch ausgeführt. Das sehe ich am Log, weil eben einige aus der Liste auch wunderbar matched werden, wenn ihre IP denn nicht schon auf der RBL erschienen ist...

Regeln unter

hypertextprotokoll:selfhtml.bitworks.de/postfix/text_spam.txt

Bitte NICHT verlinken!

Ich habe sie hier auch nicht hochladen können. Das Forum sträubt sich dagegen. Ich hoffe nicht deshalb, weil sie so falsch sind, sondern nur wegen der Sonderzeichen.

z.B. mein japanischer Freund (/^Subject:.*?ISO-2022-JP?/) wird immer gematched.
(/^From:[^<]*Replica/i) passt auch immer, egal, ob es vorne oder hinten steht.

Aber (/^Subject:.*man.*lebt.*nur.*einmal/i) kommt immer durch. Darum steht es jetzt auch zweimal drin, weil ich dachte, dass da unsichtbar ein Zeichen drin sein könnte, dass nicht passt.

Kann man die header_checks irgendwie dedizierter loggen lassen, damit ich sehe, wie die Entscheidung zustande kommt?

Erfreulich ist aber, dass ich die "Durchkommer" von den Spammern von ca. 600 auf 60 am Tag reduzieren konnte (pro Domain à zwei Mailkonten). Insgesamt erhalten wir auf dem Server ca. 14.400 Mails am Tag. Davon sind ca. 60 bis 120 SCE und der Rest eben UCE. Nutzanteil also nur ca. 6,94 o/oo !

Aber die 60 bis 100 falschen will ich auch noch loswerden, insbesondere diejenigen, denen man es doch mit blpßem Auge ansieht, weil sie immer denselben dämlichen Text im Subject oder im From: haben.

Bmerkenswert ist, dass ich bisher keine einzige FALSE POSITIVE entdecken konnte und ich sitze nun schon fast 24 Stunden vor "tail -f" und schaue zu... Spannender als Fernsehprogramm (hab ich hier auch nicht, nur über Internet, Kabel oder Satelit).

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

Tom

[Sven Rautenberg]

Moin!

Ich habe header_checks vereinbart und die werden auch ausgeführt. Das sehe ich am Log, weil eben einige aus der Liste auch wunderbar matched werden, wenn ihre IP denn nicht schon auf der RBL erschienen ist...

Du verfolgst vollkommen den falschen Ansatz.

Mit solchen Regeln rennst du immer hinterher, und kriegst, weil du nahezu deine gesamte verspammte Mail durchfiltern lassen mußt, sowohl viele nicht gefilterte Mails rein, als unter Umständen auch fehlerhafte positive Mails.

Im Prinzip machst du Inhaltsfilterung, nur mit "anderen Mitteln". Da würde ich dann doch lieber Spamassassin nehmen wollen, wenn sowas das einzige ist, was du willst.

Ich dachte eher an Dinge wie strenge Prüfung der HELO-Angaben, Prüfung der Existenz von Domains, Nutzung von Blacklisten, Nutzung von SPF, Greylisting, etc. Es gibt so wahnsinnig viele Möglichkeiten, die man aber natürlich kennen und nutzen muß, und schon verliert das Spamming seine Bedrohlichkeit.

Aber die 60 bis 100 falschen will ich auch noch loswerden, insbesondere diejenigen, denen man es doch mit blpßem Auge ansieht, weil sie immer denselben dämlichen Text im Subject oder im From: haben.

60 bis 100 Spams pro Tag wären mir entschieden zuviel. Auf meinem SELFHTML-Mailkonto kommen so gefühlt höchstens zehn Spams pro Tag durch.

- Sven Rautenberg

[Tom]

Hello Sven,

Ich habe header_checks vereinbart und die werden auch ausgeführt. Das sehe ich am Log, weil eben einige aus der Liste auch wunderbar matched werden, wenn ihre IP denn nicht schon auf der RBL erschienen ist...

Du verfolgst vollkommen den falschen Ansatz.

Das ist doch nur zusätzlich zu den von Dir unten erwähnten Maßnahmen...
Ich ahbe den fehler auch gefunden. Ich hatte das i-Flag gesetzt, was aber bei Postfix bedeutet, dass das Muster case sensitive wird. Es ist per default case Insensitive.

Man kann aber nicth alles auf einmal lesen... :-((

Mit solchen Regeln rennst du immer hinterher, und kriegst, weil du nahezu deine gesamte verspammte Mail durchfiltern lassen mußt, sowohl viele nicht gefilterte Mails rein, als unter Umständen auch fehlerhafte positive Mails.

Das ist mir schon klar, dass ich da nicht jedes neue Muster treffen kann.
Allerdings habe ich hier einen Poo, von ca. 190.000 Spam-Mails, den ich nun auswerten kann und auch die Dynaic darin erkennen kann. Es gibt begriffe, die immer wieder auftauchen. Die will ich hier aber nicht posten. Das wäre kontraproduktiv.

Im Prinzip machst du Inhaltsfilterung, nur mit "anderen Mitteln". Da würde ich dann doch lieber Spamassassin nehmen wollen, wenn sowas das einzige ist, was du willst.

Das ist mir schon klar. In den Body sind wir auch gar nicht erst eingestiegen.
Beim Header ist Schluss und das wird auch noch intelligenter, indem es auf Regeln beschränkt wird und nicht auf statische Inhalte. Wenn z.B. im Absender die eigene eMail-Adresse steht und im Betreff nicht ein ganz bestimmter Wert, wird gefiltert. Da interner Verkehr ohnhin am Filter vorbeigeht, kann das ohnhin nur passieren, wenn man sich auf einem fremden Server ein (temporäres) Konto eingerichtert hat mit seinem eigenen Absender und sich selber eine Mail schickt.

Ich dachte eher an Dinge wie

• strenge Prüfung der HELO-Angaben,    ist erledigt

• Prüfung der Existenz von Domains,    ist erledigt

• Nutzung von Blacklisten,             ist erledigt

• Nutzung von SPF,                     ?

• Greylisting,                         ?

Aber die 60 bis 100 falschen will ich auch noch loswerden, insbesondere diejenigen, denen man es doch mit blpßem Auge ansieht, weil sie immer denselben dämlichen Text im Subject oder im From: haben.

60 bis 100 Spams pro Tag wären mir entschieden zuviel. Auf meinem SELFHTML-Mailkonto kommen so gefühlt höchstens zehn Spams pro Tag durch.

von ca. 15.000 Mails am Tag?
Da sind 60 Rest-Spams schon ganz schön wenig, finde ich.

Und davon werde ich nun noch ca. die Hälfte los.

Dann siht die Statistik ungefähr so aus:

insdgesamt 5 Mailkonten, vier davon mit "ordentlich Betrieb", eins mit mäßig Betrieb

Eingang                           15.000
Mailboxen                            250
davon echte Mails                    220    ==> 1,466 %
False Positive bisher                  0    das glaube ich noch nicht ganz ...
Rejected due to wrong recipient    6.600    die hatten wir vorher schon gefiltert
rejected due to helo, !domain, RBL 8.150    die sind wir nun zusätzlich los
Rejected due to matching pattern     250                 - " -

Also alles in Allem hat sich die Nacht schon gelohnt :-)

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

Tom

[Tom]

Hello,

aktuelle Mailstatistik ist

/--------------------------------------------------------\ | Mail Statistics from running Log at 2007-12-03 01:25:52|
|                                                        |
| total amount of incoming mail:                  20583  |
| delivered mails inclusive resistant spam:         402  |
| rejected mails due to unknown recipients:        2408  |
| rejected generally:                             10623  |
| rejected due to RBL:                             7431  |
| rejected due to unknown sender host:             1951  |
| rejected due to suspicious sender address:        102  |
| rejected due to wrong helo command:               176  |
| rejected due to header 'received: (unknown)':     108  |
| rejected due to header message patterns:          287  |
| RELAY ACCESS unauthorized:                        178  |
--------------------------------------------------------/

Ich würde nun wirklich noch gerne ein SPF-Tool oder auch Greylisting noch einrichten, weiß abr echt nicht, wie ich das suf dem SuSE OS machen kann.

Ich kann mir zum Übern leider auch keinen SuSE auf meiner alten Testmaschine einrichten, obwohl noch genug HDDs da sind... Als ich es (mehrfach) probiert habe, kam das beliebte "Kernel Panic" bereits bei der Bootimage-CD.

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

Tom

[Sven Rautenberg]

Moin!

aktuelle Mailstatistik ist

/--------------------------------------------------------\ | Mail Statistics from running Log at 2007-12-03 01:25:52|
|                                                        |
| total amount of incoming mail:                  20583  |
| delivered mails inclusive resistant spam:         402  |
| rejected mails due to unknown recipients:        2408  |
| rejected generally:                             10623  |
| rejected due to RBL:                             7431  |
| rejected due to unknown sender host:             1951  |
| rejected due to suspicious sender address:        102  |
| rejected due to wrong helo command:               176  |
| rejected due to header 'received: (unknown)':     108  |
| rejected due to header message patterns:          287  |
| RELAY ACCESS unauthorized:                        178  |
--------------------------------------------------------/

Du hast nach meinem Empfinden viel zuwenig Filterung wegen HELO, und deshalb viel zuviel wegen RBL und "generally" (wobei die Frage ist, was das bedeutet).

Was hast du denn eingestellt?

- Sven Rautenberg

[Tom]

Hello,

/--------------------------------------------------------\ | Mail Statistics from running Log at 2007-12-03 01:25:52|
|                                                        |
| total amount of incoming mail:                  20583  |
| delivered mails inclusive resistant spam:         402  |
| rejected mails due to unknown recipients:        2408  |
| rejected generally:                             10623  |
| rejected due to RBL:                             7431  |
| rejected due to unknown sender host:             1951  |
| rejected due to suspicious sender address:        102  |
| rejected due to wrong helo command:               176  |
| rejected due to header 'received: (unknown)':     108  |
| rejected due to header message patterns:          287  |
| RELAY ACCESS unauthorized:                        178  |
--------------------------------------------------------/

Du hast nach meinem Empfinden viel zuwenig Filterung wegen HELO, und deshalb viel zuviel wegen RBL und "generally" (wobei die Frage ist, was das bedeutet).

Was hast du denn eingestellt?

Liegt vielleicht an der Reihenfolge?

smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = yes
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_pipelining,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
#    reject_rbl_client relays.ordb.org,       ## tot
    reject_rbl_client blackholes.easynet.nl,
    reject_rbl_client cbl.abuseat.org,
    permit
header_checks = pcre:/etc/postfix/antispam/header_checks.pcre

*hups*
da ist noch ein "generally" Fehler im Zählscript...

connect="grep -i ' connect from ' /var/log/mail | wc -l"
delivered="grep -i '(mailbox)' /var/log/mail | wc -l"
unknown_recipient="grep -i 'User unknown in virtual alias table' /var/log/mail | wc -l"
rej_general="grep -i ' reject: ' /var/log/mail | wc -l"
rej_rbl="grep -i '554 Service unavailable;' /var/log/mail | wc -l"
rej_unknown_sender="grep -i 'verification failed: Host not found' /var/log/mail | wc -l"
rej_susp_sender="grep -i 'Sender address rejected: Domain not found' /var/log/mail | wc -l"
rej_missing_helo="grep -i 'Helo command rejected: Invalid name;' /var/log/mail | wc -l"
rej_header_unknown="grep -i 'reject: header Received: from' /var/log/mail | wc -l"
rej_header_pattern="grep -i 'Message content rejected' /var/log/mail | wc -l"
relay_access_denied="grep -i 'Relay access denied;' /var/log/mail | wc -l"

Ich hatte "connect from" geschrieben und damit auch "disconnect from" erwischt, also doppelt gezählt. Das hat mich schon gewundert, weil so aus dem Bauch raus der Spam seit Einführung der Maßnahmen weniger geworden war und ich auch nicht finden konnte, wo der Rest geblieben sein sollte. Aber soweit war ich noch nicht. Ist noch noch "Übung"...

Aber nun werden plötzlich mehr Mails abgelehnt, als reinkommen. das geht auch nicht.

/--------------------------------------------------------\ | Mail Statistics from running Log at 2007-12-04 02:10:02|
|                                                        |
| total amount of incoming mail:                   7951  |
| delivered mails inclusive resistant spam:         125  |
| rejected mails due to unknown recipients:        2116  |
| rejected generally:                              8364  |
| rejected due to RBL:                             5657  |
| rejected due to unknown sender host:             1676  |
| rejected due to suspicious sender address:         86  |
| rejected due to wrong helo command:               137  |
| rejected due to header 'received: (unknown)':     182  |
| rejected due to header message patterns:           63  |
| RELAY ACCESS unauthorized:                        111  |
--------------------------------------------------------/

Es muss also noch ein Fehler drinstecken.

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

Tom

[Tom]

Hello,

Es muss also noch ein Fehler drinstecken.

Ausgehende Mails fehlen noch in der Liste. " connect to " sind aber heute nur 71.

Das geht immer noch nicht auf. Es fehlen immer noch welche.

' reject: ' + ' (mailbox) '  muss doch gleich ' connect from ' + ' connect to ' sein?

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

Tom

[Sven Rautenberg]

Moin!

Was hast du denn eingestellt?

Liegt vielleicht an der Reihenfolge?

Nein, die hast du zum Glück nicht von den diversen "Anleitungen" abgeguckt, sondern vernünftigerweise schon alles in die smtpd_recipient_restrictions getan.

Aber du könntest noch deutlich mehr tun. :)

reject_unknown_hostname - HELO-Namen sollten im DNS verfügbare Domains sein, nicht irgendwelche ausgedachten. Allerdings wird das im Standard nicht gefordert.

reject_non_fqdn_hostname - HELO-Namen müssen laut Standard ein FQDN sein! Diese Forderung erschlägt dir massenhaft Spammer.

Außerdem kannst du problemlos Mails ablehnen, die im HELO deine eigene Domain oder deine eigene IP-Adresse verwenden. Sowas tun nur Spammer, kein legitimer Mailserver (der nutzt immer seinen eigenen Hostnamen). Also ein check_helo_access reintun, und eine passende Lookup-Table integrieren, die alles, was mit deiner Domain oder deiner IP zu tun hat, ebenfalls final ablehnt.

Diese ganzen HELO-Checks gehören an den Anfang, irgendwo hinter "permit_mynetworks".

Es ist außerdem eine gute Idee, an passender Stelle noch eine IP-Whitelist und eine IP-Blacklist einzufügen, falls mal derartige Konstrukte entstehen, dass du jemanden auf so eine Liste setzen willst. Die Whitelist muß dann logischerweise vor den harten Maßnahmen greifen und ein PERMIT ausgeben, während die Blacklist nach den harten (aber unzureichenden) Maßnahmen dann ein REJECT (bzw. alternativ auch direkt einen scheiternden SMTP-Code mit Textbotschaft) ausgibt.

Die Auswahl an Blacklisten wäre eventuell noch zu verfeinern, oder durch http://www.policyd-weight.org/ ein etwas sanfteres Handling anzuwenden.

smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = yes
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_pipelining,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
#    reject_rbl_client relays.ordb.org,       ## tot
    reject_rbl_client blackholes.easynet.nl,
    reject_rbl_client cbl.abuseat.org,
    permit
header_checks = pcre:/etc/postfix/antispam/header_checks.pcre

Die header_checks halte ich dagegen für unsinnig. Ich zweifle, dass an dieser Stelle überhaupt noch viel Spam ankommt, wenn die Maßnahmen angepaßt wurden, es müßten aber ständig Anpassungen an die sich verändernden Spam-Mails vorgenommen werden. Und gerade wenn du da mit regulären Ausdrücken arbeitest, kann doch mal unerwartet ein Ausdruck matchen, obwohl die abgelehnte Mail absolut harmlos ist. Das Potential falscher Ablehnung ist mir da zu groß.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Aber du könntest noch deutlich mehr tun. :)

Was ich gerade noch gefunden habe: http://www.arschkrebs.de/postfix/postfix_incoming.shtml

Die Logik dahinter ist klar und paßt zu SPF: Mails deiner Domain können nur von authentifizierten Usern an deinen Mailserver gesendet werden, d.h. wenn ein Sender behauptet, deine Domain als Absender zu verwenden, und er authentifiziert sich nicht, dann treibt er Unfug, weil er im Widerspruch zu der Mail-Policy und den SPF-Einträgen handelt.

Was der Ralf Hildebrandt zu Postfix schreibt, ist übrigens grundsätzlich interessant.

- Sven Rautenberg

[Tom]

Hello,

Was ich gerade noch gefunden habe: http://www.arschkrebs.de/postfix/postfix_incoming.shtml

Was der Ralf Hildebrandt zu Postfix schreibt, ist übrigens grundsätzlich interessant.

Das habe ich schon auf der Liste vom Postfix-Buch gesehen, dass der wirklich gute Ideen hat.

Weißt Du, ob man diese Liste irgendwie (außer mit Google) durchsuchen kann, so wie unser Forumm hier

http://listi.jpberlin.de/pipermail/postfixbuch-users/

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

Tom

[Tom]

Hello Sven,

Liegt vielleicht an der Reihenfolge?

Nein, die hast du zum Glück nicht von den diversen "Anleitungen" abgeguckt, sondern vernünftigerweise schon alles in die smtpd_recipient_restrictions getan.

Dafür habe ich nun wieder zuviele Anleitungen gelesen, als dass ich das nicht verstanden habe :-))

Aber du könntest noch deutlich mehr tun. :)

Hab ich mir gedacht, will ich ja auch.

reject_unknown_hostname - HELO-Namen sollten im DNS verfügbare Domains sein, nicht irgendwelche ausgedachten. Allerdings wird das im Standard nicht gefordert.

OK

reject_non_fqdn_hostname - HELO-Namen müssen laut Standard ein FQDN sein! Diese Forderung erschlägt dir massenhaft Spammer.

Schaun wr mal.

Außerdem kannst du problemlos Mails ablehnen, die im HELO deine eigene Domain oder deine eigene IP-Adresse verwenden. Sowas tun nur Spammer, kein legitimer Mailserver (der nutzt immer seinen eigenen Hostnamen). Also ein check_helo_access reintun, und eine passende Lookup-Table integrieren, die alles, was mit deiner Domain oder deiner IP zu tun hat, ebenfalls final ablehnt.

Das würde ich gerne tun.
  Wie sieht der Table aus? So wie der bei header_checks?
  Muss ich einfach nur den Table verlinken, so wie es auch mit header_checks gemacht wird?

Diese ganzen HELO-Checks gehören an den Anfang, irgendwo hinter "permit_mynetworks".

ist auch klar.

Es ist außerdem eine gute Idee, an passender Stelle noch eine IP-Whitelist und eine IP-Blacklist einzufügen, falls mal derartige Konstrukte entstehen, dass du jemanden auf so eine Liste setzen willst. Die Whitelist muß dann logischerweise vor den harten Maßnahmen greifen und ein PERMIT ausgeben, während die Blacklist nach den harten (aber unzureichenden) Maßnahmen dann ein REJECT (bzw. alternativ auch direkt einen scheiternden SMTP-Code mit Textbotschaft) ausgibt.

Die header_checks halte ich dagegen für unsinnig. Ich zweifle, dass an dieser Stelle überhaupt noch viel Spam ankommt, wenn die Maßnahmen angepaßt wurden, es müßten aber ständig Anpassungen an die sich verändernden Spam-Mails vorgenommen werden. Und gerade wenn du da mit regulären Ausdrücken arbeitest, kann doch mal unerwartet ein Ausdruck matchen, obwohl die abgelehnte Mail absolut harmlos ist. Das Potential falscher Ablehnung ist mir da zu groß.

Das habe ich auch eingesehen, zumal man ständig hinterherrennen muss. Wenn Du "Penisvergroesserung" gerade raus hast, dann kommt "Penissvergrosserung" oder sonstwas...

Wie kann ich ein eigenes Shellscript in die Überprüfung einbinden?

Ich habe da nämlich den Wunsch, eine etwas aufwändigere Sache einzubauen, die auch ein LOG schreiben kann, wenn spezielle Bedingungen erfüllt sind.

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

Tom

[Sven Rautenberg]

Moin!

Außerdem kannst du problemlos Mails ablehnen, die im HELO deine eigene Domain oder deine eigene IP-Adresse verwenden. Sowas tun nur Spammer, kein legitimer Mailserver (der nutzt immer seinen eigenen Hostnamen). Also ein check_helo_access reintun, und eine passende Lookup-Table integrieren, die alles, was mit deiner Domain oder deiner IP zu tun hat, ebenfalls final ablehnt.

Das würde ich gerne tun.
  Wie sieht der Table aus? So wie der bei header_checks?
  Muss ich einfach nur den Table verlinken, so wie es auch mit header_checks gemacht wird?

Postfix hat für die "smtpd_*_restrictions" genau passend "check_*_access", mit denen eine Lookup-Tabelle angebunden wird. Die Formate dieser Tabelle sind vielfältig, von Hash über RegEx bis hin zu DB- und LDAP-Abfragen geht sehr viel, das Ergebnis so einer Abfrage hat dann wieder ein Wert zu sein, mit dem Postfix was anfange kann: "REJECT", "OK", "DUNNO", "554 We dont like spam", etc...

Wie kann ich ein eigenes Shellscript in die Überprüfung einbinden?

Ich habe da nämlich den Wunsch, eine etwas aufwändigere Sache einzubauen, die auch ein LOG schreiben kann, wenn spezielle Bedingungen erfüllt sind.

Ich würde das Perl-Skript der SPF-Policy als Grundlage nehmen und auf die gleiche Weise als Policy einbinden. Muß ja nicht zwingend Perl sein/bleiben, entscheidend ist die korrekte Implementierung des Interfaces über die Standardein- und -ausgabe.

- Sven Rautenberg

[Tom]

Hello,

nach dem Einfügen der beiden Zeilen

reject_unknown_hostname,
    reject_non_fqdn_hostname,

wurden schlagartig mehr doppelt soviele falsche HELOs abgelehnt.
Das hattest Du ja schon vermutet, dass da noch viel geht.

Aber auch die Anzahl der Connects ist danach relativ schnell um ca. 32% gefallen.
Nun arbeitet sie sich aber Stunde um Stunde wieder langsam hoch. und steht jetzt ca. 20% unter der von gestern um die gleiche Zeit.

Die Spammer lernen also dazu und stellen ihre Strategie darauf ein...

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

Tom

[Sven Rautenberg]

Moin!

nach dem Einfügen der beiden Zeilen
    reject_unknown_hostname,
    reject_non_fqdn_hostname,
wurden schlagartig mehr doppelt soviele falsche HELOs abgelehnt.
Das hattest Du ja schon vermutet, dass da noch viel geht.

Genau.

Aber auch die Anzahl der Connects ist danach relativ schnell um ca. 32% gefallen.

Wohl eher Zufall.

Nun arbeitet sie sich aber Stunde um Stunde wieder langsam hoch. und steht jetzt ca. 20% unter der von gestern um die gleiche Zeit.

Die Spammer lernen also dazu und stellen ihre Strategie darauf ein...

Nicht wirklich. Spamaktivitäten kommen und gehen wellenförmig. Ein gewisses Grundrauschen ist immer, aber manchmal ist merkwürdigerweise mal Pause, und manchmal wird es etwas intensiver.

Siehe beispielsweise http://aktuell.de.selfhtml.org/weblog/sober_rollt_an (mit netter Grafik).

- Sven Rautenberg

[Tom]

Hello,

Aber auch die Anzahl der Connects ist danach relativ schnell um ca. 32% gefallen.

Wohl eher Zufall.

Kommt mir eher so vor, als habe ein Admin seinen Kunden rausgeschmissen, nachdem nun die ganzen reject-Mails kommen. Die müssen ja auch irgendwo bleiben...

Jedenfalls ging der Trend heute wieder deutlich abwärts. Leider nicht bei denjenigen Mails, die als SPAM noch ausgeliefert werden. Die blieben leider fast konstant.

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

Tom

[Tom]

Hello,

Ich dachte eher an Dinge wie strenge Prüfung der HELO-Angaben, Prüfung der Existenz von Domains, Nutzung von Blacklisten, Nutzung von SPF, Greylisting, etc. Es gibt so wahnsinnig viele Möglichkeiten, die man aber natürlich kennen und nutzen muß, und schon verliert das Spamming seine Bedrohlichkeit.

Am Greylistung würge ich gerade herum:
Das müsste als nächstes rein, weil es wohl, noch mal 80 bis 90% vom verbleibenden Rest killen könnte.

Allerdings erhalte ich seit Tagen die Mails der Schusskandidaten schon alle dreimal oder viermal.
Die sind dann allerdings noch alle identisch, aber ich denke, da unsere Freunde hier ja auch mitlesen, wird sich das demnächst auch noch ändern.

Hier mal ein Header von einer solchen Mail:

--------------------------------------------------
Return-Path: [e-mail]
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from nv-76-0-229-9.dhcp.embarqhsd.net (nv-76-0-229-9.dhcp.embarqhsd.net [76.0.229.9])
 by h93968.serverkompetenz.net (Postfix) with ESMTP
 id 575E721C3D3; Sun,  2 Dec 2007 18:03:59 +0100 (CET)
Received: from [76.0.229.9] by gate.bluetenpracht.com; , 2 Dec 2007 09:01:52 -0800
Message-ID: 01c834c1$fabbc000$09e5004c@slhjy
From: "Tamara Lowry" [e-mail]
To: [e-mail]
Subject: Re: Barbecue
Date: , 2 Dec 2007 09:01:52 -0800
MIME-Version: 1.0
Content-Type: text/plain;
  charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3338.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1
X-UIDL: aN*#!lTf"!aL=!!3$N"!
---------------------------------------------------------

Welcher "Received:" wird denn in header_checks ausgewertet? Wenn ich da Zugriff nehme mit einem regulären Ausdruck, stehen doch beide Received-Header im Visier, oder?

Ich weiß immer nicht, was wirklch drinstehen muss im Mailheader, weil HELO fehlt.
Kann man das als Header hinzufügen lassen von Postfix? Ist ja eigentlich ein Protokollbestandteil und nicht Header, aber bei qmail hatte ich das damals auch immer drin.

Ich bin mir also nicht sicher, ob sich SPF dann überhaupt noch lohnt, wenn die Burschen doch sowieso schon jede Mail dreimal oder viermal schicken. Da fehlt ja nicht mehr viel.

Also kurz und gut: Ich habe da auch die Hosen voll, auf einem mir eigentlich unbekannten (SuSE-)Server, an den ich nur über Leitung herankomme, etwas einzukompilieren in eine existenzielle Software. Für den Debian, der neben mir steht, gibt es ein fertiges Package, und wenn da was kracht mit der Datenbank oder sonstwas, dann kann ich den zur Not auch per Hand neu starten.

Nächste Frage:

Kann ich den Spieß nicht umdrehen und Mails filtern, die gleich dreimal oder vielmal innerhalb weniger Sekunden eintreffen?
Blocken geht da ja zumindest bei der ersten nicht mehr. Wir befinden uns also sowieso schon beim Filtern, zumindest, was die Header angeht.

Wie ich SPF reinbekomme, ist mir noch überhaupt nicht klar!

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

Tom

[Sven Rautenberg]

Moin!

Am Greylistung würge ich gerade herum:
Das müsste als nächstes rein, weil es wohl, noch mal 80 bis 90% vom verbleibenden Rest killen könnte.

Postgrey genommen?

- Sven Rautenberg