Theraphosinae

Lasiodora Klugi

Die Theraphosinae ist die artenreichste Unterfamilie innerhalb der Vogelspinnen und beinhaltete annähernd 425 Arten und 52 Gattungen (Stand 2003). Viele kleine Arten wurden früher zu den Ischnocolinae gezählt. Weil diese Arten aber Reizhaare und einen gekielten Embolus enthalten, werden sie heute in die Unterfamilie Theraphosinae gestellt.

Verbreitung

Diese Unterfamilie beinhaltet ausschließlich amerikanische Arten.^[1] Das Verbreitungsgebiet der Theraphosinae erstreckt sich auf dem amerikanischen Doppelkontinent von den USA südwärts bis nach Südamerika.

Merkmale

Die Körperlängen der Spezies variieren von 12 mm (z. B. Apachepelma paloma) bis 11 cm (Theraphosa blondi).^[1]. Vertreter der Unterfamilie Theraphosinae werden auch als „Bombardierspinnen“ bezeichnet, und auch nur die Vertreter dieser Unterfamilie. In der Unterfamilie kommen keine baumbewohnenden Arten vor; baumbewohnende Vogelspinnen aus dem gleichen Verbreitungsgebiet gehören zu den Aviculariinae und Selenocosmiinae Simon, 1889.

Verhalten

Das Verhalten der Arten in dieser Unterfamilie ist sehr vielfältig. Einige Arten bauen tiefe Röhren in das Erdreich, andere leben unter Baumwurzeln, Rindenstücken oder Steinen. ^[1]

Es gibt sehr defensive Arten, insbesondere die Gattungen Theraphosa, Acanthoscurria und Phormictopus.^[1] Bei Störungen ziehen sie sich sehr schnell in ihre Wohnröhre bzw. -höhle zurück. Häufig bewerfen die Bombardierspinnen unter den Theraphosinae den Angreifer mit ihren Brennhaaren. Haben sie nicht die Möglichkeit zum Rückzug, gehen sie in Verteidigungs-/Drohstellung. Werden sie weiter provoziert, schlagen sie in der Regel erst drei- bis viermal mit den Vorderbeinen und den Tastern nach dem Angreifer, bevor sie zubeißen.

Unter den Theraphosinae-Arten gibt es aber auch sehr friedfertige Gattungen, wie z. B. Eupalaestrus, Grammostola oder Brachypelma.^[1]

Das Nahrungsspektrum der Theraphosinae ist abhängig der Körpergröße und des Verbreitungsgebietes der einzelnen Art und beinhaltet so eine große Auswahl von Beutetieren von Insekten bis Schlangen.

Quelle:

http://de.wikipedia.org/wiki/Theraphosinae

>>Einige Bilder zu dieser Spinne gibt es hier!<<

Goliath-Vogelspinne

Die Riesenvogelspinne (Theraphosa blondi), oder auch Goliath-Vogelspinne, gilt mit bis zu 12 Zentimeter Körperlänge und einer Beinspannlänge von bis zu 30 Zentimeter lt. Guinness-Buch der Rekorde als die größte Vogelspinne der Welt. Sie ist stark behaart, und ihre Färbung ist rost- bis kastanienbraun. Weibchen können ein Gewicht von bis zu 170 Gramm erreichen.

Adulte Männchen sind weniger kräftig gebaut als weibliche Exemplare und sind oft dunkler gefärbt. Im Gegensatz zu vielen anderen Vogelspinnenarten tragen die Männchen der Riesenvogelspinne am ersten Beinpaar keine Schienbeinhaken (Tibiaapophysen).

Die Cheliceren der Riesenvogelspinne erreichen eine Länge von ca. 2,5 Zentimeter und das Abdomen kann in Gefangenschaft bei übermäßiger Fütterung die Größe eines Tennisballs erreichen. Oft ist die Behaarung des Abdomens unvollständig, da sie ihre Wohnröhre regelmäßig mit Brennhaaren tapeziert.

Diese Tiere stammen aus dem tropischen Regenwald Südamerikas, wo sie besonders im nördlichen Teil Brasiliens, in Venezuela und Guyana vorzufinden sind. Die Luftfeuchtigkeit beträgt in ihrem natürlichen Lebensraum ca. 80 bis 95 % bei einer Temperatur von 25 bis 32 °C. Wobei das Mikroklima in den Bauten sich vom Makroklima etwas unterscheidet.

Die Riesenvogelspinne bevorzugt feuchte Gebiete. Dort gräbt sie tiefe Wohnhöhlen in die Erde, damit sie in Trockenzeiten eine ausreichend feuchte Rückzugmöglichkeit hat.

Sie ist eine Bombardierspinne, die vor dem Abstreifen der Brennhaare Warnlaute erzeugt, sog. Stridulieren.

Bei der Paarung sind die Weibchen weniger aggressiv als ihr allgemeines Verhalten erwarten lässt. Ein Kokon enthält ca. 100 bis 150 Eier. Die Jungtiere sind beim Schlüpfen bereits 1,5 bis 2 cm groß.

Bei einigen südamerikanischen Ureinwohnern wird Theraphosa blondi als Proteinquelle genutzt. (Der Geschmack soll dem von Langusten oder Krabben ähneln; näheres siehe Entomophagie beim Menschen)

Quelle:

http://de.wikipedia.org/wiki/Goliath-Vogelspinne

>>Einige Bilder zu dieser Spinne gibt es hier.<<

