Schutz für Firmen-Accounts mit eigenem E-Mail Server

[CNE-Hamburg]

Speziell für kleinere und mittlere Firmen.
Wie schütze ich meinen EIGENEN Mail-Server.
1.: Aktivieren Sie den Mail Bomb Schutz
Setzen Sie den Schwellwert auf 10 Mails in 5 Minuten vom gleichen Absender
Dies schützt vor s.g Bouncern, d.h ein Absender schickt an
abcd@Ihrefirma.de
abcde@Ihrefirma.de
efgh@Ihrefirma.de etc.
er geht also einfach Namenskombinationen durch, auf diese Weise wurden z.B. an ein Forschungsinstitut in Hamburg bis zu 10.000 Mails am Tag
gesendet.
2.: Viel effektiver aber sehr restriktiv: führen Sie VOR Annahme einer Mail eine DNS Verification des Absenders durch.
Jeder verantwortungsvolle Mail Server Admin sollte seinen Mail Server nicht nur mit einem DNS Eintrag versehen sondern auch mit
einem PTR-Record / In-ADR-ARPA Eintrag bei dem Internet Service Provider für die IP Adresse des Mail Servers.
Wenn der Absendende E-Mail Server über keinen PTR Record vefügt, der korrekt auf seine Domain und IP Adresse verweist
(ca 99,9995% aller Spam Sender) wird die Annahme der E-Mail verweigert und der Absnder bekommt eine entsprechende
SMTP Fehler Meldung zurück, in der Regel SMTP 504 DNS Verification faild, no mail will be accepted ! This is a permanent Error !
Diese Vorgehensweise schützt zwar vor nahezu ca 99,9995% der SPAMs, hat aber einen kleinen Nachteil:
Es kann passieren, daß der Server Betreiber eines " Erwünschten Absenders " seine Mail Server vergessen hat mit einem PTR Record zu versehen.
In dem Falle erhält der "Erwünschte Absender" die o.g. Fehlermeldung in seinen Mail Ordner.
Sie müssen dann entweder den "erwünschten" Mail Admin dazu bringen für seinen Mail Server bei seinem ISP eine PTR Record zu erzeugen, oder
sie tragen den erwünschten Mail Sender in eine s.g. white list ein, dies ist in diesem Falle einfach der DNS Table Ihres Mail Servers.
Standardmäßig finden Sie diese im Verzeichnis etc als Datei HOSTS . Diese Anpassungen können 1 bis 2 Wochen erforderlich sein, danach läuft
Ihr Mail Server nahezu wartungsfrei.
Die Lösung 2 habe ich erfolgreich beim Kunden getestet, in 3,5 Jahren Betrieb des Mail Servers sind insgesammt 3 , in Worten: DREI, SPAM Mails
durchgekommen. Ale erwünschten Mails sind angekommen. Auf dem Mail Server war daher auch kein SPAM Filter installiert, denn der wird erst aktiv wenn die Mail angekommen ist, die Lösung 2 verhindert aber das Ankommen der SPAM Mails.
Wenn Sie Fragen haben , wie Sie diese Lösung bei Ihrem System realisieren können stehe ich gerne zur Verfügung.

Dietmar Kaun
Certified Novell Engineer ( CNE )
Hamburg

[DocSnyder]

Viel effektiver aber sehr restriktiv: führen Sie VOR Annahme einer Mail eine DNS Verification des Absenders durch.
Jeder verantwortungsvolle Mail Server Admin sollte seinen Mail Server nicht nur mit einem DNS Eintrag versehen sondern auch mit
einem PTR-Record / In-ADR-ARPA Eintrag bei dem Internet Service Provider für die IP Adresse des Mail Servers.

