Datenhaufen zu IT und Elektronik.

Autor: Sebastian van de Meer (Seite 38 von 49)

Nachfolger für RFC-Ignorant.Org

Na also…

Es ist ein ordentlicher Nachfolger für rfc-ignorant.org gefunden! Der Hosting-Provider manitu hat auch bereits eine Domain gestellt: rfc-ignorant.de

Noch ist die Liste „leer“. Keine Anfrage wird daher negativ bewertet. Denn noch kann man sie bereits in seine Konfiguration aufnehmen. Die neuen Zonen sind:

Old zone   New zone
dsn.rfc-ignorant.org > dsn.bl.rfc-ignorant.de
postmaster.rfc-ignorant.org > postmaster.bl.rfc-ignorant.de
abuse.rfc-ignorant.org > abuse.bl.rfc-ignorant.de
whois.rfc-ignorant.org > whois.bl.rfc-ignorant.de
bogusmx.rfc-ignorant.org > bogusmx.bl.rfc-ignorant.de
fulldom.rfc-ignorant.org > fulldom.bl.rfc-ignorant.de

 

So gefällt es mir 🙂

 

 

Citrix XenServer local storage größer >2TB

Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt.
Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht.
Zusammengefasst bedeutet es:
–    Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen.
–    Ich kann diesen Speicher aber nicht anlegen 🙁

Damit wäre also nur das Problem des Anlegens zu lösen!

Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit.
Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.

 

Festhalten, es geht los…
–    gparted öffnen
–    den >2TB Datenspeicher auswählen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

–    über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen 

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

–    unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden

–    den neuen unallocated Speicher markieren

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT

–    über den Menüpunkt Partition den Unterpunkt New auswählen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT
–    nun den File system Type auf lvm2 pv setzten und Hinzufügen

Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT
–    Abschließend noch diese Änderungen anwenden über den Button Apply

Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen.

Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:

$ pvcreate /dev/sda1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/sda1 name-label="4TB-SPEICHER"

 Ab jetzt ist der Store wie jeder andere nutzbar.


* U-P-D-A-T-E *

Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen 🙂

Postfix nach hause telefonieren

Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.

 

Sender adress verification / callback verification / callout verification???

Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:

/var/lib/postfix/verify_cache.db

Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:

smtpd_recipient_restrictions =
….........,
reject_unverified_sender,
….........,

Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist 😀

Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.

Zu pingelig?

Klar, nach RFC müssen bestimmte Dinge bei einem Mailserver zusammenpassen.

Nach RFC1912 – Section 2.1 muss der Rückwärts aufgelöster Hostname zu dessen Vorwärtsauflösung passen.

Als Beispiel:
Wenn ich nachfrage welcher DNS Name zur IPv4 Adresse 10.2.3.4 gehört und darauf die Antwort bekomme, es ist: test.example.com…. Ja dann muss auf die Frage welche IPv4 Adresse zum DNS Namen test.example.com gehört auch die Antwort kommen: 10.2.3.4

Aus Sicht des testenden ist die Wahrscheinlichkeit schon höher dass beide Systeme unter der gleichen Kontrolle stehen. Zusätzlich haben Bots in einem Botnetz extrem selten die Möglichkeit diese Einträge passend zu setzten und der Administrator des Systems hält sich nicht nur die RFCs sondern konfiguriert zudem ordentlich. Es ist daher ebenfalls wahrscheinlich dass er sich bei seinen sonstigen Konfigurationen auch Mühe gegeben hat 😀 Dieses lässt sein System zusätzlich sicherer gegen Missbrauch erscheinen.

Weiter im Text…
Denn nach RFC 2821, Section 3.6 muss der im HELO/EHLO angegebene DNS Name nicht nur ein gültiger Fully Qualified Domain Name (FQDN) sein, sondern er muss zusätzlich zum Hostname des einliefernden Mailservers passen. So lässt sich nun ersehen dass nicht nur IP und DNS unter der gleiche Kontrolle zu sein scheinen, sondern gleichfalls das Mailsystem.

Der Admin scheint also zu wissen was er tut und hat auch die Kontrolle über das System 🙂

Ich prüfe dieses nun bei jeder einzuliefernden E-Mail. Ist nicht alles korrekt, wird die E-Mail abgelehnt. In den letzten Wochen tauchen genau hier gehäuft Unstimmigkeiten auf und dieses nicht bei kleinen „Wurstbuden“ sondern auch bei den ganz Großen! Natürlich ist es kein zwingender Grund E-Mails auf dieser Basis abzuweisen…. Da die Sysadmins der Mailserver, vor allem der ganz GROSSEN, ja Fachleute sind… Sollte man von diesen erwarten können sich an diese einfachen Vorgaben zu halten, oder? — Oder ist es wirklich zu pingelig?

 

 

 

