Howto: Spamreduktion um 99%

7 views
Skip to first unread message

Wolfgang Kueter

unread,
Dec 10, 2007, 5:48:37 PM12/10/07
to
Moin zusammen,

Ich möchte gerne mein aktuelles Mailsetup hier vorstellen, das sich nach
meiner Erfahrung gut bewährt hat und eine *drastische* Reduktion von Spam
erreichen kann wobei es nur sehr wenig Ressourcen (CPU, RAM) benötigt.

Ausgangssituation für die Entwicklung dieses Setups war das immer höhere
Spamaufkommen in den letzten Monaten und meine Unlust, für die
Spambekämpfung viel Rechenleistung zu verbraten, Ziel war eben mit
möglichst wenig Ressourcen auszukommen, also die Masse von Spam abzuweisen
bevor sie den 'teuren' Scanner (spammassassin, ClamAV) auf mail-01
erreicht.

Man braucht:
2 Mailserver (mail-01, mail-02, ich verwende Postfix)
1 Paketfilter (entweder klassisch mail-01 vorgeschaltet oder Paketfilterrung
auf dem hier mit mail-01 bezeichneten Mailserver)

Die Architektur sieht wie folgt aus:

SMTP-Client oder MTA
|
Internet----------mail-02 (harte RBL-Filterung)
|
|
|
Paketfilter
|
mail-01 ((harte RBL-Filterung + Spamassassin)

mail-01 ist bester MX, mail-02 macht Backup-MX. Der Paketfilter ist so
eingerichtet, daß mail-01 auf Port 25/tcp nur von mail-02 aus erreichbar
ist, alle anderen SMTP Verbindungen werden vom Paketfilter hart und schnell
mit ICMP Host-Unreachable abgewiesen, was zur Folge hat, daß Mails an
mail-02 als Backup-MX ausgeliefert werden (müssen). Die deutliche ICMP
Meldung ist sehr bewußt gewählt, ein DROP des Paketfilters und Warten des
Clients auf den timeout der Verbindung würde das die Zustellung
verlangsamen.

Auf mail-02 werden dann etliche RBL Listen benutzt und auch von Systemen
ohne funktionierende Reverse-DNS Auflösung wird Mail mit 554 abgelehnt.
Mail von legitimen Systemen ohne RBL Eintrag wird angenommen und an mail-01
weitergegeben und dort dann letztlich vom 'teuren' Scanner nochmal
überprüft. Das Setup arbeitet damit dreistufig, wobei die eingesetzten
Ressourcen auf jeder Stufe zunehmen.

Stufe 1: IMCP Meldung, extrem billig
Stufe 2: RBL, immer noch ziemlich billig, kostet nur einige DNS Abfragen
Stufe 3: Scanner, teuer

Im Betrieb kann man beobachteten:

1. Sehr viele Systeme, die beim ersten Zustellversuch an mail-01 im
Paketfilter abprallen, versuchen gar nicht, an den Backup MX auszuliefern,
anhand der Logs (Paketfilter und maillog auf mail-02) schätze ich, man
erreicht mit dieser Maßnahme bereits eine Reduktion um etwa 90%

2. Die harte RBL Filterung auf mail-02 erledigt dann nochmal etwa 90% der
Mails.

Damit kommen bei mail-01 nur noch etwa 1% der Mails an, die er ohne
Paketfilter und RBL auf dem Backup erhalten hätte, die Maschine und der
Scanner langweilen sich zu Tode ...

Die Laufzeiten von Mails sind nach meinen Beobachtungen nicht kritisch, von
korrekt arbeitenden Mailservern kommen Mails oft innerhalb von wenigen
Sekunden an, manchmal dauert es aber auch schon mal bis zu 3 Minuten, das
Setup ist aber nach meiner Erfahrung eher schneller als Greylisting.

Kommentare sind erwünscht ...

Wolfgang

Message has been deleted

Wolfgang Kueter

unread,
Dec 10, 2007, 7:03:25 PM12/10/07
to
Heiko Schlenker wrote:

> * Wolfgang Kueter <wolf...@shconnect.de> schrieb:
>
>> Kommentare sind erwünscht ...
>
> Was ist eigentlich die Zielsetzung?

Reduktion der Last auf mail-01. Scanner, die viel Rechenleistung brauchen,
sind leider ein gutes Ziel für (D)DoS. Lass Zombies massenweise Mail-Müll
in einen Scanner kippen und die Kiste fährt vor die Wand und rechnet sich
fest. :(

> Was soll erreicht werden? Was
> darf auf keinen Fall passieren?

Im konkretren Fall gibt es keine Gefahren. Wichtige Mails gibt es nicht. ;)

Allerdings hat in 4 Wochen, in denen das jetzt so läuft, noch niemand
gemeckert, daß eine wichtige Mail geblockt wurde. ;)
>
> Jedenfalls ist das Ganze für Umgebungen ungeeignet, in denen keine
> erwünschte E-Mail "erledigt" werden darf.

Ja, das ist klar.

> Gut, wenn man
> beispielsweise postuliert, dass von Systemen ohne funktionierende
> Reverse-DNS-Auflösung per Definition keine erwünschte E-Mail stammen
> kann ...

;)

> Kurzum, die Kunst besteht darin, erwünschte Kommunikation nicht
> unverhältnismäßig zu behindern, trotzdem aber unerwünschte
> Nachrichten so gut es geht auszufiltern. Das ist mit simplen,
> unspezifischen Regeln à la "lehne E-Mails von Systemen ohne
> funktionierende Reverse-DNS-Auflösung stumpf ab" natürlich nicht zu
> machen.

Mir ist bewußt, daß die Sache mit dem Reverse-DNS hart ist, ich habe das
testweise auch mal abgeschaltet. Wenn ich die Maillogs angucke und mit
whois stichprobenartug nachgucke, was das für Gegenstellen sind, die wegen
nicht existentem Reverse-DNS abgelehnt werden, so handelt es sich idR um
Dial-Up Kisten in Drittweltstaaten. Aber ich stimme Dir zu, Reverse-DNS zu
verlangen, ist schon ein grober Keil für den groben Klotz Spam, man läuft
damit Gefahr, Unschuldige zu treffen.

Wolfgang

Paul Muster

unread,
Dec 11, 2007, 3:12:40 AM12/11/07
to
Wolfgang Kueter wrote:
> Heiko Schlenker wrote:
>> * Wolfgang Kueter <wolf...@shconnect.de> schrieb:

>>> Kommentare sind erwünscht ...

>> Was ist eigentlich die Zielsetzung?
>
> Reduktion der Last auf mail-01.

Wenn die Prämisse deines Mailverkehrs Lastreduktion ist, solltest du
vielleicht einfach gar keinen SMTP-Server laufen lassen.


mfG Paul

Bernd Hohmann

unread,
Dec 11, 2007, 4:09:56 AM12/11/07
to
Wolfgang Kueter wrote:

> Aber ich stimme Dir zu, Reverse-DNS zu verlangen, ist schon ein
> grober Keil für den groben Klotz Spam, man läuft damit Gefahr,
> Unschuldige zu treffen.

Wir haben es seit einem halben Jahr auf einer Maschine (wo nur DE-EU
Sachen laufen) auch so drin und steuern mit dnswl.org gegen. Bis auf
nicht nachvollziehbaren Probleme bei der Namensauflösung
moutng.kundenserver.de <-> [212.227.126.173] klappt das ganz gut und
hält den gröbsten Schmutz ab.

Bernd

--
Unsere Identität entnehmen Sie bitte dem beigefügten Auszug aus
den Personenstandsbüchern. Gegen die Assimilierung in unser
Kollektiv ist nach dem ABGB (§66.4) kein Rechtsmittel zulässig.

Malte J. Wetz

unread,
Dec 11, 2007, 4:24:47 AM12/11/07
to
Wolfgang Kueter wrote:

> Heiko Schlenker wrote:
>> Kurzum, die Kunst besteht darin, erwünschte Kommunikation nicht
>> unverhältnismäßig zu behindern, trotzdem aber unerwünschte
>> Nachrichten so gut es geht auszufiltern. Das ist mit simplen,
>> unspezifischen Regeln à la "lehne E-Mails von Systemen ohne
>> funktionierende Reverse-DNS-Auflösung stumpf ab" natürlich nicht zu
>> machen.
>
> Mir ist bewußt, daß die Sache mit dem Reverse-DNS hart ist, ich habe
> das testweise auch mal abgeschaltet. Wenn ich die Maillogs angucke und
> mit whois stichprobenartug nachgucke, was das für Gegenstellen sind,
> die wegen nicht existentem Reverse-DNS abgelehnt werden, so handelt es
> sich idR um Dial-Up Kisten in Drittweltstaaten. Aber ich stimme Dir
> zu, Reverse-DNS zu verlangen, ist schon ein grober Keil für den groben
> Klotz Spam, man läuft damit Gefahr, Unschuldige zu treffen.

Zumal RFC 1123 sogar verbietet, Mails wegen nicht auflösender Hostnamen
abzulehnen. Angeblich soll man damit seine Versand-Mailserver per NAT
verstecken können. Macht das eigentlich irgend jemand?

--
http://www.malte-wetz.de (Linux: ISDN-Anrufbeantworter, Text-To-Speech,
ISDN-Inhaltsdatenkomprimierung, yapsrc für alle dt. Netze, Sondertasten
von Multimedia-Tastaturen; Allgemein: Rechnersicherheit)

Wolfgang Kueter

unread,
Dec 11, 2007, 4:45:15 AM12/11/07
to
Paul Muster wrote:

Hm, die Last entsteht kaum durch SMTP sondern durch das, was danach kommt
(Scannerei), reiner Mailtransport macht selten Lastprobleme.

Die Sache ist doch so: Man braucht IMHO ein Mittel, das in der Lage ist,
möglichst ressourcenschonend mit dem ganzen Mailmüll fertig zu werden. In
Zeiten von Botnetzen und sich selbst verbreitender Malware hast Du quasi
eine Situation fast permaneter DDoS Attacken auf Mailserver und dagegen
möchte man IMHO *effektiv* vorgehen. Ein Mailserver, der vielleicht einige
hundert Mailkonten verwaltet, erhält für diese Konten vielleicht einige
tausend legitime Mails pro Tag, das ist selbst für ältere Hardware
lächerlich wenig und nichts, was selbst eine ältere Maschine auch bei
Verwendung von Scannern in den Kollaps treiben kann. Beim heutigen Anteil
legitmer Mail an der Gesamtmenge im Bereich von 2% sieht das aber anders
aus.

Natürlich kannst Du Hardware drauf werfen und schneller rechnen lassen, die
Spammer verzehnfachen inzwischen die Größe des Botnetzes und Du kaufst die
nächsten 3 Maschinen ...

Wolfgang

Bodo Eggert

unread,
Dec 11, 2007, 4:07:27 AM12/11/07
to
Wolfgang Kueter <wolf...@shconnect.de> wrote:

> Die Architektur sieht wie folgt aus:
>
> SMTP-Client oder MTA
> |
> Internet----------mail-02 (harte RBL-Filterung)
> |
> |
> |
> Paketfilter
> |
> mail-01 ((harte RBL-Filterung + Spamassassin)

> Im Betrieb kann man beobachteten:


>
> 1. Sehr viele Systeme, die beim ersten Zustellversuch an mail-01 im
> Paketfilter abprallen, versuchen gar nicht, an den Backup MX auszuliefern,
> anhand der Logs (Paketfilter und maillog auf mail-02) schätze ich, man
> erreicht mit dieser Maßnahme bereits eine Reduktion um etwa 90%

Unabhängig davon, daß dieses Setup nicht schön ist oder bei Verbreitung
wirksam bliebe: Ich würde den niedrigsten MX wieder auf mail01 legen,
damit die Spammer, die auf dem Backup-MX einliefern wollen, auch nicht
mehr durchkommen.

Sebastian Suchanek

unread,
Dec 11, 2007, 5:07:14 AM12/11/07
to
Malte J. Wetz schrieb:

> [...]


> Zumal RFC 1123 sogar verbietet, Mails wegen nicht auflösender Hostnamen
> abzulehnen.

> [...]

So richtig werde ich aus RfC 1123 nicht schlau - ich lehne z.B.
Mails ab, bei deren SMTP-Einlieferung der HELO-Paramter kaputt
ist, also nicht RfC 821 entspricht. (Fängt mir schon mal ~50%
meines SPAMs ab.)
Verstößt das jetzt gegen RfC 1123 oder nicht?

(Die Auswirkungen sind aber in jedem Fall lokal begrenzt - über
meinen Server geht de facto nur mein eigener Mailverkehr. :-))


Tschüs,

Sebastian

Message has been deleted

Wolfgang Kueter

unread,
Dec 11, 2007, 5:22:46 AM12/11/07
to
Bodo Eggert wrote:

> Unabhängig davon, daß dieses Setup nicht schön ist

1. -v
2. Ich will keinen Schönheitspreis gewinnen. ;)

> oder bei Verbreitung wirksam bliebe:

Um Stufe 1 (Abgeschottung von mail-01 durch Paketfilter) zu überwinden,
müßten Bots lernen, Backup-MXe zu benutzen. Viele tun das bisher nicht,
sondern folgem (noch) blind dem Ansatz, möglichst viel Mail in möglichst
kurzer Zeit rauszudrücken. Die Verwendung von RBL als Stufe 2 bleibt
bestehen, auch wenn die Bots gelernt haben, Backup-MXe zu benützen.

> Ich würde den niedrigsten MX wieder auf mail01 legen,
> damit die Spammer, die auf dem Backup-MX einliefern wollen, auch nicht
> mehr durchkommen.

-v

wk@work18:~> host -t mx shconnect.de
shconnect.de mail is handled by 10 mail-01.shconnect.de.
shconnect.de mail is handled by 20 mail-02.shconnect.de.

Wolfgang

Malte J. Wetz

unread,
Dec 11, 2007, 5:47:25 AM12/11/07
to
Sebastian Suchanek wrote:

> So richtig werde ich aus RfC 1123 nicht schlau - ich lehne z.B.
> Mails ab, bei deren SMTP-Einlieferung der HELO-Paramter kaputt
> ist, also nicht RfC 821 entspricht. (Fängt mir schon mal ~50%
> meines SPAMs ab.)
> Verstößt das jetzt gegen RfC 1123 oder nicht?