PTR-Records sind zwar sehr wünschenswert, in der Praxis gibt deren Vorhandensein aber so gut wie keine Aussagekraft darüber, ob es sich um einen Spam-Zusteller handelt oder nicht. Auch legitime Korrespondenten sind oft zu faul, PTR-Records einzurichten. Spam hingegen kommt fast immer von IPs mit korrektem PTR. Gegen Spam, der über offizielle Mailrelays großer ISPs verschickt wird, z. B. was eine gewisse Laura gerne praktiziert, helfen solche Maßnahmen Null komma niente.
Mails ohne PTR kann man im SpamAssassin einen halben Punkt nach oben scoren, aber mehr schon nicht und hart blocken schon gar nicht. Es gibt viel effektivere und weniger riskante Maßnahmen. Eine davon ist SPF, was inzwischen nicht mehr ganz unbedeutend ist. Man muss nur seiner SPF-Bibliothek ein paar Fallbacks mitgeben, da z. B. die von der ReverZ-Mafia genutzten Domains keine SPF-Einträge enthalten. Diese kann man dann "erraten" und hinterlegen. Ähnliches für Ebay, Paypal, Suntrust und was sonst an Phishing-Zeug hereinkommt.
Weiterhin empfiehlt sich, nicht nur die Sender-Domain, sondern auch das HELO gegen SPF zu prüfen und überhaupt dem HELO nicht zu wenig Aufmerksamkeit zukommen zu lassen. Fake-HELOs (insbesondere HELO == Empfänger-IP oder Empfänger-Hostname oder Empfänger-Domain) können per se nur von verwurmten Windoofkisten oder offenen Proxies kommen, deren IP man schon beim ersten Versuch in die Blacklist stecken kann.
BTW bei Bouncern kenne ich keine Gnade: wenn von derselben IP mehr als x Bounces mit leerem Absender (DSN) an eine Spamtrapadresse kommen, wandert die ganze IP in die Blacklist. Spamhaus handhabt dies ähnlich und listet Bouncer sogar in der SBL.

Certified Novell Engineer ( CNE )

Achso... na gut. Ich hätte eher auf einen Lotus-Domino-Spezialisten getippt.
/.
DocSnyder, Postfix unter Debian GNU/Linux einsetzend.
--
Friss, Spammer, friss: http://docsnyder.de/spl/forum/

[CNE-Hamburg]

Naja, in 3,5 Jahren 3 SPAM-Mails angekommen scheint schon recht erfolgreich
>"PTR-Records sind zwar sehr wünschenswert, in der Praxis gibt deren Vorhandensein aber so gut wie keine Aussagekraft darüber,
> ob es sich um einen Spam-Zusteller handelt oder nicht."
Wer bei seinem Internet Service Provider einen PTR Record für die Absende IP beantragt muss dafür quasi seinen Personalausweis vorlegen,
das wird ein SPAM Mailer selten tun.
Der PTR Record muss mit den Daten im HELO über die Absende Domain übereinstimmen bei der Funktion. Das sollte eigentlich für alle
Würmer und Trojaner, die eine eigene SMTP Engine mitbringen, als Filter ausreichen.
Beispiel
Betreff: Like Music? Movies? Games? Download Them Free Now. - promiscuity
Von: Kaazaa Equivalent <sales@prizedjobs.com>
Auflösung zu prizedjobs.com = 209.120.245.218
Rückwertige Auflösung 209.120.245.218 = atlas.rapidns.com
Stimmt nicht überein, also : SMPT 504 DNS verification failed, no mail will be accepted, Und Tschüß !

> "Auch legitime Korrespondenten sind oft zu faul, PTR-Records einzurichten."
Ja warum eigentlich ? Ich hab die Erfahrung gemacht daß sie nicht zu faul sind sondern es nicht wissen.
Dabei handelt es sich auch in großer Zahl um Linux "Profis" die mal auf die Schnelle beim Kunden einen Mail Server einrichten.
Die Prüfung beginnt schon beim ersten HELO, also bevor überhaupt eine Mail gesendet wird.
> "Mails ohne PTR kann man im SpamAssassin einen halben Punkt nach oben scoren, aber mehr schon nicht und hart blocken schon gar nicht"
Es wäre wünschenswert, daß für die gängigen Mail Server die entsprechenden Einstellungen mal zusammengestellt werden.
Bei SendMail soll es direkt in der Konfiguration des SendMails selber gehen, muß ich mal beim EMBL Server Admin nachfragen, bei Novell GroupWise E-Mail und GroupWare Server, den es auch für Linux gibt / geben wird sind es nur 4 Mouse Clicks in Konfigurations Prgramm; wer lieber auf der Console hackt kann es auch von Hand in die config Datei eintragen :-)
> "Gegen Spam, der über offizielle Mailrelays großer ISPs verschickt wird..."
Open Relays sollte man generell blocken.

[Fidul]

>> "Gegen Spam, der über offizielle Mailrelays großer ISPs verschickt wird..."
> Open Relays sollte man generell blocken.
Das sind allerdings keine Open Relays. Die Mails werden per Virus/Proxy "regulär" über einen Kunden des Providers verschickt.
--
Wir kriegen euch alle!