Bei der Vogelspinne Avicularia versicolor (dt.: „Martinique-Baumvogelspinne“) (Walckenaer, 1837) handelt es sich um eine sehr oft im Terrarium gehaltene Art der GattungAvicularia. Diese Art wurde im Jahr 1837 durch Baron Charles Athanasie Walckenaer beschrieben. Ihre Heimat ist Martinique. Die weiblichen Tiere werden 4–6 cm groß, wobei es teilweise Exemplare gibt, welche 7–8 cm groß geworden sind. Die Männchen bleiben oft mit ca. 2–4 cm deutlich kleiner. Als Jungtiere (Spiderlinge) haben sie die typische Avicularia-Jugendfärbung. Das ganze Tier schimmert metallisch-blau. Ab dem 4. bis 5. Nymphenstadium färben sich die Jungtiere langsam um. Mit jeder weiteren Häutung ähneln sie den erwachsenen Tiere mehr. Diese haben einen dunklen Hinterleib mit roter Behaarung. Die Beinbehaarung ist ebenfalls rötlich. Das Kopf-Bruststück (Carapax) schimmert grün-bläulich.

Verhalten

Diese Spinnenart ist sehr friedlich, gutmütig und dämmerungs- bzw. nachtaktiv. Je älter sie wird, desto ruhiger wird sie. Im Laufe der verschiedenen Entwicklungsstufen (Häutungen) sind jedoch starke Verhaltensänderungen zu erleben. Während sie in dem einen Stadium noch sehr scheu sein mag, kann sie bereits nach der nächsten Häutung schon sehr „neugierig“ und „interessiert“ sein.

Sie lebt in einem seidigen Wohngespinst, welches sie – wenn möglich – mit Hilfe von Pflanzen oder Ästen tarnt. Sie hält ihr Haus immer von Unrat rein, in dem sie sich sowohl zum Entsorgen von Essensresten als auch zum Koten außerhalb ihrer Wohnhöhle aufhält. Sie ist sehr reinlich, was sich besonders nach dem Fressen beobachten lässt: Dann nämlich werden ihre Cheliceren und ihre Pedipalpen ausgiebig gereinigt.

Sie ist eine ausgezeichnete Jägerin, die besonders auf Fluginsekten (z. B. „dicke Brummer“) interessiert reagiert. Da lässt es sich schon mal beobachten, wie sie am helllichten Tag langsam aus ihrem Gespinst gekrabbelt kommt und sich ans Opfer anpirscht. Sollten anfängliche Versuche des Fangens fehlschlagen, wird man ihre sehr schnellen Reaktionen zu sehen bekommen: Dann läuft sie hinter ihrer Beute her und springt sogar manchmal von den Wänden auf Äste oder fällt schon mal auf den Boden. Avicularia versicolor ist eine baumbewohnende Vogelspinne, die im Jungtieralter auch häufig und gerne weite Sprünge ausübt. Diese Verhaltensweise verliert sich mit zunehmendem Alter.

Bedrängt man diese Spinne, wird sie als erstes versuchen, sich zurückzuziehen und die Flucht ergreifen, bzw. sich flach auf den Boden drücken, die Beine an den Körper ziehen und reglos verharren. Falls ihr all dies nicht möglich sein sollte, hat sie zwei verschiedene Abwehrmechanismen:

1. Sie beschießt ihren Feind mit Kot (wobei sie ca. 30 cm weit noch treffen kann)
2. Sie hat Brennhaare auf dem Hinterleib (sieht man auf Fotos immer als Fleck in der Mitte des hinteren Teils des Abdomen). Sie streckt ihr Hinterleib einem Angreifer entgegen.
3. Sollten die anderen Verteidigungsmethoden nicht wirken, beißt sie auch zu.

Fortpflanzung

Zu Paarungszwecken im Terrarium sollte das Männchen zum Weibchen gegeben werden. Dieses wird, sobald es das Gespinst des Weibchens berührt, anfangen mit den Tastern (Padipalpen) zu Trommeln. Ist das Weibchen paarungswillig wird es ebenfalls Trommeln und dem Männchen entgegengehen. Ist das Weibchen nicht willig und der Bock geht dennoch näher an das Weibchen heran, landet er meistens als Zwischenmahlzeit, auch bei sehr gut gefütterten Weibchen, im Magen. Ist das Weibchen paarungswillig, besteht die nächste Hürde für den Bock darin, an die Geschlechtsöffnung zu gelangen. Diese liegt zwischen den ersten Lungenpaar auf der unteren Seite des Hinterleibs. Gelingt es dem Bock nicht das Weibchen hochzustemmen, wurde bereits beobachtet, wie sich das Weibchen auf die Seite legt oder selbstständig aufrichtet, um dem Bock den Paarungsakt zu erleichtern. Nach der Paarung sollte das Männchen wieder in sein eigenes Terrarium gesetzt werden. Ein längeres Zusammenleben endet für den Bock nach etwa ein bis zwei Wochen tödlich. Hat das Weibchen dann einen Kokon gebaut, kann man sich auf 50 bis 300 Jungtiere freuen. Die Aufzucht bereitet in der Regel keine Probleme. Es kommt meistens nur bei zu viel oder zu wenig Feuchtigkeit zu Komplikationen, zum Beispiel bei der Häutung.

 

Quelle:

http://de.wikipedia.org/wiki/Avicularia_versicolor

>>Hier nun einige Bilder zu der Spinne<<

Debian Lenny, dovecot 1.2, quota 1.1, MySQL und Quota Warnings.

