Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 45 von 48)

Eigenen Jabber-Server einrichten: Schritt-für-Schritt-Anleitung

Ich nutze Jabber schon länger als Messenger. Nun habe ich mir die Frage gestellt ob es nicht sinnvoll ist einen eigenen Jabber-Server zu betreiben…. Hier kann man nun etwas dazu lesen!

Warum ich Jabber benutze kann man schnell erkennen, wenn man sich das Thema Policy durchliest! Zudem bietet Jabber extrem viele Vorteile. Ich zähle mal ein paar auf 😀

– Jabber ist OpenSource, jeder kann sich also den Code anschauen. Es wird schwer hier Schadcode zu verstecken.
– Gerade weil jeder an den Code kann, kann auch jeder recht gut neue Software dafür entwickeln.
– Es gibt Transporter um, sofern man möchte, auch Verbindung zu ICQ, AIM, MSN usw. zu bekommen.
– Verschlüsselung per SSL/TLS/GPG usw. ist meist kein Problem und sehr einfach einsetzbar.
– Es gibt nicht ein zentrales Hauptsystem, welches bei einem Ausfall direkt alles lahm legt. Es besteht aus einem Netzwerk vieler kleiner Systeme, welche unabhängig voneinander funktionieren. Fällt eines aus, sind die User dieses Systems nicht mehr zu erreichen. Alle anderen sind davon nicht betroffen.

Klingt doch schon mal toll, oder? Warum nun also ein eigener Jabber Server?

Nun ja, natürlich um herauszufinden wie es funktioniert und ob ich es hin bekomme. Dann ist man unabhängiger von anderen Systemen und kann seine eigenen Regeln aufstellen. Alles lässt sich so konfigurieren und einrichten, wie man es selbst gerne hätte. Man kann selbst bestimme, welche Module in welcher Form nutzbar sein sollen….

Ich habe dann etwas mit verschiedenen Servern auf meinem Testsystem herumprobiert. Getestet habe ich jabberd, ejabberd und openfire. Hängen geblieben bin ich am Ende bei Openfire in Kombination mit dem Kraken IM Gateway Plugin. Dieser Server ist nur für mich, die Familien und einige enge Freunde geplant. Würde es ein großer öffentlicher Server werden sollen, hätte ich mich sicher für einen anderen Server entschieden! Für meinen Plan bringt dieser aber alles mit was ich brauche und dieses schnell und einfach! Zusätzlich spricht mein PSI mit dem Server auch über IPv6! IPv6 Kompatibilität ist für mich inzwischen recht wichtig und es war an einigen Stellen schon: „Das Zünglein an der Waage“.

Unter Debian war die Installation schnell durch. Ich musste für das Plugin etwas suchen, das lag aber eher an meiner situativen Unfähigkeit 😀 Das Plugin ermöglicht die Verbindung in andere IM Netzte, wie ICQ, MSN, AIM, Facebook usw. usw… Denn dieses Plugin stellt die so genannten Transporter!

Thema Policy

In den AIM Terms of Service findet sich beispielsweise folgende Stelle:

You or the owner of the Content retain ownership of all right, title and interest in Content that you post to public areas of any AIM Product. However, by submitting or posting Content to public areas of AIM Products (for example, posting a message on a message board or submitting your picture for the „Rate-A-Buddy“ feature), you grant AOL, its parent, affiliates, subsidiaries, assigns, agents and licensees the irrevocable, perpetual, worldwide right to reproduce, display, perform, distribute, adapt and promote this Content in any medium. Once you submit or post Content to any public area on an AIM Product, AOL does not need to give you any further right to inspect or approve uses of such Content or to compensate you for any such uses. AOL owns all right, title and interest in any compilation, collective work or other derivative work created by AOL using or incorporating Content posted to public areas of AIM Products.

Bei der Accepable Use Policy schaut es meiner Meinung nach nicht besser aus:

You agree that by posting any material or information anywhere on the ICQ Services and Information you surrender your copyright and any other proprietary right in the posted material or information. You further agree that ICQ LLC. is entitled to use at its own discretion any of the posted material or information in any manner it deems fit, including, but not limited to, publishing the material or distributing it.

Bei Microsoft findet man ähnliches…..

Ist doch eine Super Sache, oder?

Aber kann man es ihnen wirklich vorhalten? Die Jungs stellen „kostenlos“ Serversysteme, Infrastruktur, Manpower usw usw…. Glaubt man denn wirklich das diese Dienstleister das aus reiner Nächstenliebe machen? Einen gewissen Plan werden die schon verfolgen und die müssen auch Geld mit ihrem Produkt verdienen. Wenn die jetzt schon in ihren Policys schreiben, dass man als Nutzer die Rechte an allem abgibt was man in irgendeiner Weise in deren Service wirft. Dann…. Na dann werden die doch GAAANNNNZZZ sicher nichts blödes mit diesen Daten anstellen, oder?


Um kurz zu zeigen wie anpassungsfähig jabber ist, habe ich hier noch ein paar Bilder.

Zuhause nutze ich das Siemens Gigaset C470IP. So kann ich schnell und einfach die Sipgate- und SIP-Accounts erreichbar machen. Dieses sogar so, dass jeder ohne Vorkenntnisse damit einfach telefonieren kann! Zusätzlich habe ich einen Jabber-Account auf meinem Server für ein Gigaset C47H erstellt.

Das Telefon hat also einen Messenger, welcher sich mit meinem Jabber-Server verbindet und darüber Nachrichten empfangen und verschicken kann.

Gigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem MessangerGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue NachrichtGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue Nachricht
Der Jabber Messenger des Gigaset C47H
ist online und mit dem Jabber-Server
verbunden.
Am Gigaset C47H ist eine neue Jabber
Message angekomen!
Die Jabber Nachricht wird am Mobilteil
gelesen. Nun könnte man auch
antworten.

Auch wenn mich einige für verrückt erklären werden, ich finde es total geil 😀

Zusammen mit den Transportern könnte ich das Telefon auch für MSN / Facebook / ICQ  usw. usw.. erreichbar machen. Na ja, wenn ich wollte 😛


*Update 19.05.2012*

Vergesst bei eurem Jabber-Server nicht die DNS SVR RECORDS 🙂

Theraphosinae

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!<<

Theraphosa blondi

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.<<

Avicularia versicolor: Pflege und Haltung der Vogelspinne

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<<

Quota Dovecot

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!

Skoda Octavia LPG

Der alte Firmenwagen (Fabia II TDI Sport / 2,5 Jahre / 120.000KM / zweiter Motor) steht mehr in der Werkstatt als er mir zur Verfügung steht, Diesel ist auch nicht mehr so günstig wie es mal war und von der jährlichen Steuerzahlung ganz zu schweigen. Zusätzlich beansprucht mein Nachwuchs mehr Platz im Auto. Aus all diesen Gründen muss ein neuer Firmenwagen her, so zumindest die Entscheidung von meinem Chef (ich kann/konnte/wollte und habe mich natürlich dieser Entscheidung angeschlossen).

Also etwas telefoniert und dann geschlossen auf zum Autohaus unseres Vertrauens (Autohaus Weiner in Bochum – Wattenscheid). Hier wurde unserer Idee einen neuen Firmenwagen zu leasen natürlich freudig aufgenommen.

Alle unsere Firmenwagen waren und sind von Skoda. Bisher sind alle mit dem Skoda Preis- / Leistungsverhäldnis zufrieden. Besonders Diskussionen hinsichtlich der Herstellermarke gab es daher nicht mehr. Da der Octavia bei uns auch hinlänglich bekannt war und gefahren wurde, ja daher sollte es wohl ein Octavia werden! Welcher genau? Das war nun noch die große Frage!