[mattes]

Hallo,

Naja, in 3,5 Jahren 3 SPAM-Mails angekommen scheint schon recht erfolgreich

mhmm, ohne eine Relation, wie viele Versuche es gegeben hat, ist diese Aussage relativ nichtssagend.
Wenn schon Sender-Verification, dann Adress-Verification mit Call-Out. Bis auf wenige - falsch konfigurierte - Sender gibt es damit auch kaum False-Positives oder andere Probleme. Bei uns werden damit und mit Recipient-Verification schon ca. 85% (von ca. 900k SMTP-Verbindungen p. Monat) rejected.
Danach kommen diverse DNSBLs (auch Reject), Viren- und Mime-Check (Blackhole), eine RegEx-Liste mit knapp 100 Einträgen, BATV, SPF-Check und der SpamAssassin (Quarantäne bzw. Markierung).
Das Schöne beim Rejecten ist, daß die "Verschmähten" sich recht häufig sofort dem Secondary-MX zuwenden. Und der ist ein Jackpot (Teergrube/Honeypot) :-)
Trotzdem sind unter den etwa 30.000 durchkommenden Nachrichten im Monat noch immer etwa 1-2.000 [1] "unerwünschte".
Selbst diese 1-2 Promille [2] sind noch lästig.
Grüße
mattes
[1] Vor allem, weil der SpamAssassin recht lax eingestellt ist. Bis 8er SpamScore markiert er bei uns nur.
[2] Ausgehend von den Verbindungsversuchen, in Wahrheit ist der Anteil ja viel niedriger, da bei einem Verbindungsversuch eines Spammers selten nur an einen Recipient zugestellt wird
--
http://www.nervmich.net

[josef]

Hallo Doc und alle anderen.
Dieses Forum hat mir schon einiges über Spam beigebracht. Ich muss bei bestimmten Begriffen zwar immer wieder Google heranziehen um Schlauer zu werden, aber immerhin "ich bin schlauer geworden".
Sicher noch nicht ganz....
Eine IP Adresse ist weltweit eindeutig! oder?
Eine E-Mail Adresse auch? oder?
Nur hilft das recht wenig, wenn niemand weiß wer hinter einer abc123@xxxmail.com stekt.
SPF-Einträge können da hilfreich sein. Schlau gemacht habe ich mich auf Seite http://www.baschny.de/spf/howithelps.html
Aber ein Allheilmittel ist das auch nicht. Ich denke an meinen Urlaub z.B. wenn ich in Alaska meine E-Mails prüfen und beantworten möchte dann funktioniert das nicht mer? oder???
Eine Absolut verlässliche methode wäre: Die Signierte E-Mail.
Der Provider vergiebt mit der E-Mail adresse auch ein Passwort das den Versender eindeutig Identifiziert. Der Provider Prüft das Passwort und Sendet weiter mit dem Vermerk E-Mailversender identifiziert. Ohne dessen Identität ohne vorliegen einer sittenwiedrigen oder strafbaren Handlung preiszugeben.
Das wäre eventuell ein ganz neues Diskussionstema.

[DocSnyder]