Ich habe vor kurzem vor dem Problem gestanden meinen dovecot mailboxen quotas aufzuerlegen. Die Anleitung von: http://wiki.dovecot.org/Quota/1.1 war sehr hilfreich, funktioniert aber leider mit meiner Konfiguration nicht sofort.

Ich wollte folgendes erreichen:
–    Alle Mailboxen haben im Standard eine quota von maximal 512MB.
–    Jeder Mailbox kann ich dynamisch mehr oder weniger Platz zur Verfügung stellen.
–    Die Benutzer sowie der Admin sollen frühzeitig Warnmeldungen bekommen, wenn der Platz eng wird.

Als erstes musste eine etwas aktuellere Version vom dovecot (Taubenschlag) auf den Lenny Server. Glücklicherweise findet sich die Version 1.2 schon in den Backports. Diese waren schnell eingebunden!

echo "deb http://www.backports.org/debian lenny-backports main contrib non-free" >> /etc/apt/sources.list
apt-get update && apt-get install debian-backports-keyring && apt-get update
apt-get –t lenny-backports install dovecot-common

Nach der Installation erweiterte ich meine /etc/dovecot/dovecot.conf um die folgenden Einträge in den jeweiligen Sektionen.

protocol imap {
mail_plugins = quota imap_quota
}

 

protocol lda {
mail_plugins = sieve quota
quota_full_tempfail = yes
}

Hier ist zu beachten das in der neueren dovecot Version das sieve Plugin nicht mehr cumsieve heist! Damit E-Mais bei vollem Postfach nicht sofort zurückgewiesen werden, sondern mit einem temporären Fehler (so hat der Postfachbesitzer etwas mehr Zeit sein Postfach aufzuräumen), gibt es den 2. Eintrag.

plugin {
quota = dirsize:User quota
quota_rule = *:storage=512M
quota_warning = storage=80%% /usr/local/bin/quota-warning.sh 80 %u
quota_warning2 = storage=95%% /usr/local/bin/quota-warning.sh 95 %u
quota_warning3 = storage=99%% /usr/local/bin/quota-warning.sh 99 %u
}

Hier gebe ich nun an das ich als Backend, also über welche der möglichen Lösungen ich den Speicherplatz „berechnen“ möchte. Zudem gebe ich an, das jede Mailbox default 512MB Platz hat.
Quota_warning… Ruft jeweils bei 80%, 95% und 99% Mailboxauslastung das Script /usr/local/bin/quota-warning.sh auf.

Das Script muss man selbst anlegen. Das script im dovecot-wiki hat bei mir nicht so ganz funktioniert, es wurden keine quota_warnings generiert, versendet oder wie auch immer. Daher habe ich es etwas umgeschrieben und als weitere Übergabewert mir noch die betreffende E-Mailadresse des Postfaches mit übergeben lassen „%u“. Zusätzlich wollte bei mir (warum auch immer /usr/sbin/sendmail) nicht funktionier. Daber habe ich auf Heirloom Mailx zurückgegriffen (apt-get install heirloom-mailx). Mein script ist ausführbar (chmod +x /usr/local/bin/quota-warning.sh) und gehört dem Benutzer sowie der Gruppe vmail (chown vmail:vmail /usr/local/bin/quota-warning.sh). Es schaut nun so aus:

#!/bin/bash
PERCENT=$1
USER=$2
FROM=" <a href="mailto:%3Ca%20href=" mailto:sebastian="" vandemeer="" de="">sebastian@vandemeer.de"><a href="mailto:sebastian@vandemeer.de">sebastian@vandemeer.de<span style="display: none;">This e-mail address is being protected from spambots. You need JavaScript enabled to view it. "
qwf="/tmp/quota.warning.$"
echo "
(for English version please see below
Liebe(r) Mailsystem Benutzer(in
ihr E-Mail Postfach $USER ist jetzt zu  $PERCENT% voll.
Fuer Informationen senden Sie eine E-Mail an: sebastian@vandemeer.de">sebastian@vandemeer.de

Ab jetzt läuft das Thema Quota schon. Es lässt sich auch testen. Für alle jeweils 512MB.

Jetzt möchte ich natürlich in meiner mysql Datenbank den einzelnen Mailboxen mehr oder weniger Platz zuweisen können! Diesen Teil kann man für seine eigene Konfiguration aber nur dann so wie jetzt beschrieben übernehmen, wenn die Benutzerauthentifizierung wie bei mir funktioniert. Hier habe ich etwas länger gehangen bis ich eine funktionable Lösung hatte. Wer hier auch hängt: http://www.gidf.de/ vielleicht kann ich auch helfen (e-mail)!
Ich musste bei mir meine dovecot-sql.conf um die folgende Zeile erweitern:

>>Klick mich<<

Dann habe ich in der dovecot.conf den Teil auskommentiert:

#  userdb static {
#    # Template for the fields. Can return anything a userdb could normally
#    # return. For example:
#    #
#    args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes
#    #
#    #args =
# }

Und durch diesen hier „ersetzte“:

userdb prefetch {
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

In meiner Datenbank habe ich dann ein neues view angelegt, und vorher meiner Tabelle virtual_users ein neues Feld quota_kb spendiert:

CREATE VIEW view_users_quota AS select concat(`virtual_users`.`user`,_latin1'@',`virtual_domains`.`name`) AS `email`,`virtual_users`.`quota_kb` AS `quota_kb`,`virtual_users`.`password` AS `password` from (`virtual_users` left join `virtual_domains` on((`virtual_users`.`domain_id` = `virtual_domains`.`id`)));

Dieses view sammelt sich aus meinen anderen Tabellen die passenden Informationen zusammen und erbricht bei einer Abfrage gleich auch die Quota infos:

>>klick mich<<

Jetzt klappt es auch mit den dynamisch zugeteilten quotas. Dafür habe ich aber etwas gebraucht *lach*!

Als Webmailser setzte ich roundcube ein. Dieser zeigt einem sogar in einer lustigen Statusleiste wieviel Platz gerade „verschwendet“ wird. Dieser Statusbalken hat mir (quick and dirty) beim Testen sehr geholfen :-P! Zudem kann roundcube mit sieves-filtern bessern umgehen als alle mir (derzeit) bekannten Mailclients!

---

*Update*

Da gibt es etwas neues. Man muss natürlich nicht unbedingt über den view gehen. Ich habe ein weiteres System neu aufgesetzt. Alles läuft nun über /var/vmail und die sql user query schaut nun so aus: >>klick mich<<

Ne ne ne… im Grunde müsste ich das alles noch einmal neu schreiben 😛 Wenn ich dafür nur die Zeit hätte!

Zu überprüfen ob die Angaben des Absenders, des Empfängers oder der Clients stimmen, ist für Postfix recht einfach. Es ermöglicht das schnelle „Ausfiltern“ von Spam- und Virenversendern.

Als Beispiel:

Wenn jemand versucht eine E-Mails an mich zu verschicken, und als Absender eine Domain angibt, die im DNS keinen A-Record oder keinen MX eingetragen hat, werde ich auf diesen Absender niemals antworten können. Eine solche E-Mail kommt fast ausschließlich von Viren- und Spamversendern, welche sich Absenderdomains ausdenken müssen. Ähnlich verhält es sich mit der Angabe des Clienthostnames. Ordentlich konfigurierte Mailserver melden sich mit ihrem FQDN und der Revers-DNS Eintrag passt zu diesem. Gekaperte Rechner eines Botnetzes melden sich maximal mit dem Namen, welcher vom Besitzer eingegeben wurde (Peters Wohnzimmerhobel)… Selbst wenn der FQDN passt, wird der Botnetzbetreiber kaum beim ISP des gekaperten Rechners einen passenden Reverse-DNS setzten lassen. Bei Verbindungen aus dynamischen IP-Netzten, sprich A-DSL T-COM 0815 Internetverbindungen, ist der Hostname meist nicht mal in einem gültigen Format. Warum auch? Dieses können wir uns zunutze machen, indem wir hier schon aussortieren. Fällt doch mal ein gewünschter Absender unter diese Restriktionen, hat dessen Admin meist nicht sauber gearbeitet. Der Admin und der Absender der E-Mail werden über passende Rückmeldungen und Logeinträge auf diesen Punkt aufmerksam gemacht!

Diese Filtermethode ist recht effektiv (30 – 55 Prozent Spam und Viren fliegen hier schon weg), einfach und sicher.

Eine erste grobe und einfache Konfiguration läuft so….

In der Datei /etc/postfix/main.cf müssen folgende beiden Zeilen ergänzt werden:

smtpd_helo_required = yes
smtpd_delay_reject = yes

smtpd_helo_required gibt vor, das unser Server immer und von jedem ein helo erwartet. Ist smtpd_delay_reject auf yes gesetzt führt Postfix die UCE-Filterung erst nach dem „RCPT TO:“ aus. Würde dieses nicht so sein, hätten einige SMTP Clients von z.B.: Microsoft damit arge Probleme.

Die einzelnen Beschränkungen legen wir passend unter den einzelnen Optionen an, was welche bewirkt erkläre ich unten….

Unter smtpd_recipient_restrictions:

        reject_unlisted_recipient,
        reject_non_fqdn_recipient,
        reject_non_fqdn_helo_hostname,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_unknown_recipient_domain,
        reject_unknown_client_hostname,
        reject_unknown_helo_hostname,
        reject_unknown_client,
        reject_unknown_recipient_domain,
        reject_unknown_sender_domain,
        reject_unauth_destination,
        reject_invalid_helo_hostname,
        reject_invalid_hostname,

Wichtig ist hier die Einrückung sowie Beachtung des Komma!

reject_non_fqdn_sender
Weist den Absender der E-Mail zurück, wenn dieser nicht in FQDN Form angegeben wurde.

reject_non_fqdn_recipient
Weist den Empfänger der E-Mail zurück, wenn dieser nicht in FQDN Form angegeben wurde.

reject_non_fqdn_hostname
Weist E-Mails zurück, wenn der Clientname nicht in FQDN Form angegeben wurde.

reject_invalid_hostname
Weist E-Mails zurück, wenn der Clientname nicht in einem gültigen Format angegeben wurde.

reject_unknown_recipient_domain
Weist die Anfrage zurück, wenn die angegebene Domain (RCPT TO) des Empfängers im DNS keinen Eintrag vom Typ A oder MX hat.

reject_unknown_sender_domain
Weist die Anfrage zurück, wenn die angegebene Domain (MAIL FROM) des Absenders im DNS keinen Eintrag vom Typ A oder MX hat.

reject_unlisted_recipient
Weist die E-Mail zurück, wenn der Empfänger nicht in der Liste der gültigen Empfängerdomains aufgeführt ist.

reject_unauth_destination
Weisst die E-Mail zurück:
  – wenn Postfix als relay Host arbeitet und die angegebene Empfängerdomain nicht in der Liste gültiger Weiterleitungsdomains steht.
  – wenn Postfix der Zielserver ist und die angegebene Empfängerdomain nicht in der Liste gültiger Empfänger steht.

reject_unknown_client_hostname
Weisst die E-Mail zurück, wenn Hostname und IP Adresse des einliefernden Mailservers nicht zueinander passen, oder nicht aufgelöst werden können.

reject_invalid_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname fehlerhaft ist. Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_non_fqdn_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname kein fqdn nach RFC ist.  Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_unknown_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname keinen A oder MX Record hat. Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_unknown_client
Weisst die E-Mail zurück, wenn Host-IP Adresse und der Hostname des einliefernden Mailservers nicht zueinander passen, oder nicht aufgelöst werden können.

Nach einem Restart von Postfix kann man nun im Logfile schon die Wirkung der Beschränkungen bewundern:

tail -f -n 200 /var/log/mail.log

Hier versucht der Client „userpc“ mit der IP: 94.52.112.110 (GeoIP City Edition, Rev 1: RO, 10, Bucharest, (null), 44.433300, 26.100000, 0, 0) eine E-Mail einzuliefern. Da aber userpc kein FQDN ist, wird die Verbindung vom Server mit einem 504 zurückgewiesen. Der Vorteil von Errorcodes aus dem Bereich 5XX ist das wir (also der angesprochene Server) die Verbindung sofort beenden können, ohne auf den Client zu warten. Damit werden Verbindungen sofort wieder freigegeben und stehen anderen Verbindungen zur Verfügung.

Jun 7 17:50:35 smtp postfix/smtpd[22037]: NOQUEUE: reject: RCPT from unknown[94.52.112.110]: 504 5.5.2 <userpc>: Helo command rejected: need fully-qualified hostname; from=<MackenzieSaranzak@redvanilla.com> to=<spamemfaenger@spammdomain.de> proto=ESMTP helo=<userpc>
Jun 7 17:50:36 smtp postfix/smtpd[22037]: lost connection after DATA (0 bytes) from unknown[94.52.112.110]

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

---

*Update* 22.03.2012

Ich habe inzwischen ein paar Auswertungen gefahren. Dabei zeigte sich, das ich mit folgenden Optionen bereits knapp 96% aller Spam und Virenmails erschlagen kann:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rhsbl_sender rhsbl.ahbl.org,
        reject_rhsbl_sender cart00ney.surriel.com,
        reject_rhsbl_sender in.dnsbl.org,
        reject_rhsbl_sender rhsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rhsbl_client abuse.rhsbl.kernel-error.de,
        reject_rhsbl_client postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_client spam.rhsbl.kernel-error.de,
        reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
        reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_sender spam.rhsbl.kernel-error.de,
        reject_rbl_client spam.rbl.kernel-error.de,
        reject_rbl_client socks.dnsbl.sorbs.net,
        reject_rbl_client http.dnsbl.sorbs.net,
        reject_rbl_client misc.dnsbl.sorbs.net,
        reject_rbl_client web.dnsbl.sorbs.net,
        reject_rbl_client new.spam.dnsbl.sorbs.net,
        reject_unlisted_recipient,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_unknown_client_hostname,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_client,
        check_policy_service unix:private/tumgreyspf

smtpd_data_restrictions =
        reject_unauth_pipelining,
        permit

unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550

Wichtig:

Die Liste *.kernel-error.de ist meine ganz eigene private. Die nur für mich und meine eigenen Zwecke angedacht ist. Als einfachen Test könnt ihr sie natürlich gerne abfragen aber sie sollte niemals produktiv eingesetzt werden. Das wird bestimmt mal Probleme geben. Am besten einfach weg lassen!

---

Hier hätte ich dann noch die groben Auswertungen der Kiste, die sich um meine privaten Mails kümmert. Ist natürlich mit keinem großem Mailsystem zu vergleichen. Aber die Leute stehen ja so auf bunte Bilder 😛

Greylisting ist ein sehr einfacher und ebenso wirkungsvoller Kniff um sich gegen Spam und Viren zu schützen. 80 bis 90 Prozent der Spammails und fast schon alle Viren werden inzwischen von großen Botnetzen verschickt. Vor allem Betreiber größerer Mailserver bekommen schnell Probleme durch solche Botnetze. Die von großen Botnetzten ausgelösten Spam- und Virenfluten, verstopfen die Mailserver. Dadurch verzögern sich die Zustellungen einzelner E-Mails auf fast schon unbestimmte Zeit. Der bearbeitende Mailserver ist oft damit ausgelastet sich um Spam- und Virenmails zu kümmern.

Wie kann Greylisting hier nun helfen? Im Grunde ganz einfach….

Wenn ein Mailserver das erste Mal versucht einem Mailserver mit Greylisting eine E-Mail zuzustellen, wird diese mit der Bitte abgewiesen, es in ein paar Minuten noch einmal zu probieren. Im gleichen Moment speichert der Mailserver ein so genanntes Tripple. Dieses Tripple besteht aus der E-Mail Adresse des Empfängers, der E-Mail Adresse des Absenders und der IP-Adresse des Clients. Versucht nun der Mailserver nach ein paar Minuten eine erneute Zustellung, wird dieses von unserem greylistingfähigen Mailserver erkannt und die E-Mail wird ohne weitere Verzögerung zugestellt. Was das nun bringen soll? Nun ja, fast alle Botnetze arbeiten nach dem „fire and forget“ Prinzip. E-Mails werden also einfach abgeschickt und dann nicht weiter beachtet. Das liegt daran, dass die Botnetze sehr effektiv arbeiten sollen. In der Zeit, in welcher sich das Botnetz damit befasst eine E-Mail zu puffern und später noch einmal zuzustellen, sich darum kümmert das ein angesprochener Mailserver gerade nicht antwortet oder eine E-Mail Adresse nicht mehr existiert, in dieser Zeit hätte das Botnetz schon mehrere andere Empfänger anschreiben können. Zudem ist die Wahrscheinlichkeit, dass ein Server mit Greylisting auch sonst gut vor Spam geschützt ist und die E-Mail in einem nachgeschalteten Filter sowieso ausgefiltert wird, größer als bei einem anderen Server. Denn hier hat der Admin anscheinend seine Hausaufgaben gemacht. Aus diesen Gründen ist es für einen Botnetzbetreiber einfacher und besser von seinem vermeintlichen Opfer abzulassen und sich mit einem anderen zu beschäftigen!

Mit aktiviertem Greylisting wird nun jede erste Zustellung eines Mailservers verzögert zugestellt. Fast alle Greylistingsysteme sind selbstlernend, d.h.: nach kurzer Zeit landen bereits bekannte Mailserver auf einer whitelist und müssen ab diesem Moment keine Verzögerung mehr erdulden. Greylisting ist zwar in einigen Fällen nutzlos und sicher ist es kein Allheilmittel gegen Spam und Viren, es hält dem Mailserver denn noch sehr viel „Müll“ vom Hals, damit dieser sich um andere Dinge kümmern kann!

Zusammen mit Postfix benutze ich seit längerem schön das Tool postgrey von David Schweikert.

Eine Erste funktionsfähige Implementierung ist unter Debian schon in 5 – 7 Minuten zu realisieren.

Postgrey ist direkt aus dem Paketmanager heraus zu installieren:

apt-get install postgrey

Im Normalfall wird postgrey nach der Installation sofort ausgeführt. Dieses lässt sich recht schnell überprüfen, da es auf dem Port 60000 auf 127.0.0.1 lauscht.

netstat -anp | grep 60000

Sollte hier nun etwas wie:

tcp 0 0 127.0.0.1:60000 0.0.0.0:* LISTEN 2540/postgrey.pid -

zurückgeben….

Um Postfix nun die Nutzung von postgrey näher zu bringen, müssen in der Datei /etc/postfix/main.cf die „smtpd_recipient_restrictions“ um den Eintrag:

check_policy_service inet:127.0.0.1:60000

erweitert werden. Nach einem Postfixrestart sollte das Greylisting schon laufen. Genauer kann man es sich direkt im Logfile anschauen:

tail -f -n 200 /var/log/mail.log

Es wird das erste Mal versucht eine E-Mails einzuliefern. Porstgrey vergibt die action greylist. Postfix antwortet dem einlieferndem Server also mit:: „450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html“ Alle 4XX Fehler sind als temporäre Fehler deklariert, daher wird es der einliefernde Mailserver in kürze noch einmal probieren!

Jun 7 10:26:29 smtp postfix/smtpd[9268]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:26:40 smtp postgrey[1202]: action=greylist, reason=new, client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:26:40 smtp postfix/smtpd[9268]: NOQUEUE: reject: RCPT from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]: 450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html; from=<kernel-error@kernel-error.de> to=<Testadresse@testdomain.de> proto=ESMTP helo=<smtp.kernel-error.de>
Jun 7 10:26:40 smtp postfix/smtpd[9268]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Hier ist nun der zweite Einlieferungsversuch des Mailservers! Postgrey erkennt hier schon, den Server. Die Zeit, welche zwischen den Zustellversuchen vergehen muss (default 5 Minuten), ist noch nicht abgelaufen: „reason=early-retry (84s missing)“. Aus diesem Grund wird dem einliefernden Mailserver wieder ein: „450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html“ zurückgegeben.

Jun 7 10:30:11 smtp postfix/smtpd[9268]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:30:16 smtp postgrey[1202]: action=greylist, reason=early-retry (84s missing), client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:30:16 smtp postfix/smtpd[9268]: NOQUEUE: reject: RCPT static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]: 450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html; from=<kernel-error@kernel-error.de> to=<Testadresse@testdomain.de> proto=ESMTP helo=<smtp.kernel-error.de>
Jun 7 10:30:16 smtp postfix/smtpd[9268]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Jetzt kommen wir zum dritten Einlieferungsversuch. Postgrey findet das Tripple und die minimale Zeit zwischen den Zustellversuchen ist inzwischen vergangen. Daher bekommen wir die action pass, welche Postfix zur Annahme der E-Mail bringt! Die E-Mail wurde zugestellt! Postgrey wird sich diesen Vorgang nun für (default) 35 Tage speichern. Aus dieser Merkliste wird postgrey nun lernen und das Greylisting wird Stück für Stück, bei bekannten Kombinationen, verschwinden!

Jun 7 10:32:34 smtp postfix/smtpd[9827]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:32:35 smtp postgrey[1202]: action=pass, reason=triplet found, delay=355, client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:32:35 smtp postfix/smtpd[9827]: 6B271904DA4C: client=static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:32:35 smtp postfix/cleanup[10999]: 6B271904DA4C: message-id=<584E00FCBBB4684XXXXXXD0119300F37D4@smtp.kernel-error.de>
Jun 7 10:32:35 smtp postfix/qmgr[1637]: 6B271904DA4C: from=<kernel-error@kernel-error.de>, size=5104, nrcpt=1 (queue active)
Jun 7 10:32:36 smtp postfix/smtpd[9827]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Hier ist nun ein Beispiel für einen Vorgang, bei welchem der Client schon eingelernt wurde.

Jun 18 11:43:40 smtp postfix/smtpd[17392]: connect from www.XXX.nrw.de[193.xxx.xxx.xxx]
Jun 18 11:43:55 smtp postgrey[1203]: action=pass, reason=client AWL, client_name=www.XXX.nrw.de, client_address=193.xxx.xxx.xxx, sender=xxxxxxxxxxxxx@uni-wuppertal.de, recipient=kernel-error@kernle-error.de
Jun 18 11:43:55 smtp postfix/smtpd[16425]: B1613904DA46: client=www.XXX.nrw.de[193.xxx.xxx.xxx]
Jun 18 11:43:55 smtp postfix/cleanup[18052]: B1613904DA46: message-id=<2A15E2XXXXXXXXXX9A17CF771D007BDC@men>
Jun 18 11:43:55 smtp postfix/qmgr[1643]: B1613904DA46: from=<xxxxxxxxxx@uni-wuppertal.de>, size=79646, nrcpt=1 (queue active)
Jun 18 11:43:55 smtp postfix/smtpd[16425]: disconnect from www.XXX.nrw.de[193.xxx.xxx.xxx]

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) als Spam- und Virenabwehr für Postfix? Diese Frage habe ich mir des öfteren gestellt. Ich sehe hier sehr klare Vorteile genauso wie Nachteile.