DKIM Schüssel getauscht

Nachdem nun alle etwas nervös wegen zu kurzer DKIM Keys sind (512Bit), diese lassen sich wohl bei Amazon in knapp 72 Stunden knacken. Habe ich dann meine Schlüssel auch einmal getauscht. Diese hatten bisher eine Länge von 1024 Bit, mit diesen wäre ich also noch locker auf der sicheren Seite denn noch kann es ja nicht schaden sie auf 2048Bit aufzubohren. Fast alle Systeme können mit diesen inzwischen umgehen. Die Leistung aktueller Systeme sollte heute ebenfalls nicht sonderlich unter diesen Schlüssellänge leiden.

Die Schlüssel sind schnell erstellt:

$ dkim-genkey -b 2048 -s kernel-error.de -d kernel-error.de

Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:

dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space

Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:

kernel-error.de._domainkey IN TXT ( "v=DKIM1; g=*; k=rsa; "
                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1V7WG+ZchvAxfJ2wi9jn7vWVs2mDkk66cqrKjTETdbuPwL"
                    "CX4N4IXTemT7SMS2Z+gTxcPNnUCorcMsXigNlGJK4Oq8GNx0fcxbXB+vq522FpM6FY8FVTfhL7bqLg5ajp9k0boJnSRv"
                    "F4wY3nci6E7CYCdP9XjHVoOciJdlrGFMo8rYGGiI9Ubgvue8etqgPCV2T8BKEZgys7kabPyaujSHmqrPbBkjb/F+QPJH"
                    "WqcyD7ywfT5vUkrj40Qiwsr7HxGk9aYCAHwyvdP4dvXd5xfMH2QlRKbrMjIQfKJfD5cfTiAl7YgFBFO1n7Wfj5syB6FE"
                    "bRZR9HO+rusv0hojiViQIDAQAB" )

Schnell noch mit einer Testmail an: check-auth@verifier.port25.com prüfen ob alles korrekt ist.

Fertig….

 

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
    To:'20'<check-auth@verifier.port25.com>;'0D''0A'
    Subject:'20'check-auth@verifier.port25.com'0D''0A'
    MIME-Version:'20'1.0'0D''0A'
    Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
    '20'format=flowed'0D''0A'
    Content-Transfer-Encoding:'20'7bit'0D''0A'
    Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
    From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
    Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
    DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
    '09's=kernel-error.com;'20't=1352457228;'0D''0A'
    '09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
    '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
    '09''20'Date:From:Message-ID;'0D''0A'
    '09'b=

Canonicalized Body:
    check-auth@verifier.port25.com'0D''0A'
    

DNS record(s):
    kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

 

Das kann doch nicht sein, oder?!?!?

Da schicke ich doch heute eine E-Mail ab und bekommen Sekunden später etwas wie das Folgende zurück:

Ihre E-Mail wird aus Gründen der Spam- und Virenabwehr zurückgehalten bis ihr Absender bestätigt wurde. Klicken sie zur Bestätigung auf diesen Link oder antworten sie auf diese E-Mail mit dem Betreff: „Supperspamabwehr8857“

O_o ist das ein Scherz? Wie arm ist denn dieser Versuch? Ja, ok… Vor vielen vielen Jahren war es wohl eine erste Notlösung aber so etwas setzt man doch heute nicht mehr ein. Zumindest war ich davon überzeugt!

Jetzt mal im Ernst, dem durchschnittlichen User kann man so etwas nicht zumuten. Er wird es einfach nicht verstehen, selbst wenn man es in deutsch schreibt. Mailinglisten, Onlineshops oder ähnliches würden zusätzlich nicht auf so etwas reagieren. Ein ordentlich konfigurierter Mailserver sollte hier wohl besser funktionieren – oh ja, dann müssten hier nicht die User sonder der „Admin“ denken….

Ich halte dieses fast so überflüssig wie das Gefummel mit den E-Mail Adressen. Auf vielen Webseiten steht unter -Kontakt- oft etwas wie: E-Mail: wurstsuppe – at – wurstdomain.de

Davon mal abgesehen dass jeder Spamroboter dieses schon beim einlesen herausfiltern kann, steht ja oft im Link hinter dieser Adressverwurstung die korrekte E-Mail Adresse im mailto:

Selbst wenn es in einem Bild hängt, ganz ohne Link… Glaubt wirklich noch jemand dass diese Spamroboter kein OCR beherrschen? Den einzigen denen man mit so etwas das Leben schwer macht, sind User welche einem wirklich eine E-Mail schicken wollen.

Bei dem ganzen Thema sind, wie so oft, einfach mal die Admins gefragt. Diese sollten ihren Job machen und nicht versuchen es über Dinge wie Challenge-Response auf die User abzuwälzen! Wie war es noch gleich: „Früher war alles besser“

 

 