Eine IP-Adresse ist weltweit tatsächlich eindeutig, mit Ausnahmen der privaten Netzblöcke (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) und Sonderbereichen (0.0.0.0/8, 224.0.0.0/3), die im Internet nicht geroutet werden. Allerdings beherrschen einige Schurken das Handwerk, über die Ausnutzung von Fehlern in Routerprotokollen IP-Netzbereiche umzuleiten ("Hijacking"). Die Adressen sind dann immer noch eindeutig, allerdings nicht mehr in der Gewalt dessen, der sie eigentlich bedienen sollte.
Eine E-Mail-Adresse besteht aus Localpart und Domainpart. Letzterer ist weltweit eindeutig. In der Domainkonfiguration wird als "MX-Eintrag" ein Host hinterlegt (oder mehrere), der für die Annahme von E-Mail zuständig ist. Dieser weiß, welche Localparts gültig sind. Sofern nur ein MX Mail annimmt oder mehrere gleich konfiguriert sind (was der Fall sein sollte), sind auch die Localparts und somit die ganze E-Mail-Adresse eindeutig.
Wenn du in Alaska Urlaub machst und deine E-Mails beantworten möchtest, obwohl dein Domainpart mit SPF geschützt ist, gibt es dafür die Möglichkeit, per authentifizierter SMTP-Session über den für dich zuständigen Mailprovider zuzustellen. Du gibst dann in der SMTP-Session Benutzerkennung und Passwort an, und der Provider leitet deine Mails an den eigentlichen Empfänger weiter. Prüft dieser nach SPF, zählen die IP-Adressen des Providers, die im SPF-Eintrag nach wie vor als zulässig bekannt gegeben werden.
Ideen für alternative Zustellmethoden gibt es immer wieder. Ich hatte vor einiger Zeit die Idee, über eine per Public Key authentifizierte Session direkt zuzustellen, wobei die Identität des Absenders überprüft werden kann. Dabei wird natürlich die Anonymität geopfert, was aber den Vorteil hat, dass man auf diese Art auch Behördengeschäfte erledigen könnte. Außerdem hat der Absender die Gewissheit, dass der Empfänger die jeweilige Mail bekommen hat.
Ein ganz großes Problem verschafft sich die Internet-Community selbst: die stoische Festklammerung an teils uralten RFCs und ein sehr aufwändiges und wenig aussichtsreiches Verfahren, Änderungen einzureichen. Spammer scheren sich bekanntlich überhaupt nichts um Standards. Vor kurzem habe ich im Usenet den Vorschlag genannt, über 59x-Fehler automatische Spam-Alerts auf der Gegenseite auszulösen, damit ISP sofort merken, wenn sie unfreiwillig zum Spamversender werden. Schließlich entscheidet nur die erste Ziffer der SMTP-Antwort über den Zustellerfolg, die zweite und dritte können zusätzliche Informationen liefern, beeinflussen die Reaktion des absendenden Systems aber in keinster Weise. Nach einigen Tagen intensiver Popcornschlacht kam ich zu der Erkenntnis, dass es keinen Wert hat, über weitere Gimmicks nachzudenken, solange aus so einer Kleinigkeit ein derartiges Trara entsteht. Und dies fand nur im deutschsprachigen Usenet statt - international wäre die Reaktion viel heftiger ausgefallen.
/.
DocSnyder.
--
Friss, Spammer, friss: http://docsnyder.de/spl/forum/

[josef]

Wie kann ich meine Domain bzw. E-Mailadressen nach SPF Registrieren? Mein Mailserver ist bei meinem Provider. Ich könnte einen eigenen Mailserver konfigurieren, da ich von meinem Provieder eine Fixe IP zugewiesen bekommen habe. Ich möchte mich allerdings damit nicht belasten.
__________________________________________________
Habe in der zwischenzeit mit meinem Provider gesprochen, musste bis zum technischen Leiter vordringen bis jemand was wuste von SPF.
Der hat gemeint ich breuchte nur meine Daten Mailen dann wird er eine SPF Registrierung veranlassen.

[DocSnyder]

Man braucht dazu nur einen TXT-Eintrag in der Zonendatei der jeweiligen Domain. Diese kennzeichnet mit einer auf den ersten Blick kryptisch anmutenden Zeichenfolge, von wo aus Mail mit dieser Domain als Absender versandt werden darf.
Beispiel: docsnyder.de
$ host -t TXT docsnyder.de
docsnyder.de text "v=spf1 ip4:213.133.101.176/32 ip4:213.239.199.73/32 -all"
Man sieht, dass Mails mit meiner Domain als Absender nur von meinen beiden Serverlein ("ip4:$adresse/$netzmaske") kommen dürfen und sonst von nirgends ("-all"). In der Zonenkonfiguration sieht dies dann etwa so aus:
--- /etc/bind/master/for/docsnyder.de
[...]
@ IN TXT "v=spf1 ip4:213.133.101.176/32 ip4:213.239.199.73/32 -all"
---
Woanders muss SPF nicht registriert werden.
Auswirkungen sind übrigens durchaus spürbar. Ich hatte ohne SPF-Tags immer wieder mal Bounces, wenn Spammer Empfängeradressen als Fake-Absender benutzten und irgendwelche Mailserver das Zeug annahmen und bouncten (auch "Backscatter" genannt). Solche Fälle gibt es zwar immer noch, aber ich habe das Gefühl, dass sich die Bounce-Quote mit SPF reduziert hat. Außerdem hat man dann bei Backscatter einen guten Grund, die Bounces selbst per Fehlermeldung abzuweisen.
/.
DocSnyder.

--
Friss, Spammer, friss: http://docsnyder.de/spl/forum/

[josef]

Hallo Doc
Ich finde diese Zonendatei leider nicht.