Der wirklich große Vorteil ist, dass wenn ein Client auf einer Blacklist steht, dieser sofort abgewiesen wird. Der Mailserver muss also erst überhaupt keine E-Mail annehmen, sich lange mit dem Client unterhalten, irgendwas filtern, auf das Beenden der Verbindung vom Client aus warten usw. usw…
Als Admin großer Mailserver wünscht man sich so etwas.

• Denn hält ein Client die Verbindung bis zum Timeout offen, ist dieser Prozess für andere eingehende Verbindungen nicht zu gebrauchen. Einem läuft also die Tabelle voll.
• Jede Spam- oder Virenemail die eingeliefert wird, verschwendet Traffic und Serverzeit.
• Jede Spam- oder Virenemail im System beschäftigt dieses auch. Die E-Mail wird zwischengelagert, verschoben, gefiltert, überprüft, verglichen usw.. Sie nimmt echten E-Mails den Platz weg, diese müssen auf die Verarbeitung von Müll warten, alles verschleppt sich. Es entstehen Mailstaus, die Zustellung gewünschter E-Mails wird bis auf ungewisse Zeit verzögert!

Der für mich große Nachteil ist, dass man sich auf andere ~blind~ verlässt.

• Ich kann die Blacklisten nicht wirklich überprüfen, es ist für mich zudem nicht wirklich transparent.
• Hin und wieder landet auch mal ein System „versehentlich“ auf einer solchen Liste.
• Ob und wie dieses System wieder von einer solchen Blackliste herunter kommt, kann ich nicht wirklich beeinflussen.