— Im Unterhalt bitte günstig 😀 —

Günstig… in der Nähe unseres Firmenparkplatzes hat eine Autogastankstelle (LPG) eröffnet, irgend so ein „Kleinanbieter“ GG-Autogas. Hier gibt es eine Kundenkarte, mit dieser kann man Tanken und am Ende des Monats bekommt die Firma eine Abrechnung. Zudem bekommt man noch 2 Cent Rabatt auf jeden Liter. Ganz cool also….

Aber Autogas? Mehr Verbrauch bei weniger Leistung und dann noch die Tankstellensuche? Zu dem wie schwachbrüstig ist so eine LPG Kiste genau? Glücklicherweise hatte Weiner einen Octavia LPG. Diesen haben wir dann gleich mal zur Probefahrt ausgeliehen. Meinen Chef und mich hat dieses Auto überzeugt! Daher wurde dieser unser neuer Firmenwagen….

Inzwischen bin ich schon einige Zeit mit der Kiste unterwegs und kann Rede und Antwort zu den gängigsten Fragen stehen. Die Kiste hat über 100 PS, auf Gas verliert man 3 – 4 PS. Dieses fühlt man nicht wirklich. Man merkt es klar auf der Autobahn bei der Endgeschwindigkeit. Hier ist auf Benzin (je nach Wetterlage) etwas um die 5 – 10 km/h mehr möglich. Im Grunde mit dem einschalten der Klimaanlage zu vergleichen 😛

Der Gastank ist dort verbaut, wo normalerweise der Ersatzreifen seinen Platz gefunden hätte, ich habe von allen möglichen Details Bilder gemacht, diese sind weiter unten zu finden. Der Tankstutzen ist recht formschön zusammen beim Tankstutzen fürs Benzin verbaut. Man muss also nicht zum Tanken unter das Auto kriechen, das Nummernschild verdrehen oder das Gas irgendwo in die Stoßstange quetschen. Zum Auto gibt es dann noch zwei interessante Adapter für die verschiedenen Tankrüssel, bei mir in einer dafür viel zu kleinen Tüte, so wie irgendwelche Gaszertifikate. Die Tankanzeige vom Gastank ist vor dem Schaltknüppel in der Mittelkonsole angebracht. Vom Design her passt sie nicht zu 100 Prozent zum Rest des Wagens, schaut denn noch nicht fehlplatziert aus. Die Tankanzeige wird durch blaue LEDs dargestellt. Ein gelbe blinkende LED zeigt einem an, dass auf Gasbetrieb umgestellt wird, dauerhaftes Leuten bedeutet, du fährst mit Gas 😀 Kurz bevor der Gastank leer ist, leuchtet eine rote LED auf. Ist der Tank leer piepst die Anzeige lautstark und schaltet automatisch auf Benzin um. Benzin wird zum Starten des Motors benötigt und so lange bis der Motor auf Betriebstemperatur ist, dann wird automatisch auf Autogas umgeschaltet. Davon bekommt man aber nicht wirklich etwas mit, es knackt nur kurz ein Magnetventil im Kofferraum. Will man bewusst auf Benzin fahren, lässt sich das an der Anzeige durch einen Knopfdruck umschalten!

Die Verbrauchsanzeigen usw. des Boardcomputers funktionieren tadellos mit Gas oder Benzin. Im Gasbetrieb verbraucht ich naturgemäß etwas mehr Kraftstoff als mit Benzin. Da ich mit um die 0,60 Euro pro Liter dabei bin ist das mehr als ok! Ich fahre den 40 Liter Tank in knapp 300 km Leer, mehr Reichweite ist halt nicht. Da wir die Gas Tankstelle direkt vor der Nase habe, ist das aber kein Problem. Zudem gibt es mehr Autogastankstellen als man so meinen würde. In Europa muss man sich sicherlich keinen Kopf machen, mit leerem Gastank irgendwo liegen zu bleiben. Zudem kann man ja auch weiterhin mit einem 50 Liter Benzintank fahren.