SPF Records

Es gibt seit einiger Zeit einen dedizierten SPF-Record. Dieser wird auch bereits von vielen SPF-Filtern sowie Bind seit Version 9.4 unterstützt. Dieses entlastet etwas die TXT Anfragen und sorgt für mehr Ordnung 🙂 Wird dieser SPF Record vom jeweiligen SPF Filter unterstützt, fragt dieser meist zuerst nach dem SPF-Record und wenn es keine Antwort gibt als nächstes nach einem TXT-SPF Record.

Um diesen Filtern etwas Arbeit zu ersparen, das DNS etwas aufzuräumen und auf lange Sicht RFC konform zu bleiben (es würde mich nicht wundern wenn der TXT-SPF Record bald ausstirbt). Sollte man ebenfalls bei seiner SPF geschützten Domain einen solchen Record erstellen.

Für meinen Bind und die Domain kernel-error.de würde ein Beispiel wie folgt aussehen:

kernel-error.de.    IN    SPF    "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"

 

Geprüft werden kann alles schnell und einfach mit DIG:

# dig kernel-error.de IN SPF +short
"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"

 

Sobald alle gängigen Filter die SPF-Records implementiert haben und alle Postmaster ihre Einführungszeit hatten, kann man dann sicher seinen TXT-SPF-Record entfernen. Dieses dauert sicher wieder ein paar Jahre! Ach ja, mein TXT SPF Record schaut so aus:

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"

 

 

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

Postifx und AMaViS – content-filter oder smtpd-proxy-filter?

Das amavisd-new eine sehr schöne Lösung ist um eingehende E-Mails nach Viren oder Spam zu filtern, muss ich kaum einem erklären. Dass es aber zwei verschiedene Lösungen zur Anbindung an Postfix gibt schon. In den meisten großen HowTo´s zu Postfix und Amavis wird fast immer der Weg über content_filter beschrieben. Daher ist es wohl der verbreitetste! Es gibt zusätzlich noch die Möglichkeit amavis per smtpd_proxy_filter mit Postfix zu verknüpfen, mein persönlicher Favorit. Natürlich haben beide Lösungen wieder Vor- und Nachteile…. Für mich wiegen die Vorteile der smtpd_proxy_filter Lösung schwerer. Eine kurze und grobe Beschreibung sollte ausreichen damit es nachvollziehbar wird! Am besten wir gehen einmal den Weg einer E-Mail, wenn amavis per content_filter angebunden und einmal wenn amavis per smtpd_proxy_filter arbeitet.

 

content_filter:

Im ersten Fall nimmt Postfix die Verbindung vom einsendenden Mailserver an und nimmt die komplette E-Mail entgegen. Der einsendende Mailserver bekommt also von unserem System ein: OK, ich habe die E-Mail komplett und ohne Fehler erhalten und bin nun für alles weitere verantwortlich. Der einsendende Mailserver baut die Verbindung ab und ist damit fertig und zufrieden 🙂 Unser Mailsystem hat diese E-Mail nun zwischengespeichert und schiebt sie weiter an amavis, welches sich um die Filterung und Bewertung der E-Mail kümmert. Hat amavis gerade alle Hände voll zu tun, versucht der lokale Postix es einfach immer wieder, bis die Mail durch ist. Erkennt amavis die E-Mail nun als Virus/Spam passiert (je nach Konfiguration) folgendes. Amavis sendet über Postfix eine Info an den Absender/Empfänger, schiebt die Nachricht in Quarantäne, Tag sie und gibt sie weiter an Postfix, oder lässt sie im schlechtesten Fall „verschwinden“. Verschwindet die E-Mail nicht, landet sie in jedem Fall erst einmal wieder bei Postfix. Dieser kümmert sich jetzt erst um die weitere Zustellung der Nachricht. Also lokal weiter in ein Postfach oder Dovecot, usw. oder an einen weiteren nachgeschalteten Mailserver.

 

smtpd_proxy_filter:

Arbeitet amavis als smtpd_proxy_filter, wird die E-Mail wieder vom einliefernden Mailserver von Postfix angenommen. Nun muss man sich vorstellen das Postfix dabei die E-Mail direkt durch amavis leitet und die Nachricht somit direkt Gefiltert/Bewertet werden kann. Der einliefernde Mailserver bekommt also zum Abschluss vom Postifx nicht einfach ein: OK, E-Mail ist angekommen“ sondern direkt die durchgereichte Nachricht von Amavis: „Ne, das ist SPAM, die lehnen wir ab.“ oder „Ne, da ist ein Virus im Anhang, die E-Mail nehmen wir nicht an!“. Unser Mailsystem nimmt die E-Mail also nur an, wenn amavis nichts dagegen hat. Das bringt uns rechtlich schon mal auf eine ganz andere Seite. Denn man kann uns nicht nachsagen, dass wir eine uns zur Übermittlung anvertraute Nachricht „unterdrückt“ oder dem Empfänger „vorenthalten“ hätten. Denn wir haben die Nachricht ja erst überhaupt nicht angenommen! Zusätzlich müssen wir die E-Mail nicht erst annehmen, zwischenspeichern, an amavis weiterleiten, dort wird die e-mail bearbeitet, dann wird sie wieder an postfix durchgereicht welcher sich erst nun um den weiteren Versand kümmert. Der größten Nachteile sind sicher: Amavis braucht zur Bewertung und Filterung der E-Mail etwas Zeit. Genau diese Zeit halten wir natürlich den Einliefernden Mailserver fest und auch die Verbindung offen. Zusätzlich braucht eine Bewertung/Filterung von E-Mails deutlich mehr Systemresoucen. Es werden also über diesen Weg deutlich weniger E-Mails gleichzeitig eingeliefert werden können, also wenn Postfix die E-Mails erst einmal nur annimmt und zwischenspeichert.
Um so mehr Leistung das System hat um so mehr gleichzeitig Amavis Prozesse sind natürlich möglich. Kann unser Mailserver eine E-Mail gerade nicht annehmen, da kein amavis Prozess frei ist, wird die E-Mail aber nicht einfach als unzustellbar abgewiesen. Nein es gibt einen temporären Fehler 4xx und der einliefernde Mailserver wird es einfach später noch einmal probieren.

 

Um nun amavis als smtpd_proxy_filter arbeiten zu lassen und nicht über die Funktion content_filter, müssen in der Datei: /etc/postfix/master.cf folgende Änderungen vorgenommen werden:

smtp inet n - - - 100 smtpd
    -o smtpd_proxy_filter=127.0.0.1:10024
 
amavis unix - - n - 6 smtp
    -o smtp_data_done_timeout=1800
    -o smtp_send_xforward_command=yes
    -o disable_mime_output_conversion=yes
    -o disable_dns_lookups=yes
 
127.0.0.1:10025 inet n - - - - smtpd
    -o content_filter=
    -o smtpd_proxy_filter=
    -o local_recipient_maps=
    -o smtpd_authorized_xforward_hosts=127.0.0.0/8
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_data_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

Postfix muss noch die Funktion content_filter genommen werden. Dazu müssen in der Datei /etc/postfix/main.cf noch die beiden folgenden Zeilen auskommentiert werden:

 

#content_filter = smtp-amavis:[127.0.0.1]:10024
#receive_override_options = no_address_mappings

Wichtig ist, nicht zu vergessen auch die receive_override_options = no_address_mappings auszukommentieren. Denn sonst gibt es lustige Fehler… Zum Beispiel schaut dovecot bei der lokalen E-Mail Zustellung nicht nach virtuellen alias Einträgen. Diese E-Mail werden einfach mit dieser Meldung zurückgewiesen:

 

Oct 28 00:00:12 postfix/pipe[18488]: 5FC6EE20C1: to=<kernel-error@kernel-error.com>;, relay=dovecot, delay=11, delays=10/0.01/0/1.3, dsn=5.1.1, status=bounced (user unknown)

 

Oct 31 16:00:47 dovecot: auth(default): master in: USER#0111#011kernel-error@kernel-error.com#011service=deliver
Oct 31 16:00:47 dovecot: auth(default): prefetch(kernel-error@kernel-error.com): passdb didn't return userdb entries, trying the next userdb
Oct 31 16:00:47 dovecot: auth-worker(default): sql(kernel-error@kernel-error.com): SELECT email as user, concat('*:storage=', quota_kb, 'K') AS quota_rule2, password, 5000 as uid, 5000 as gid, '/zpool/mailbox/kernel-error.com/kernel-error' as home FROM virtual_users WHERE email='kernel-error@kernel-error.com';
Oct 31 16:00:47 dovecot: auth-worker(default): sql(kernel-error@kernel-error.com): Unknown user
Oct 31 16:00:47 dovecot: auth(default): passwd(kernel-error@kernel-error.com): lookup
Oct 31 16:00:47 dovecot: auth(default): passwd(kernel-error@kernel-error.com): unknown user
Oct 31 16:00:47 dovecot: auth(default): master out: NOTFOUND#0111

 

 

IPv6 / Default Route / DNS /DHCP

Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln.

Im Grunde ist es ganz einfach:
–    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router!
–    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen.
–    Der Router verteilt sein Präfix per RA (Router Advertisment).
      o    Der Client kümmert sich um die Generierung einer IP-Adresse.
      o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.
      o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS)

Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat.

Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen.
Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen.

Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert!

Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen.

Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten!

Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk.

Noch Fragen? Dann fragen….

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