,----[ RFC 1123, Abschnit 5.2.5 ]
| The sender-SMTP MUST ensure that the <domain> parameter in a
| HELO command is a valid principal host domain name for the
| client host. As a result, the receiver-SMTP will not have to
| perform MX resolution on this name in order to validate the
| HELO parameter.
|
| The HELO receiver MAY verify that the HELO parameter really
| corresponds to the IP address of the sender. However, the
| receiver MUST NOT refuse to accept a message, even if the
| sender's HELO command fails verification.
`----

Ich interpretiere den zweiten Absatz so, dass der zweite Satz im Kontext
des ersten zu sehen ist. Sprich, das »MUST NOT refuse« bezieht sich
ausdrücklich auf die Überprüfung per DNS-Auflösung.

Dessen ungeachtet sollte man den ersten Absatz als Rechtfertigung
heranziehen können, eine Prüfung auf syntaktisch korrekt formatierte
FQDNs durchzuführen und ggf. Mails abzuweisen.

Also, nach meiner subjektiven Einschätzung:
Prüfung, ob im HELO ein FQDN steht und ablehnen, falls nicht, ist Ok.
Prüfung, ob der (syntaktisch korrekte) FQDN im DNS eingetragen wurde
(Auflösen auf IP) und ablehnen falls nicht, ist nicht Ok.

Bodo Eggert

unread,
Dec 11, 2007, 8:05:25 AM12/11/07
to
Wolfgang Kueter <wolf...@shconnect.de> wrote:
> Bodo Eggert wrote:

>> Unabhängig davon, daß dieses Setup nicht schön ist
>
> 1. -v
> 2. Ich will keinen Schönheitspreis gewinnen. ;)

Es sollten halt die Hosts drinnstehen, die Mails auch wirklich annehmen.

>> oder bei Verbreitung wirksam bliebe:
>
> Um Stufe 1 (Abgeschottung von mail-01 durch Paketfilter) zu überwinden,
> müßten Bots lernen, Backup-MXe zu benutzen. Viele tun das bisher nicht,
> sondern folgem (noch) blind dem Ansatz, möglichst viel Mail in möglichst
> kurzer Zeit rauszudrücken. Die Verwendung von RBL als Stufe 2 bleibt
> bestehen, auch wenn die Bots gelernt haben, Backup-MXe zu benützen.

Dann aber kannst Du mail-01 auch wieder austragen.

>> Ich würde den niedrigsten MX wieder auf mail01 legen,
>> damit die Spammer, die auf dem Backup-MX einliefern wollen, auch nicht
>> mehr durchkommen.

> wk@work18:~> host -t mx shconnect.de


> shconnect.de mail is handled by 10 mail-01.shconnect.de.
> shconnect.de mail is handled by 20 mail-02.shconnect.de.

shconnect.de mail is handled by 30 mail-01.shconnect.de.

Wolfgang Kueter

unread,
Dec 11, 2007, 9:14:32 AM12/11/07
to
Bodo Eggert wrote:


> Dann aber kannst Du mail-01 auch wieder austragen.

Dann müßte ich
a) auf mail-02 eine manuelle Mailroute setzen und damit wäre die erste Stufe
der Filterung weg, die 90% der Clients bereits mit ICMP erledigt, weil sie
nicht an Backup-MX ausliefern.

Wolfgang


Andreas M. Kirchwitz

unread,
Dec 11, 2007, 9:30:35 AM12/11/07
to
Wolfgang Kueter <wolf...@shconnect.de> wrote:

> Ich möchte gerne mein aktuelles Mailsetup hier vorstellen, das sich nach
> meiner Erfahrung gut bewährt hat und eine *drastische* Reduktion von Spam
> erreichen kann wobei es nur sehr wenig Ressourcen (CPU, RAM) benötigt.

Viel Aufwand und viel False Positives für ein Ergebnis, dass ich mit
einem vernünftig aufgesetzten Spam-Filter in einem traditionellen
Setup ohne fragwürdige Annahmen und Tricks auch erreiche.

Wenn Dein Mailserver zusammenbricht, muss das wohl noch eine Maschine
aus den 80ern sein. Oder die Konfiguration ist nicht gut. Selbst mit
einem besseren Pentium II kann man problemlos große Mengen Mail für
den eigenen Bedarf filtern.

Verwundert ... Andreas

Wolfgang Kueter

unread,
Dec 11, 2007, 10:23:56 AM12/11/07
to
Andreas M. Kirchwitz wrote:

> Wolfgang Kueter <wolf...@shconnect.de> wrote:
>
> > Ich möchte gerne mein aktuelles Mailsetup hier vorstellen, das sich
> > nach meiner Erfahrung gut bewährt hat und eine *drastische* Reduktion
> > von Spam erreichen kann wobei es nur sehr wenig Ressourcen (CPU, RAM)
> > benötigt.
>
> Viel Aufwand

Viel Hardware, OK, aber die war ohnehin vorhanden und aich in Betrieb,
Paketfilter und Backup-MX existierten sowieso.

> und viel False Positives

Das kann ich bis jetzt nicht betätigen.

> für ein Ergebnis, dass ich mit
> einem vernünftig aufgesetzten Spam-Filter in einem traditionellen
> Setup ohne fragwürdige Annahmen und Tricks auch erreiche.
>
> Wenn Dein Mailserver zusammenbricht, muss das wohl noch eine Maschine
> aus den 80ern sein.

Na ja, eher Ende des letzten Jahrtausends oder Anfang dieses ;)

> Oder die Konfiguration ist nicht gut. Selbst mit
> einem besseren Pentium II kann man problemlos große Mengen Mail für
> den eigenen Bedarf filtern.

Wen Du in einen älteren P3 etwa 1 Mail pro Sekunde kippst *und* teure
Scanner auf der Kiste laufen, wird das nach meiner Erfahrung knapp mit der
Rechenleistung. Solche Mailmengen sind bei Spamruns inzwischen ja schnell
erreicht.

Wolfgang

Rainer Sokoll

unread,
Dec 11, 2007, 10:22:02 AM12/11/07
to
Thus Wolfgang Kueter wrote:

> mail-01 ist bester MX, mail-02 macht Backup-MX. Der Paketfilter ist so
> eingerichtet, daß mail-01 auf Port 25/tcp nur von mail-02 aus erreichbar
> ist, alle anderen SMTP Verbindungen werden vom Paketfilter hart und schnell
> mit ICMP Host-Unreachable abgewiesen, was zur Folge hat, daß Mails an
> mail-02 als Backup-MX ausgeliefert werden (müssen).

Ohne mit Zahlen dienen zu können: Ich habe bei mir den Eindruck, daß
mehr Spammer den Backup-MX versuchen als den Haupt-MX.

Rainer

Wolfgang Kueter

unread,
Dec 11, 2007, 10:37:22 AM12/11/07
to
Rainer Sokoll wrote:


> Ohne mit Zahlen dienen zu können: Ich habe bei mir den Eindruck, daß
> mehr Spammer den Backup-MX versuchen als den Haupt-MX.

Das mag bei Dir so sein, es steht aber vollkommen im Widerspruch zu meinen
Erfahrungen. Wenn ich den Paketfilter vor dem Haupt-MX aufmache und SMTP
aus aller Welt zulasse verarbeitet die Maschine *erheblich* mehr Mails pro
Zeiteinheit (zum Beispiel eine Stunde) als der Backup-MX in einer Stunde,
wenn eben der Haupt-MX nicht erreichbar ist.

Bei gesperrtem Zugang zum Haupt-MX sieht man ja auch im Protokoll des
Paketfilters mit welcher Frequenz SMTP Connects von extern versucht und
abgelehnt werden und gleichzeitig im Mail-Log des Backup-MX was davon am
Backup-MX noch ankommt. Es ist nach meinen Logs wirklich drastisch weniger.

Dass es inzwschen Spamsoftware gibt, die gezielt versucht, an Backup-MXe
auszuliefern und den Haupt-MX gar nicht versucht, habe ich allerdings auch
schon bemerkt, das scheint nach meiner Wahrnehmung aber (noch) die Ausnahme
zu sein.

Wolfgang

Rainer Sokoll

unread,
Dec 11, 2007, 10:39:16 AM12/11/07
to
Thus Wolfgang Kueter wrote:

> Wen Du in einen älteren P3 etwa 1 Mail pro Sekunde kippst *und* teure
> Scanner auf der Kiste laufen, wird das nach meiner Erfahrung knapp mit der
> Rechenleistung. Solche Mailmengen sind bei Spamruns inzwischen ja schnell
> erreicht.

Das geht eigentlich. Wenn man bei den beiden "fetten" Scannern jeweils
die dämonisierten Varianten (also spamd und clamd) nimmt und genügend
RAM hat. Wenn es doch zu heftig wird, throttled der MTA ja
dankenswerterweise.

Rainer

Juergen Ilse

unread,
Dec 11, 2007, 12:19:31 PM12/11/07
to
Hallo,

Ein nicht unerheblicher Teil der Spammer liefert (sofern es einen Backup-MX
gibt) *ausschliesslich* an diesen ein (weil die teils nicht so hart filtern
wie der primary, was denn ggfs. zur "Weiterverteilung" von dem Muell an die
gefaketen absender fuehrt, was aber den Spammer nicht mehr kuemmern muss ...).

Ich halte es fuer einen Bug, wenn als primary MX einer im DNS steht, der
gar nicht erreichbar ist ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...

Matthias Leisi

unread,
Dec 11, 2007, 12:59:01 PM12/11/07
to
Wolfgang Kueter schrieb:

> Stufe 1: IMCP Meldung, extrem billig
> Stufe 2: RBL, immer noch ziemlich billig, kostet nur einige DNS Abfragen
> Stufe 3: Scanner, teuer

1) Du ersetzt einen Teil der in einem Standard-Setup(*) anfallenden
DNS-Abfragen durch ICMP-Meldungen. Wenn die Spamengine ein korrektes
Retry macht, hast du ICMP-Meldung *und* DNS-Abfrage(n).

2) Gewisse Spamengines halten sich nicht an die vorgesehene
MX-Record-Logik und/oder machen aus sonstigen Gründen kein korrektes
Retry, dafür hämmern sie auf dem erst-besten MX herum in der Hoffnung,
trotzdem durchzukommen. Das kann ansehnlichen ICMP-Traffic erzeugen.

3) Alle Mails werden gegenüber einem Standard-Setup(*) um die
Sender-spezifischen Timeouts für Retries verzögert. Gegenmassnahme
könnte sein, bekannt-gute Mailserver in der Firewall zu whitelisten.

4) Das Gesamtverhalten des Systems ist am Rande des spezifikationsmässig
zulässigen. Es kann daher auch für legitime Mails Zustellprobleme geben,
respektive es kann die Fehlersuche für einen aussenstehenden Admin
erschweren.

Insgesamt scheint mir das kein guter Tradeoff zu sein.

-- Matthias

(*) Funktionsfähiger "bester" MX

--
http://www.dnswl.org/ - Protect against false positives

Stefan Reuther

unread,
Dec 11, 2007, 1:29:55 PM12/11/07
to
Wolfgang Kueter wrote:
> mail-01 ist bester MX, mail-02 macht Backup-MX. Der Paketfilter ist so
> eingerichtet, daß mail-01 auf Port 25/tcp nur von mail-02 aus erreichbar
> ist, alle anderen SMTP Verbindungen werden vom Paketfilter hart und schnell
> mit ICMP Host-Unreachable abgewiesen, was zur Folge hat, daß Mails an
> mail-02 als Backup-MX ausgeliefert werden (müssen).

Ich könnte mir vorstellen, dass das zu Problemen mit erwünschten
Bulkmailern führen kann (z.B. Yahoogroups). Yahoogroups ist ja schon in
den Frühzeiten des Greylisting dadurch aufgefallen, dass sie keinen
zweiten Zustellungsversuch machen, also würde ich nicht ausschließen,
dass sie das hier auch nicht tun. Ich werde bei denen zumindest auch
gelegentlich mal auf Status "deine Mail bounct, also senden wir dir
nichts mehr" gesetzt.

Disclaimer: IANAMA (...MailAdmin).


Stefan

Bodo Eggert

unread,
Dec 11, 2007, 1:48:12 PM12/11/07
to

Die Voraussetzung für den Schritt ist gerade, daß diese Vorfilterung bereits
versagt, weil alle Dein Setup übernommen haben.

Bodo Eggert

unread,
Dec 11, 2007, 1:51:41 PM12/11/07
to
Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Malte J. Wetz schrieb:

>> [...]
>> Zumal RFC 1123 sogar verbietet, Mails wegen nicht auflösender Hostnamen
>> abzulehnen.
> > [...]
>
> So richtig werde ich aus RfC 1123 nicht schlau - ich lehne z.B.
> Mails ab, bei deren SMTP-Einlieferung der HELO-Paramter kaputt
> ist, also nicht RfC 821 entspricht. (Fängt mir schon mal ~50%
> meines SPAMs ab.)
> Verstößt das jetzt gegen RfC 1123 oder nicht?

Das wäre dann ein Syntaxfehler.
Zulässige Antworten bei HELO sind 500, 501, 504, 421.
Also ist die Antwort "501 Syntax error" zulässig.

Wolfgang Kueter

unread,
Dec 11, 2007, 2:44:18 PM12/11/07
to
Juergen Ilse wrote:

> Ein nicht unerheblicher Teil der Spammer liefert (sofern es einen

> Backup-MX gibt) *ausschliesslich* an diesen ein. [...]

Kann ich bestätigen.
Stichprobenartig finde ich viele IP Adressen, die im Paketfilter (Also
Zustellung an den Haupt-MX versucht haben) abprallen, im Logs des Backups
nicht mehr.

Umgekehrt gilt das genauso, ziemlich viel, was man im Maillog des Backup-MX
sieht, hat vorher *nicht* versucht, an den Haupt-MX zuzustellen.

Die Bots scheinen definitiv entweder oder zu versuchen, beide Mailserver
versuchen nur ganz wenige. Mal sehen, vielleicht bau ich mal was, um das
mal über den Zeitraum von einigen Stunden auszuzählen.

> Ich halte es fuer einen Bug, wenn als primary MX einer im DNS steht, der
> gar nicht erreichbar ist
> ...

Manche Bugs sind Features ;)

Wolfgang

Wolfgang Kueter

unread,
Dec 11, 2007, 3:20:49 PM12/11/07
to
Matthias Leisi wrote:

> Wolfgang Kueter schrieb:
>
>> Stufe 1: IMCP Meldung, extrem billig
>> Stufe 2: RBL, immer noch ziemlich billig, kostet nur einige DNS Abfragen
>> Stufe 3: Scanner, teuer
>
> 1) Du ersetzt einen Teil der in einem Standard-Setup(*) anfallenden
> DNS-Abfragen durch ICMP-Meldungen. Wenn die Spamengine ein korrektes
> Retry macht, hast du ICMP-Meldung *und* DNS-Abfrage(n).

Stimmt, aber die wenigsten tun es. Ohne es genau ausgezählt zu habne, kann
ich aber schon mal sagen:

Die meisten versuchen Zustellung an den besten MX.
Nicht ganz wenige versuchen Zustellung *nur* an den Backup.
Nur sehr wenige probieren beide.



> 2) Gewisse Spamengines halten sich nicht an die vorgesehene
> MX-Record-Logik und/oder machen aus sonstigen Gründen kein korrektes
> Retry, dafür hämmern sie auf dem erst-besten MX herum in der Hoffnung,
> trotzdem durchzukommen.

ICMP host-unreachable als Antwort von einem vorgeschalteten
Router/Paketfilter auf ein TCP SYN Paket ignoriert nicht mal ein Windows
TCP/IP Stack und das will was heißen. ;)

> Das kann ansehnlichen ICMP-Traffic erzeugen.

Hm, ein kompletter 3-way-handshake und der beginnende SMTP Dialog mit
HELO/EHLO etc. bedeutet eher mehr Traffic ;)

> 3) Alle Mails werden gegenüber einem Standard-Setup(*) um die
> Sender-spezifischen Timeouts für Retries verzögert.

Stimmt, aber das passiert bei Greylisting auch. Und nach meiner Erfahrung
kommen die Mails über den Backup schneller rein als wenn man Greylisting
macht. Ich habe um 20:58 testweise mal ein Posting nach de.test geschickt,
um zu gucken, wie schnell ich Antwort von irgendwelchen Mailreflektoren
kriege, ich habe jetzt (21:01) Antwort von 7 Reflektoren ueber den Backup:

Beispielhaft hier mal einer der Header zur Veranschaulichung der Laufzeiten:

---8<---
Received: from deep-thought.shconnect.de ([unix socket]) by deep-thought
(Cyrus v2.2.12) with LMTPA; Tue, 11 Dec 2007 20:58:44 +0100
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost [127.0.0.1]) by
deep-thought.shconnect.de (Postfix) with ESMTP id 31556AD1F5 for
<wolf...@shconnect.de>; Tue, 11 Dec 2007 20:58:39 +0100 (CET)
Received: from deep-thought.shconnect.de ([127.0.0.1]) by localhost
(deep-thought [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29056-06
for <wolf...@shconnect.de>; Tue, 11 Dec 2007 20:58:29 +0100 (CET)

Received: from milliways.shconnect.de (milliways.shconnect.de
[212.60.13.218]) by deep-thought.shconnect.de (Postfix) with ESMTP id
203C2ACE17 for <wolf...@shconnect.de>; Tue, 11 Dec 2007 20:58:28 +0100
(CET)

Received: from dedi.luli.de (dedi.luli.de [88.198.62.74]) by
milliways.shconnect.de (Postfix) with ESMTP id 7B0FD1C7CC for
<wolf...@shconnect.de>; Tue, 11 Dec 2007 20:58:25 +0100 (CET)

Received: (qmail 12229 invoked by uid 9); 11 Dec 2007 19:58:25 -0000
---8<---

Wie Du siehst, ist die Mail in der gleichen Sekunde auf dem Backup in dem
der absendende qmail die Zustellung beginnt und 3 Sekunden später auf dem
Haupt-MX. Die Scannerei und Auslieferung an die Mailbox dauert dann nochmal
etwa 15 Sekunden. Bei den anderen 6 Reflektorenmails waren als MTA
sendmail in unterschiedlichen Versionen und ein exim im Spiel und die
Zustellzeiten waren genauso schnell.

> Gegenmassnahme
> könnte sein, bekannt-gute Mailserver in der Firewall zu whitelisten.

Stimmt, das kann man für einige tun, aber wie schnell das Konstrukt
funktionieren kann (nicht immer funktionieren muss): s. Header der
Reflektorenmail.

> 4) Das Gesamtverhalten des Systems ist am Rande des spezifikationsmässig
> zulässigen. Es kann daher auch für legitime Mails Zustellprobleme geben,
> respektive es kann die Fehlersuche für einen aussenstehenden Admin
> erschweren.

Die ICMP Meldung, die der Router liefert, sagt sehr deutlich, dass der beste
MX nicht erreichbar ist. Damit sollte jeder normale Mailserver umgehen
können.

> Insgesamt scheint mir das kein guter Tradeoff zu sein.

YMMV

Wolfgang

Jost Krieger

unread,
Dec 11, 2007, 3:21:36 PM12/11/07
to
Malte J. Wetz schrieb:

> Zumal RFC 1123 sogar verbietet, Mails wegen nicht auflösender Hostnamen
> abzulehnen. Angeblich soll man damit seine Versand-Mailserver per NAT
> verstecken können. Macht das eigentlich irgend jemand?

Wo steht das? Es geht in RFC1123 m.E. darum, die Mail nicht nur deshalb
abzulehnen, weil das HELO nicht auf die IP des Klienten auflöst.

Hier ging es gar nicht ums HELO (soweit kommt der ja gar nicht).

Gruß Jost |8-))

Bernd Hohmann

unread,
Dec 11, 2007, 5:01:35 PM12/11/07
to
Jost Krieger wrote:

>> Zumal RFC 1123 sogar verbietet, Mails wegen nicht auflösender Hostnamen
>> abzulehnen. Angeblich soll man damit seine Versand-Mailserver per NAT
>> verstecken können. Macht das eigentlich irgend jemand?
>
> Wo steht das? Es geht in RFC1123 m.E. darum, die Mail nicht nur deshalb
> abzulehnen, weil das HELO nicht auf die IP des Klienten auflöst.

Korrekt.

Ich trag das aber mal als Topic in die "Ewige Liste" für Dezember ein.

Malte J. Wetz

unread,
Dec 11, 2007, 6:07:39 PM12/11/07
to
Jost Krieger wrote:

> Hier ging es gar nicht ums HELO (soweit kommt der ja gar nicht).

Ja, aber ist das nicht das gleiche in grün? Nicht ins DNS eingetragene
Systeme werden an der Auslieferung gehindert. Genau das, was man mit
der Bestimmung von 5.2.5 in RFC1123 eigentlich verhindern wollte.

Daher meine Frage, ob das überhaupt ein Problem ist, sprich, ob das
Verfahren (geNATete Mailouts ohne öffentlichen DNS-Eintrag) irgendwo
praktiziert wird.

Lutz Donnerhacke

unread,
Dec 11, 2007, 6:13:27 PM12/11/07
to
* Malte J. Wetz wrote:
> Daher meine Frage, ob das überhaupt ein Problem ist, sprich, ob das
> Verfahren (geNATete Mailouts ohne öffentlichen DNS-Eintrag) irgendwo
> praktiziert wird.

Ja, wir haben eine entsprechende Filtereinstellung wieder entfernt, weil
zuviele Firmen ihre Mailserver entsprechend aufsetzen. Mit Firmenkunden ist
das dann schwierig. Nun gibt's das Filterfeature nur noch auf Aufforderung.
Die Spamreduktion beträgt beim vollstänigen Blocken von "nicht rDNS", "DSL"
oder "Dialup" bei uns ca. 90% des Mailvolumens.

Lutz Donnerhacke

unread,
Dec 11, 2007, 6:15:02 PM12/11/07
to
* Malte J. Wetz wrote:
> Daher meine Frage, ob das überhaupt ein Problem ist, sprich, ob das
> Verfahren (geNATete Mailouts ohne öffentlichen DNS-Eintrag) irgendwo
> praktiziert wird.

Ja, wir haben eine entsprechende Filtereinstellung wieder entfernt, weil


zuviele Firmen ihre Mailserver entsprechend aufsetzen. Mit Firmenkunden ist
das dann schwierig. Nun gibt's das Filterfeature nur noch auf Aufforderung.

Die Spamreduktion beträgt beim vollständigen Blocken von "nicht rDNS", "DSL"
oder "Dialup" bei uns ca. 90% des Mailvolumens. Aber - wie geschrieben - es
sind einige Firmen dabei, die eingehend einen SPAM-Filter-Mailserver von
einem Drittanbieter benutzen und ausgehend direkt versenden.

Andreas M. Kirchwitz

unread,
Dec 11, 2007, 11:43:03 PM12/11/07
to
Wolfgang Kueter <wolf...@shconnect.de> wrote:

>> und viel False Positives
>
> Das kann ich bis jetzt nicht betätigen.

Beispielsweise Reverse DNS. Bei vielen (meist kleinen) Firmen,
die mit ihrer IT noch auf Kriegsfuß stehen, ist das leider oft
ein Problem. Umgekehrt erwischt so ein Reverse-DNS-Check kaum
zusätzlich Mail, die nicht auch auf anderem Weg bereits (viel
sicherer) als Spam erkennbar ist. Hier nicht mal 1 von 1000.

>> Oder die Konfiguration ist nicht gut. Selbst mit
>> einem besseren Pentium II kann man problemlos große Mengen Mail für
>> den eigenen Bedarf filtern.
>
> Wen Du in einen älteren P3 etwa 1 Mail pro Sekunde kippst *und* teure
> Scanner auf der Kiste laufen, wird das nach meiner Erfahrung knapp mit der
> Rechenleistung. Solche Mailmengen sind bei Spamruns inzwischen ja schnell
> erreicht.

86400 Messages pro Tag durch beispielsweise einen P3 mit 600 MHz
zu jagen, halte ich mit passendem (vorfilterndem) MTA (z.B. Exim)
für machbar, sofern die Maschine sonst nicht viel Rechenintensives
zu tun hat (also z.B. kein High-Traffic-Webserver mit PHP und MySQL).
Je mehr RAM die Maschine hat, desto besser.

Wie schon mal vor einiger Zeit erwähnt: Den Virus-Check kann man sich
im Zweifelsfall sparen. Mail-Viren gibt's kaum noch. Das meiste davon
kann auch der Spam-Filter erledigen. Wer unbedingt will, kann den
Virus-Check ja lastabhängig vornehmen.

Wäre zumindest eine Idee. ;-)

Alles wird gut ... Andreas

Erik Heinz

unread,
Dec 12, 2007, 2:49:31 AM12/12/07
to
* Malte J. Wetz wrote:
>
>> Hier ging es gar nicht ums HELO (soweit kommt der ja gar nicht).
>
> Ja, aber ist das nicht das gleiche in grün? Nicht ins DNS eingetragene
> Systeme werden an der Auslieferung gehindert. Genau das, was man mit
> der Bestimmung von 5.2.5 in RFC1123 eigentlich verhindern wollte.

Nein. Fehlende oder inkonsistente DNS-Einträge sind einfach nur schlampige
Konfiguration und das lässt sich bei Einsicht in die Zusammenhänge leicht
abstellen. Für einen vom DNS-Namen abweichenden HELO-Namen kann es aber
bei komplizierteren Setups durchaus gute Gründe geben.

Gruß,
Erik

--
IKS GmbH, Leutragraben 1, D-07743 Jena
Tel.: +49 (3641) 460850 Fax: +49 (3641) 460855
Geschäftsführer: Jens Bookhagen, Jena HRB 205795

Erik Heinz

unread,
Dec 12, 2007, 2:56:25 AM12/12/07
to
* Andreas M. Kirchwitz wrote:
>
> Beispielsweise Reverse DNS. Bei vielen (meist kleinen) Firmen,
> die mit ihrer IT noch auf Kriegsfuß stehen, ist das leider oft
> ein Problem.

Stimmt. Ob man das einsetzen kann, hängt vom Kommunikationsverhalten ab.
Wer im wesentlichen einen festen Kreis von Kommunikationspartnern hat, kann.
Wer z.B. auf Neukundenkontakte per Mail angewiesen ist, kann nicht.

> Umgekehrt erwischt so ein Reverse-DNS-Check kaum
> zusätzlich Mail, die nicht auch auf anderem Weg bereits (viel
> sicherer) als Spam erkennbar ist. Hier nicht mal 1 von 1000.

Mag sein. Man kann das aber auch umgekehrt sehen: wenn ich 90% Müll schon
per simplem DNS-Check ablehnen kann, entlastet das das Content-Filter enorm.

Wolfgang Kueter

unread,
Dec 12, 2007, 3:42:16 AM12/12/07
to
Andreas M. Kirchwitz wrote:

> Beispielsweise Reverse DNS. Bei vielen (meist kleinen) Firmen,
> die mit ihrer IT noch auf Kriegsfuß stehen, ist das leider oft
> ein Problem.

Was hindert solche Firmen, wenn sie denn einen eigenen Mailserver betreiben,
für den Versand von Mail einen Mailserver ihres ISP als Smarthost zu
verwenden? Für einen Smarthost bei einem ISP kann man annehmen, daß reverse
DNS sichergestellt ist. Allgemein ist reverse DNS eine Aufgabe, um die sich
eher die ISPs kümmern, kaum eine Firma mit Festverbindung und kleinem oder
großen, öffentichen IP-Adressraum betreibt selbst öffentlich erreichbare
DNS-Server. Wenn in Firmen DNS Server laufen, sind die oft nur
caching-only, allenfalls primary für eine intern verwendete Domain und auch
nur aus den LAN erreichbar.

Wolfgang

Lutz Donnerhacke

unread,
Dec 12, 2007, 4:15:27 AM12/12/07
to
* Wolfgang Kueter wrote:
> Andreas M. Kirchwitz wrote:
>> Beispielsweise Reverse DNS. Bei vielen (meist kleinen) Firmen,
>> die mit ihrer IT noch auf Kriegsfuß stehen, ist das leider oft
>> ein Problem.
>
> Was hindert solche Firmen, wenn sie denn einen eigenen Mailserver betreiben,
> für den Versand von Mail einen Mailserver ihres ISP als Smarthost zu
> verwenden?

Eingehend wird über einen Spamausfilterdienstleister per MX empfangen.
Ausgehend sendet jede Zweigstelle direkt über den lokalen DSL Anschluß mit
dynamischer oder fester IP. Bei fester IP ist i.d.R. kein reverse DNS seitsn
des ISP eingerichtet.

Wolfgang Kueter

unread,
Dec 12, 2007, 4:22:50 AM12/12/07
to
Lutz Donnerhacke wrote:


>> Was hindert solche Firmen, wenn sie denn einen eigenen Mailserver
>> betreiben, für den Versand von Mail einen Mailserver ihres ISP als
>> Smarthost zu verwenden?
>
> Eingehend wird über einen Spamausfilterdienstleister per MX empfangen.
> Ausgehend sendet jede Zweigstelle direkt über den lokalen DSL Anschluß mit
> dynamischer oder fester IP. Bei fester IP ist i.d.R. kein reverse DNS
> seitsn des ISP eingerichtet.

Du lieferst eine Situationsbeschreibung, beantwortest aber die Frage nicht.

;)

Wolfgang

Rainer Sokoll

unread,
Dec 12, 2007, 4:57:46 AM12/12/07
to
Thus Lutz Donnerhacke wrote:

> Eingehend wird über einen Spamausfilterdienstleister per MX empfangen.
> Ausgehend sendet jede Zweigstelle direkt über den lokalen DSL Anschluß mit
> dynamischer oder fester IP. Bei fester IP ist i.d.R. kein reverse DNS seitsn
> des ISP eingerichtet.

Bzw. das "EHLO KENSERVER" matcht nicht mit 4.3.2.1-dialinpool.example.com :-)

Rainer

Bernd Hohmann

unread,
Dec 12, 2007, 5:55:37 AM12/12/07
to
Wolfgang Kueter wrote:

> Was hindert solche Firmen, wenn sie denn einen eigenen Mailserver betreiben,
> für den Versand von Mail einen Mailserver ihres ISP als Smarthost zu
> verwenden?

Ich kenne das in etwa so: man stellt sich erst für diverse
Unified-Messaging Dienste einen Server ins Haus, später richtet man
einen POP3-Sammeldienst ein um externe Mails inhouse zu verwalten und
dann kauft man sich ein entsprechend beworbenes DSL-Paket ("damit können
Sie ihren Mailserver betreiben") und versendet selber.

Von einer Administration des Inhouse-Servers kann man nur in den
seltensten Fällen sprechen, denn dort beherrscht normalerweise die
Maschine den Menschen sodass das ganze mit einer kruden Mischung aus
Technik und Schamanismus am laufen gehalten wird.

Den Hohepriester einer solchen Alchemistenküche auf Urlaubsreisen klug
zu machen scheitert in der Regel daran, dass sich der Kollege jegliche
Störung seiner Traumwelt (und im Traum können wir bekanntlich alle
Fliegen wie die Vögel) verbittet.

Wolfgang Kueter

unread,
Dec 12, 2007, 5:57:02 AM12/12/07
to
Rainer Sokoll wrote:

> Bzw. das "EHLO KENSERVER" matcht nicht mit 4.3.2.1-dialinpool.example.com

Meine Konfig ist nicht übrigens gar nicht so restriktiv, dass
Übereinstimmung verlangt wird. Es reicht mir, wenn zu einer IP im rDNS
überhaupt etwas gefunden wird.

Bei dem geht nix:

Dec 12 11:28:17 milliways postfix/smtpd[32248]: NOQUEUE: reject: RCPT from
unknown[80.253.80.50]: 554 Client host rejected: cannot find your hostname,
[80.253.80.50]; from=<xxxx...@example.com> to=<yyyyy...@example.com>
proto=SMTP helo=<t-online.de>

der prallt zwar auch ab, aber es geht etwas mehr:

Dec 12 11:23:54 milliways postfix/smtpd[32235]: NOQUEUE: reject: RCPT from
c41-168.icpnet.pl[62.21.41.168]: 554 Service unavailable; Client host
[62.21.41.168] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?62.21.41.168; from=<xxxx...@example.com>
to=<yyyyy...@example.com> proto=SMTP helo=<kamila1.icpnet.pl>

Wolfgang

Wolfgang Kueter

unread,
Dec 12, 2007, 6:15:50 AM12/12/07
to
Bernd Hohmann wrote:

> Ich kenne das in etwa so: [...]

Deine in der Praxis gewonnene Erfahrung deckt sich mit meiner.

:(

Da aber inzwischen leider etwa 98% aller transportieren Mail nur noch Müll
ist, kann man zunehmend weniger Rücksicht nehmen und die Betreiber von
schlecht administrierten Systemen müssen IMHO damit leben, dass sie ihre
Mails nicht mehr loswerden und Fehlermeldungen erhalten.

Wolfgang

Bernd Hohmann

unread,
Dec 12, 2007, 6:24:11 AM12/12/07
to
Wolfgang Kueter wrote:

> Da aber inzwischen leider etwa 98% aller transportieren Mail nur noch Müll
> ist, kann man zunehmend weniger Rücksicht nehmen und die Betreiber von
> schlecht administrierten Systemen müssen IMHO damit leben, dass sie ihre
> Mails nicht mehr loswerden und Fehlermeldungen erhalten.

Das ist eben das Problem: diese Krauterkisten werden noch zu oft Ihre
Mails los, selbst wenn sie bereits tief in den RBLs verankert sind oder
hemmungslos falsch konfiguriert sind. Die Prügel bekomme ich dann ab.

Lutz Donnerhacke

unread,
Dec 12, 2007, 6:46:06 AM12/12/07
to
* Wolfgang Kueter wrote:
>>> Was hindert solche Firmen, ...

>
> Du lieferst eine Situationsbeschreibung, beantwortest aber die Frage nicht.

Gut, Du willst es so. Die Antwort lautet: "Geht doch!"

Wolfgang Kueter

unread,
Dec 12, 2007, 6:55:37 AM12/12/07
to
Bernd Hohmann wrote:

> Das ist eben das Problem: diese Krauterkisten werden noch zu oft Ihre
> Mails los, selbst wenn sie bereits tief in den RBLs verankert sind oder
> hemmungslos falsch konfiguriert sind. Die Prügel bekomme ich dann ab.

Wie man gut man solche Prügel ertragen kann, ist nur eine Frage der Höhe des
Schmerzensgeldes. ;)

Wolfgang

Wolfgang Kueter

unread,
Dec 12, 2007, 7:00:45 AM12/12/07
to
Lutz Donnerhacke wrote:

Mail geht eben leider auf der globalen Ebene zunehmend schlechter und
schlechter und irgendwann fängt das an, Folgen für die Einzelnen zu haben,
die jahrelang immer nur nach der Devise "Geht doch" vorgegangen sind.

Wolfgang

Lutz Donnerhacke

unread,
Dec 12, 2007, 7:02:19 AM12/12/07
to
* Wolfgang Kueter wrote:

> Lutz Donnerhacke wrote:
>> Gut, Du willst es so. Die Antwort lautet: "Geht doch!"
>
> Mail geht eben leider auf der globalen Ebene zunehmend schlechter und
> schlechter und irgendwann fängt das an, Folgen für die Einzelnen zu haben,
> die jahrelang immer nur nach der Devise "Geht doch" vorgegangen sind.

Im gewerblichen Umfeld, interessiert es den Kunden nicht, ob seine
Geschäftspartner bescheuert, blöd oder unfähig ist, sondern ob er von ihm
Mails wie bisher empfangen kann.

Message has been deleted

Sebastian Suchanek

unread,
Dec 12, 2007, 7:58:28 AM12/12/07
to
Heiko Schlenker schrieb:

> [...]
> Man hat keine Kontrolle über den Smarthost:
> Man hat keinen Zugriff auf die Logfiles. Man weiß nicht, ob die
> Nachrichten den eigenen Zuständigkeitsbereich verlassen haben und in
> den Zuständigkeitsbereich des Empfänger gelangt sind. Außerdem ist
> der Provider bald verpflichtet, Verbindungsdaten über einen langen
> Zeitraum zu speichern. Und so weiter und so fort.

Und Du glaubst, das alles würde Vollpatienten, wie sie Bernd so
schön beschrieben hat, tangieren?


Tschüs,

Sebastian

Clemens Zauner

unread,
Dec 12, 2007, 8:10:35 AM12/12/07
to
Rainer Sokoll <rai...@sokoll.com> wrote:
> Das geht eigentlich. Wenn man bei den beiden "fetten" Scannern jeweils
> die dämonisierten Varianten (also spamd und clamd) nimmt und genügend
> RAM hat. Wenn es doch zu heftig wird, throttled der MTA ja
> dankenswerterweise.

Skaliert auch nur mehr bedingt. Erfahrungsgemäss ist bei >1 Mail/sec
an die fetten Scanner (ja, dämonisiert) eher das Limit erreicht, das
sich noch einigermassen kostengünstig per Hardware erschlagen lässt.

Kurzzeitige Spitzen regeln sich ab. Aber bei MTAs die oft stundelang
solche Volumina dursetzen müssen hilft es einfach enorm offensichtlichen
Dünnpfiff im Dialog so früh wie möglich abzulehnen. Und eine gute Wahl
an RBLs ist da eine geeignete Wahl, IMO.

Es macht einfach keinen Spass sonst. Gut, eventuell bin ich einfach
ein alter Sack; aber ich bin der Ansicht dass sich Mailsysteme ein
paar Jahre halten sollten. Es ist absolut witzfrei da im Jahrestakt
"the latest and greatest" Hardware hinzuschieben.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Message has been deleted

Lutz Donnerhacke

unread,
Dec 12, 2007, 8:46:29 AM12/12/07
to
* Heiko Schlenker wrote:
> Das ist der Knackpunkt. Was sind "gute" RBLs?

Die eigenen.

> Ich möchte schon selbst bestimmen, welche Filterkriterien zum
> Einsatz kommen und welche Systeme auf der schwarzen Liste landen.

Tu's doch.

> Mit RBLs, die unter fremder Kontrolle stehen, ist das nicht zu
> machen.

Dann laß es doch.

> RBLs im Kontext des Scoring heranzuziehen ist in Ordnung.

Fremde RBLs, ja.

Clemens Zauner

unread,
Dec 12, 2007, 9:01:34 AM12/12/07
to
Heiko Schlenker <hsc...@gmx.de> wrote:
>
> Das ist der Knackpunkt. Was sind "gute" RBLs? Ist es wirklich "gut",
> bloß aufgrund von RBLs Nachrichten abzulehnen?
>

Das hängt von den Präferenzen des Admins ab. Und wenn einem gar keine
zusagt: den Ausweg hat Lutz ja aufgezeigt.

Message has been deleted

Hanno Foest

unread,
Dec 12, 2007, 9:27:45 AM12/12/07
to
Lutz Donnerhacke schrieb:

> Gut, Du willst es so. Die Antwort lautet: "Geht doch!"

"Warum beschweren Sie sich dann?"

Hanno

Bernd Hohmann

unread,
Dec 12, 2007, 10:04:08 AM12/12/07
to
Lutz Donnerhacke wrote:

> Im gewerblichen Umfeld, interessiert es den Kunden nicht, ob seine
> Geschäftspartner bescheuert, blöd oder unfähig ist, sondern ob er von ihm
> Mails wie bisher empfangen kann.

Das Problem ist zunehmend dem eigenen Kunden klarzumachen dass es nicht
bei einem selber klemmt sondern die Mails von der Gegenseite überhaupt
nicht oder nur mit massiver Verzögerung ausgeliefert werden.

Typischerweise passiert das dann, wenn der bisherige Fileserver erst
Router, dann NAT-Gateway und zum Schluss noch Mailserver spielen muss -
das Ganze natürlich auf dem 19,95 EUR DSL-Tarif von Anbieter
"Schlagmichtot".

Typische Antwort "Es geht sonst immer" und "Wieso, ist doch ne
Standleitung?"

Marc Haber

unread,
Dec 12, 2007, 10:10:12 AM12/12/07
to

Gerade im gewerblichen Umfeld ist doch eher "das ist _mein_
Mailserver, _ich_ bestimme was ich annehmen, sag doch gefälligst
Deinem Dienstleister durch welche brennenden Reifen er zu springen hat
damit ich Eure Mails wieder annehme" üblich.

Grüße
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Wolfgang Kueter

unread,
Dec 12, 2007, 2:36:11 PM12/12/07
to
Heiko Schlenker wrote:

> Man hat keine Kontrolle über den Smarthost: [...]

Zustimmung, keine Frage. Das Argument gilt allerdings nur für Umgebungen, in
denen jemand mit der Administration des Mailsystems befaßt ist, der die
erfoderliche Qualifikation dazu aufweist und in der Lage ist, ins Log zu
gucken und zu versteht, was er darin sieht. Standorte mit solchem Personal
haben dann oft auch Anbindungen ans Internet, die ohne Smarthost auskommen
und rDNS funktioniert für deren Adressraum eben oft auch. ;)

Die Krauterklitsche mit einem irgendwie funktionierenden (?) Mailserver, der
von irgendjemandem irgendwie zusammengeklickt wurde, der noch nicht mal
weiß, daß Mailsysteme normalerweise Logs schreiben, kann mit Deinem
Argument eben gerade *nicht* kommen, denn da guckt zwar nie einer ins Log
aber jeder schreit, wo seine 50 MB große Mailanlage denn geblieben sein
könnte, wenn die nach 3 Minuten noch nicht beim Empfänger angekommen ist
(vorhandene DSL upstream Bandbreite 128 kbit/s) ;)

Wolfgang

Wolfgang Kueter

unread,
Dec 12, 2007, 2:51:28 PM12/12/07
to
Erik Heinz wrote:

> Nein. Fehlende oder inkonsistente DNS-Einträge sind einfach nur schlampige
> Konfiguration und das lässt sich bei Einsicht in die Zusammenhänge leicht
> abstellen.

ACK.

> Für einen vom DNS-Namen abweichenden HELO-Namen kann es aber
> bei komplizierteren Setups durchaus gute Gründe geben.

Schon relativ einfache Setups (virtuelle (web)Server auf einer Maschine,
mehrere Hostnamen für die geliche IP im DNS oder ganz einfach ein
Mailserver, der für mehrere Domains Mail annimmt und/oder versendet)
verursachen sowas. Und genau deshalb stellen sich meine hier beispielhaft
vorgestellten Systeme beim HELO nicht zickig an.

Wolfgang

Wolfgang Kueter

unread,
Dec 12, 2007, 2:59:39 PM12/12/07
to
Clemens Zauner wrote:

> Es macht einfach keinen Spass sonst. Gut, eventuell bin ich einfach

> ein alter Sack; [...]

Keine Angst, Du bist nicht allein, in diesem Thread schreiben nur alte
Säcke.

Wolfgang


Lutz Donnerhacke

unread,
Dec 12, 2007, 3:17:11 PM12/12/07
to

Tun sie nicht. Es sind deren Kommunikationspartner, die ihren lokalen ISPs
die Hölle heiß machen.

Lutz Donnerhacke

unread,
Dec 12, 2007, 3:18:37 PM12/12/07
to
* Marc Haber wrote:

> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Im gewerblichen Umfeld, interessiert es den Kunden nicht, ob seine
>>Geschäftspartner bescheuert, blöd oder unfähig ist, sondern ob er von ihm
>>Mails wie bisher empfangen kann.
>
> Gerade im gewerblichen Umfeld ist doch eher "das ist _mein_
> Mailserver, _ich_ bestimme was ich annehmen, sag doch gefälligst
> Deinem Dienstleister durch welche brennenden Reifen er zu springen hat
> damit ich Eure Mails wieder annehme" üblich.

Selbst wenn Du gewerbliches Umfeld auf Unternehmen in der IT Branche
beschränkst, hast Du nicht mal Recht.

Bernd Hohmann

unread,
Dec 12, 2007, 6:24:02 PM12/12/07
to
Lutz Donnerhacke wrote:

>> Gerade im gewerblichen Umfeld ist doch eher "das ist _mein_
>> Mailserver, _ich_ bestimme was ich annehmen, sag doch gefälligst
>> Deinem Dienstleister durch welche brennenden Reifen er zu springen hat
>> damit ich Eure Mails wieder annehme" üblich.
>
> Selbst wenn Du gewerbliches Umfeld auf Unternehmen in der IT Branche
> beschränkst, hast Du nicht mal Recht.

Ich hab hier beim letzten Umzug Memos weggeschmissen. in denen die
technischen Grundlagen für eine einwandfreie E-Mail Kommunikation
festgelegt wurden - quasi alles Reverse-Engineering des SMTP-Protokolls
ohne die RfCs zu kennen.

Nein, ich scherze nicht, ein kleines Unternehmen war das auch nicht und
Anstand verbietet es mir, Namen zu nennen.

Roland M. Kreutzer

unread,
Dec 13, 2007, 5:02:56 AM12/13/07
to
Wolfgang Kueter wrote:
> 1. Sehr viele Systeme, die beim ersten Zustellversuch an mail-01 im
> Paketfilter abprallen, versuchen gar nicht, an den Backup MX auszuliefern,
> anhand der Logs (Paketfilter und maillog auf mail-02) schätze ich, man
> erreicht mit dieser Maßnahme bereits eine Reduktion um etwa 90%

Ich habe das schon einige Monate nicht geprüft, aber meiner Meinung nach
wird der Backup-MX von vielen Bots sogar zuerst versucht, um die härteren
Möglichkeiten des primär zuständigen Servers zu umgehen. Bist Du sicher,
dass die Bots das nicht mehr machen? Dann könnte man ja durch MXe ins
Nirvana schon die meisten Spams loswerden...
--
lg,
Roland

Roland M. Kreutzer

unread,
Dec 13, 2007, 5:09:57 AM12/13/07
to
Wolfgang Kueter wrote:
> Die Bots scheinen definitiv entweder oder zu versuchen, beide Mailserver
> versuchen nur ganz wenige. Mal sehen, vielleicht bau ich mal was, um das
> mal über den Zeitraum von einigen Stunden auszuzählen.

Mach dazu drei MXe, zb 1 (unerreichbar), 2 (annehmender SMTP), 3
(unerreichbar). Ich bin sicher, dass viele Bots 1 und 3 angehen (bei meinem
letzten Test waren am dritten mehr als am ersten). Die Bots versuchen sich
also meist am letzten der Kette, der die wenigste "Nähe" zum Hauptserver
hat, also weniger prüfen kann. Normale Mailserver sollten von Versuch auf 1
gleich zu Versuch auf 2 gehen.

BTW. ist ein MX oberhalb deines zweiten Servers wohl auch wieder eine gute
Möglichkeit, weiter zu filtern...

Bin gespannt auf Deine Ergebnisse.
--
lg,
Roland

Bodo Eggert

unread,
Dec 13, 2007, 5:33:14 AM12/13/07
to
Bernd Hohmann <trap20...@spamonly.net> wrote:
> Lutz Donnerhacke wrote:

>> Im gewerblichen Umfeld, interessiert es den Kunden nicht, ob seine
>> Geschäftspartner bescheuert, blöd oder unfähig ist, sondern ob er von ihm
>> Mails wie bisher empfangen kann.
>
> Das Problem ist zunehmend dem eigenen Kunden klarzumachen dass es nicht
> bei einem selber klemmt sondern die Mails von der Gegenseite überhaupt
> nicht oder nur mit massiver Verzögerung ausgeliefert werden.
>
> Typischerweise passiert das dann, wenn der bisherige Fileserver erst
> Router, dann NAT-Gateway und zum Schluss noch Mailserver spielen muss -
> das Ganze natürlich auf dem 19,95 EUR DSL-Tarif von Anbieter
> "Schlagmichtot".
>
> Typische Antwort "Es geht sonst immer" und "Wieso, ist doch ne
> Standleitung?"

Jein. Wer heutzutage was anderes als DSL für Standleitungszwecke nutzt, der
ist mit einem Klammerbeutel gepudert, in dem man die Klammern duech Hufeisen
ersetzt hat. Feste IP und korrekte Auflösung ohne generische Namen sollten
dann aber zur Abgrenzung von Virenschleudernden Home-PCs ausreichen.

Bodo Eggert

unread,
Dec 13, 2007, 5:12:06 AM12/13/07
to
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Wolfgang Kueter wrote:
>> Andreas M. Kirchwitz wrote:

>>> Beispielsweise Reverse DNS. Bei vielen (meist kleinen) Firmen,
>>> die mit ihrer IT noch auf Kriegsfuß stehen, ist das leider oft
>>> ein Problem.
>>
>> Was hindert solche Firmen, wenn sie denn einen eigenen Mailserver betreiben,
>> für den Versand von Mail einen Mailserver ihres ISP als Smarthost zu
>> verwenden?
>
> Eingehend wird über einen Spamausfilterdienstleister per MX empfangen.
> Ausgehend sendet jede Zweigstelle direkt über den lokalen DSL Anschluß mit
> dynamischer oder fester IP. Bei fester IP ist i.d.R. kein reverse DNS seitsn
> des ISP eingerichtet.

Und bei dynamischer IP ist eine Übereinstimmung eine Garantie dafür, daß es
sich um einen Spambot handelt.

Bastian Blank

unread,
Dec 13, 2007, 4:38:36 AM12/13/07
to
Bodo Eggert wrote:
> Unabhängig davon, daß dieses Setup nicht schön ist oder bei Verbreitung
> wirksam bliebe: Ich würde den niedrigsten MX wieder auf mail01 legen,
> damit die Spammer, die auf dem Backup-MX einliefern wollen, auch nicht
> mehr durchkommen.

Und wenn man es zu weit treibt, bekommt man keine Mails mehr, weil die
Sender-MTAs die Anzahl der anzuschauenden MXe auf ein sinnvolles Maß,
bei Postfix AFAIK 5, begrenzen und im Zweifel auch die Daten aus
truncated DNS-Antworten verwenden.

Bastian

Bastian Blank

unread,
Dec 13, 2007, 4:41:10 AM12/13/07