Benzintank…. Bei 0,2 km auf dem Tacho habe ich den Benzintank vollgetankt. Bei ca. 8000 km musste Benzin nachgetankt werden, das finde ich ok! Im Grunde merkt, sieht oder riecht man keinen Unterschied ob man nun Gas oder Benzin fährt!

Im Motorraum schaut alles gut verbaut und sauber aus. Durch die Gasanlage scheint die, normalerweise vorhandene, Motorabdeckung nicht mehr zu passen. Ich vermisse diese nicht weiter!

Geräusche? Puhh, ich bin vorher Diesel gefahren! Ich habe die ersten km an jeder Ampel gedacht die Kiste ist aus. Kein wackeln kein Brummen kein überhaupt nichts.

Die Motorleistung ist ausreichend, jedes PS mehr wäre nur für den Spaßfaktor gut, sollte aber auch nicht kleiner sein! Auf der Bahn sind 200 und etwas mehr auch schon mal möglich…. Das Auto fährt sich super und ich bin absolut zufrieden damit (hier noch mal Dank an den Chef).


Hier nun die versprochenen Bilder…


* Update 10.10.2012 *

So ich bin nun bei knapp 55000km.. Bisher bin ich noch sehr zufrieden mit dem Auto. Er hatte zwar ein kleines „Problemchen“ mit der Gasanlage, diese konnte aber gelöst werden.
Er Meldete immer dass er sporadisch zu fett oder sporadisch zu mager läuft. Mein Autohaus tippte auf die Lambdasonde. Diese wurde mehrfach Ö_ö getauscht, brachte aber keine Besserung. Denn nach kurzer Zeit tauchte dieser Fehler wieder auf. Da mein Autohaus noch keine weiteren Erfahrungen mit einem LPG Auto hatte, hat dieses ein befreundetes Autohaus um Rat gebeten. Hier wurde ein Softwareupdate eingespielt. Dieses half leider ebenfalls nicht.
Erst der etwas längere Ausflug meines Autos zum Skoda Werk brachte eine Verbesserung. Im Grunde wurde dabei der komplette Gasstrang vom Tank bis zum Motor getauscht.
Da alles noch innerhalb der Garantie war und sich mein Autohaus sehr viel Mühe gegeben hat war es auszuhalten.
Man sollte also sicherstellen dass sein Autohaus auch wirklich mit LPG Autos umgehen kann.


 * Update 08.03.2013 *

Es gibt ein neues Auto 🙂 Heute wandert der gute alte Octavia zum Autohaus und ich bekomme einen nagelneuen Skoda Yeti TDI 2.0. Ich kann es kaum abwarten! Gas war toll und nun doch wieder Diesel…. Oh ja und natürlich wieder beim Autohaus Weiner in Bochum Wattenscheid!

 

 

Spam- und Virenabwehr durch HELO: So funktioniert’s

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 mit Postfix

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!

RBL und Postfix…

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.

 

 

 

SPF

Sender Policy Framework (früher Sender Permitted From), kurz SPF, ist eine Technik, die das Fälschen des Absenders einer E-Mail auf SMTP-Ebene erschweren soll.

Klingt komplex ist es aber nicht…

Es gibt eine simplen SPF-Generator, welcher einem einen fertigen Eintrag für seinen DNS-Server erstellt.

Einfach mal hier: http://www.spf-record.de/ schauen….

Möchte man seine SPF Konfiguration testen gibt einem folgende Webseite viele Möglichkeiten: http://www.kitterman.com/

Der SPF-Record könnte für meine Zone wie folgendes Beispiel aussehen:

kernel-error.de.    IN  TXT „v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all“

 

Bei Fragen oder Problemen, helfe ich natürlich gerne weiter!

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

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