Es gibt zwar Wege, sich selbst eine solche Liste anzufertigen!
Einer ist, eine E-Mail Adresse überall dort zu veröffentlichen, wo sie vermeintliche Spammer einsammeln können. Jeder der dann an diese Adresse eine E-Mail sendet landet auf der Blackliste. So würde sich diese Liste selbst pflegen lassen. Es wird aber lange dauern bis sie wirklich effektiv arbeitet und der Spammer muss natürlich zuerst die „Sammeladresse“ anschreiben. Hier sind die großen Listen von spamhaus.org oder die Listen mit den dynamischen IP-Netzten schon viel viel viel weiter, wenn man sich auf diese verlassen möchte!

Ich habe es erst an einem Testsystem probiert und später Stück für Stück auf die echten Systeme ausgebreitet. Dieses mit überwältigendem Erfolg! ca. 80 – 90 Prozent aller Viren- und Spammails werden schon beim Einlieferungsversuch abgewiesen. Die Belastung der Server ist stark zurück gegangen. Bisher hat sich noch kein Kunde beschwert und mir ist kein Problem aufgefallen, wie Mailverlust, Falschabweisung oder ähnliches…. Diese Lösung ersetzt ganz klar keine nachgeschalteten Filter und man sollte alles im Auge behalten, hält einem denn noch extrem viel Müll vom Hals!

Die erste grobe Konfiguration ist schnell und einfach gemacht….

Die zu befragenden Server trägt man in die passenden Sektionen der Konfigurationsdatei /etc/postfix/main.cf ein.

Unter smtpd_recipient_restrictions

        reject_rhsbl_sender rhsbl.ahbl.org,
        reject_rhsbl_sender cart00ney.surriel.com,
        reject_rhsbl_sender in.dnsbl.org,
        reject_rhsbl_sender rhsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rhsbl_client abuse.rhsbl.kernel-error.de,
        reject_rhsbl_client postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_client spam.rhsbl.kernel-error.de,
        reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
        reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_sender spam.rhsbl.kernel-error.de,
        reject_rbl_client spam.rbl.kernel-error.de,
        reject_rbl_client socks.dnsbl.sorbs.net,
        reject_rbl_client http.dnsbl.sorbs.net,
        reject_rbl_client misc.dnsbl.sorbs.net,
        reject_rbl_client web.dnsbl.sorbs.net,
        reject_rbl_client new.spam.dnsbl.sorbs.net,

---

Wichtig:

Die Liste *.kernel-error.de ist meine ganz eigene private. Die nur für mich und meine eigenen Zwecke angedacht ist. Als einfachen Test könnt ihr sie natürlich gerne abfragen aber sie sollte niemals produktiv eingesetzt werden. Das wird bestimmt mal Probleme geben. Am besten einfach weg lassen!

---

Beim Eintragen muss auf das Komma geachtet werden und darauf dass die Einträge eingerückt werden. Sonst wertet Postfix diese als eigenständigen Eintrag, welcher zu Fehlern führen wird!

Ist ein Mailserver „versehentlich“ auf einer Blacklist gelandet wird sich der Administrator des Mailserver natürlich irgendwann wundern, warum sein Mailserver kaum noch E-Mails ausliefern kann. Diesem Administrator wollen wir natürlich die Arbeit etwas erleichtern und sorgen für klare Logeinträge in seinem System. Zudem sollten die Absender auch etwas sinniges bekommen. Daher setzten wir eine Standardrückmeldung für alle Systeme, welche aufgrund der Blackliste abgelehnt werden! Es muss in der Konfigurationsdatei /etc/postfix/main.cf etwas in dieser Art ergänzt werden:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@$recipient_domain; So long.....

 

Wird die Annahme der E-Mail nun verweigert, bekommt der Absender eine sinnige E-Mail. In dieser steht nun der Grund und dass er die Nachricht bitte an seinen Administrator weiterleiten soll (dieser sollte in der Lage sein sie auch zu verstehen). Zusätzlich wird noch angegeben unter welcher E-Mail Adresse man den Postmaster des Empfängers erreichen kann.

Nach einem Restart von Postfix sollte RBL schon laufen.

tail -f -n 200 /var/log/mail.log

 

Wie gut zu erkennen ist, baut ein Clientsystem mit der IP: 66.220.155.147 (GeoIP City Edition, Rev 1: CA, ON, Petrolia, (null), 42.883301, -82.150002, 0, 0) eine Verbindung zu unserem Mailserver auf. Dieses System befindet sich nun auf eine Blacklist oder kommt aus einem dynamischen Adressbereich, welche auf einer Blacklist steht. Es wird daher sofort ein 554 gesendet. Alle Fehlercodes aus dem Bereich 5XX sind als dauerhafte/fatale Fehlercodes deklariert. Bei allen Fehlern aus dem Bereich 5XX baut unser Server direkt die Verbindung ab und wartet nicht auf ein Beenden der Verbindung vom Client. Diese Verbindung wird somit sofort freigegeben und steht anderen Prozessen zur Verfügung.

Oct 31 16:19:16 postfix/smtpd[7308]: connect from outmail013.ash2.facebook.com[66.220.155.147]
Oct 31 16:19:18 postfix/smtpd[7308]: NOQUEUE: reject: RCPT from outmail013.ash2.facebook.com[66.220.155.147]: 554 5.7.1 Service unavailable; Client host [66.220.155.147] blocked using ix.dnsbl.manitu.net; Your e-mail service was detected by mx.selfip.biz (NiX Spam) as spamming at Wed, 31 Oct 2012 04:20:15 +0100. Your admin should visit http://www.dnsbl.manitu.net/lookup.php?value=66.220.155.147; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@user.de; So long.....; from=<notification+kr4mss2q24wx@facebookmail.com>; to=<user@user.de>; proto=ESMTP helo=<mx-out.facebook.com>

 

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

 

---

 

Ein kleines „Problem“ ist mir bei dieser Technik untergekommen. Einer der RBL Server, welchen ich abgefragt habe, hat (für mich) plötzlich seinen Dienst eingestellt. Dieses ist mir aber erst spät aufgefallen.
Im Postfixlogfile unter: /var/log/mail.log werden dazu Warnmeldungen angezeigt. Nach dem Timeout der Abfrage wurde einfach der nächste Server in der Liste abgefragt. Alles kein Problem, sollte man meinen 😀 Leider ist das Mailaufkommen auf diesem Server doch sehr hoch. Die ständigen Anfragen bis in die Timeouts führten leider in seltenen Fällen zu einer unvollständigen Rückmeldung anderer DNS-Abfragen. Einige E-Mails konnten so nicht richtig zugestellt werden. Die Rückmeldung war folgende:

<kernel-error@kernel-error.de>: Host or domain name not found. Name service error for name=mailserver.maildomain.de type=A: Host found but no data record of requested type

 

Nachdem ich den toten Server entfernt hatte und die DNS Abfragen nicht mehr in die Timeouts liefen, war dieses Problem weg! Ich habe nur leider in den ersten Minuten keinen Zusammenhang zwischen dem toten RBL-Server und einer gescheiterten „Weiterleitung“, wegen einer nicht vollständig aufgelösten DNS-Abfrage, gesehen.

 

 

 

Funktionsweise

Dazu wird in der DNS-Zone einer Domäne ein sog. Resource Record vom Typ TXT oder SPF mit Informationen darüber hinterlegt, welche Computer E-Mails für diese Domäne versenden dürfen. Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die „MAIL FROM“-Identität als auch die „HELO“-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.

Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an

test@example.org

Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden. Mit dieser Technik lässt sich die Fälschung von Absenderadressen effektiv verhindern.

SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

SPF muss nur vom Empfängersystem unterstützt werden – am SMTP-Protokoll der Mailübertragung ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt