Ganz kleine Eimer…


… (oder zumindest erst einmal einen, man ist schließlich wohlerzogen und daher bescheiden…) bräuchte man, wenn man Mäuse melken wollen würde. Und dabei ist mir im Moment sogar völlig egal, aus welchem Material dieser Eimer wäre und ob er verbeult und obendrein vielleicht sogar noch quietschebunt wäre! Ein oller Blech-Eimer wäre also schon völlig ausreichend !!! Hier dreht sich momentan alles nur um Mäuse – und um alles, was damit zu tun hat. Insofern sind mir derzeit sogar meine Mitmenschen mal völlig relativ egal – es sei denn, jemand könnte mir leihweise mit dem so dringend benötigten Mäusemelk-Equipment aushelfen – oder SPF verklickern. Das könnte zumindest die Gefahr etwas eindämmen, daß ich gleich auf den Kriegspfad ziehe und Bullys berühmten Klappstuhl ausgrabe…

Denn: Es ist mal wieder – wie der intellektülle ;-) Leser nach obenstehender Andeutung bereits erahnen mag – zum sagenumwobenen und viel beschrienen Mäusemelken… Und wenn ich den kleinen Nagebiestern nicht spätestens sofort an den Minizitzchen rumzerren kann, raste ich wohl endgültig aus und drehe komplett durch! Ich frage mich nämlich mal wieder, wie “beklopft” (“bekloppt” klingt immer so trivial…) man sich manchmal anstellen kann. Und damit meine ich einerseits mich selbst – und andererseits die FAQ- bzw. Hilfstext-Schreiberlinge gewisser ISPs…

Prolog

Wie unter Fw: Important! – HELO WORLDST-UQ3K9Q0 (bzw. WIN-NPPN1JPV75J) geschildert, leiden einige unsere bisherigen, aktuellen und evtl. sogar zukünftigen ;-) Kontakte unter massiven Spam-Attacken, die SCHEINBAR von uns ausgehen. Zum Glück für uns handelt es sich “nur” um E-Mail-Spoofing bzw. einen sogenannten Mail-Joe-Job – soll heißen: Die Mails sind gefälscht und stammen nicht von uns. Trotzdem ist das natürlich sehr ärgerlich und kann uns in keinster Weise dazu verleiten, uns aufgrund dieser Erkenntnis entspannt zurückzulehnen… Denn:

a) Unsere Kontakte werden ja trotzdem nach wie vor belästigt und evtl. sogar durch etwaige bösartigen Inhalte gefährdet.
b) Unsere Reputation als Kontakt leidet darunter natürlich immens, erst recht die als IT-Fuzzis – jeder denkt natürlich, wir hätten Schadware auf den Rechnern…
c) Fragwürdig ist nach wie vor, wie die Gauner an die Adressen der Opfer gelangt sind. Immerhin spricht zwar alles für ein Sicherheitsleck beim Provider (siehe verlinkter Beitrag) – aber wer glaubt einem das?
Siehe Forenbeitrag von “SoulOfDarkness” vom 21.09.2015,
siehe Kommentar vom “genervten Admin” vom 01.10.2015,
siehe Kommentar von “Anonymous” vom 09.11.2015 und
siehe Kommentar von “amayr” vom 09.11.2015,

Daher hüpfte ich heute auf einmal wie ein Flummi vor Freude bis an die Decke, als ich auf der Suche nach Updates zu dem seit Mitte/Ende August massiv auftretenden Problem auf einer 1&1-Admin- bzw. Postmaster-Seite etwas vom Sender Policy Framework las.

SPF (Sender Policy Framework) ist eine Technik, die das Fälschen von Absenderadressen erschweren soll. Hierzu wird festgelegt, von welchen IP-Adressen der Versand von E-Mails mit einer bestimmten Absenderdomain erfolgen darf (respektive von welchen IP-Adressen ein Versand nicht erfolgen darf). Dazu wird in der DNS-Zone ein Ressource Record vom Typ TXT (oder falls vorhanden SPF) hinterlegt, der alle berechtigten IP-Adressen auflistet, diese Domain als Absenderadresse zu verwenden. Zur Überprüfung Ihres SPF-Eintrages empfehlen wir Ihnen den so genannten “SPF-Wizzard” auf den Seiten von Openspf.org

Das beste war, daß 1&1 lt. einem Forumpost bei Antispam-eV.de SPF unterstützen soll:

… »Den Webhoster überprüfen lassen, ob der Mailserver einen sogenannten “SPF-Eintrag” im DNS hat. Mit diesem “SPF-record” wird sichergestellt, dass Mails mit Absendeangabe Ihrer Domain nur von einem bestimmten Mailserver (nämlich dem Ihres Hosters bzw. von Ihrem eigenen Mailserver) von einer festgelegten IP-Adresse aus gesendet werden dürfen. Da die meisten Mailprovider weltweit inzwischen die SPF-records bei der Mailannahme prüfen, wird dann kaum noch irgendwo ein Mailprovider Spam-Mails mit Ihrer Domain, aber unpassender IP, annehmen.«
….
Das geht z.B. bei STRATO ganz einfach über Domainverwaltung, DNS-Einstellungen, TXT-Record inklusive SPF-Einstellungen, und dann ‘aktiviert’. Andere Hoster (1&1 etc.) haben ähnliche Einstellungen…

Und gemäß einer Meldung vom 05.08.2015 ist das bei 1&1 nun auch tatsächlich der Fall.

Soweit so gut. Oder sollte ich sagen: “Soweit so schlecht?” Denn dann ging es los…


“SPF – Ver(w)irrungen auf dem Wege zur Erkenntnis”
oder
“Die Odyssee durchs Netz in 23 Akten”

Ein gepflegtes “Pfffff….” bekomme ich ja gerade noch so – sogar im Vollrausch – formuliert… Aber einen SPF-Record im DNS? Wo ich mich letztens gerade extrem körperlich verausgabt (=> Mausarm *lol*) habe, nur um hier unter Einsatz meines Lebens den DNS-Server BIND 9.8.1 einzurichten? Ich möchte die nächsten 3 Jahre bitte nur noch an Desoxyribonukleinsäure denken, wenn ich DNS höre – und nicht an irgendein nerviges Domain Name System… Ergo: Ich muß mal wieder büffeln, damit ich auch weiß, was ich wie und auf welche Weise wann wo warum und wozu mache. I need also sozusagen etwas Input in Sachen Syntax! Befragte ich also Freund Google…

1) Das erste, was auffiel: Die Suchwörter “1&1” und “SPF” in Kombination liefern ganz tolle, superhilfreiche und vor allem extrem allgemein gehaltene Hilfstexte a la “Wenn in China ein Sack Reis umfallen soll, benötigen Sie neben der Schwerkraft auch noch einen Sack Reis in China.” bei 1&1. Soll heißen: Wenn Sie einen SPF-Eintrag anlegen wollen, tragen Sie doch einfach einen ein! Hammer !!!

2) Der Rest, der einem auf den ersten Blick bei Google ins Auge sticht, ist entweder englisch oder veraltet. (“1&1 bietet nicht die Möglichkeit für TXT-Records…”)

3) “E-Mail-Spoofing“, “Eintrag anlegen”, “Anleitung” etc. als zusätzliche Suchwörter bewirken so ziemlich gar nichts – es sei denn, sie “verschlimmbessern” die ausgegebene Erbenisliste noch.

4) Die englischen Seiten zu SPF- bzw. TXT-Records liefern zwar ganz tolle Bilder engländischer Webinterfaces bei 1and1 (also bei “2″) – aber was in 3-Teufelsnamen soll v=spf1 a mx ptr ~all darstellen? Kann mir auch mal jemand diese 4 Sachen hinter spf1 vernünftig erklären, damit ich nicht 5 Fragezeichen in meinen 6y Geleemurmeln habe? ;-)

5) Zwischenzeitlich war ich nämlich auch schon mal bei Wiki und bei OpenSPF und habe dort etwas von SoftFail und Neutral gelesen. Helfen mir dann die Qualifikatoren ~ oder ? wirklich weiter? Und wenn + für Pass als Standard steht – brauche ich dann nicht höchstwahrscheinlich ein klitzekleines - für ein (Hard)Fail ???

6) Witzig ist, daß mal von Host, mal von Client, mal von Sender geschrieben wird. Was die Termini a, mx & Co so halbwegs bedeuten, ist ja nicht einmal mir neu. Von A-Record und MX-Record habe nämlich sogar ich schon mal was gehört. ;-) Aber gebe ich nun bei include: meine betreffende bzw. eher “betroffene” Domain an, damit eine SPF-Anfrage dann die dazugehörige Server-IP rausrückt? Warum stehen in manchen Beispielen bei ip4: ganze Netze mit Präfixen? Wieviele IPs hat ein Server? Ok – es gibt Cluster bzw. Load Balancing… aber /16er Netz? Geht es da um die Adressen des Clients? Wer ist der “Sender”, der “Host”? MX-Records sagen ja eher meinen Kontakten, wohin sie ihre Mails schicken sollen, wenn sie mich erreichen wollen… Sollte man dann nicht eher mout.kundenserver.de statt mx00.kundenserver.de  und mx01.kundenserver.de für ein 1&1-Paket eintragen? Fragen über Fragen… – wahrscheinlich, weil ich wie immer mal wieder viel zu kompliziert denke.

7) Wenn man sich nun nicht in 5 min ein paar Grundlagen anlesen kann, weil man schon 30 min sucht und irgendwie nichts wirklich aussagekräftiges findet, da man in Ermangelung eines 20-jährigen Informatikstudiums den gefundenen, einem inkompatibel erscheinenden  Output nicht als eigenen Input verwenden kann, braucht man also TOOLS & UTILITIES  !!! Geile Idee! ;-)

8) Gedacht, gesucht, gefunden. Zumindest theoretisch. Der im obigen ersten Zitat genannte “Wizzard” ist weder auf der Startseite noch über die Suche bei OpenSPF.org zu finden. (Geht also schon mal gut los…) Sucht man clevererweise nach “Wizard” oder schaut unter Tools nach, stellt man fest, das es eben diesen zauberhaften und zaubernden Assistenten letztlich “… wegen der Schwierigkeit der korrekten Erläuterung der zugrunde liegenden Konzepte…” nicht mehr gibt. Die Ergebnisse wären nämlich oft zu komplex oder funzten nicht, wenn Leute, die die Feinheiten nicht kannten, nur schnell mal im Vorbeigehen einen Eintrag erstellen wollten. (Also solche doofen Vollpfosten wie ich… – suuuuuuuuuuuuuuper Erklärung!  *LOL*  !!!) Sind wir denn hier bei OpenSPF.org – oder auf Mein-Privates-Tool-Sammelsurium.de mit tausend toten Links ??? Das ist ja fast so, als wenn man ‘ne Pressemitteilung läse, in der stünde, daß man bei Winzigweich in Redmond, Virginia, USA alle Festplatten formatiert hätte und auf Linux umgestiegen wäre, nur weil die berühmte “Fenster”-Software zu buggy ist… ;-)   Ich meine: Bei OpenSPF kriegt man es nicht hin, daß man verständlich (!)  vom Assistenten geführt wird, so, daß es hinterher auch funzt? Von wem darf man sowas denn dann erwarten?

9) Na von Microsoft (oder/und meinem Hirn) wohl auch nicht. Denn  was die Jungs und Mädels bei OpenSPF meinten, durfte ich als “DAU” live auf Microsofts Anti-Spamtools.org erleben. Ich hatte zwar nach ein paar Klicks augenscheinlich einen ganz passablen SPF-Record erzeugt – aber der funzte natürlich nicht !!! ;-) Scheiß DAUs… (also ich, meinereiner und meine ganzen ebenso tumben Alter Egos) !!!

10) Aber weiter. Ich eiere ja erst ‘ne Stunde rum und habe noch genug Langeweile. 64-seitige, undeutsche Kampfschriften :-) wie den englischsprachigen RFC7208 lese ich erst, wenn ich bettlägrig bin und mich gar nicht mehr wehren kann… Grundlagen sind zwar immer gut – aber man kann es ja auch übertreiben… Denn wie sieht es aus? Ich habe eine – wenn auch englische – Beschreibung zur Syntax – und ein Tool, das irgendwie irgendwas (!) erzeugt. Wie ich das einzugeben habe, weiß ich auch schon. Na ja – zumindest fast. Fast?  Gleich….  – einen Moment Geduld bitte! ;-)

11) Ich muß mich bezüglich meiner Handlungsweise beim Eintragen nämlich entscheiden, ob mich 1&1 einfach nur ein bißchen rassistisch diskriminieren oder aber hochgradig verwirren will. Erstens wurde ja – wenn ich das richtig gelesen habe, RFC4408 durch den 7208er  überflüssig. Soll heißen, man macht eigentlich gar keine dedizierten SPF-Einträge (= spezielle TXT-Einträge) mehr, sondern nur noch TXT-Einträge, die mittlerweile multipel nutzbar sind… Da ist das schon mal witzig, daß mir 1&1 jetzt, mehr als 1 Jahr nach der Verabschiedung dieses RFCs das UNDOKUMENTIERTE  Anlegen dedizierter SPF-Records ermöglicht. Wow!  Nun, mehr als 2 Nameserver gibt es ja auch erst seit einigen Dutzend Wöchelchen… – lt. entsprechendem, jahrealten RFC vom Juli 1997 sollten es aber mind. 3 und max. 7 sein… Und alte 1&1-Hostingverträge dümpeln immer noch mit ihren nur 2 NS rum.. Hinzu kommt, daß 1and1 Einträge als TXT-Record ohne Anführungszeichen vorsieht; ich als Deutscher hingegen soll bei 1und1 einen SPF-Record mit Anführungszeichen anlegen. Wird das jetzt wirklich unterschiedlich gehandhabt? Oder ist das ein Fehler? Denn dank Wartezeit bei der Übernahme des Eintrags macht Testen ja nicht wirklich viel Spaß… Man will ja schließlich auch mal den Eintrag abrufen und sehen, ob alles funzt.

12) Stichwort Abrufen. Hähä… ;-) Syntax, Tool und 2 Möglichkeiten, etwas einzutragen habe ich also. Daß es darum geht, eine Verifikation von HELO oder/und MAIL FROM durchzuführen, habe ich ja durchaus schon rausgelesen. Und daß es bei Weiterleitungen oder bei Webformularen Dritter Probleme mit SPF geben kann, habe ich auch schon mitbekommen. Sender-ID soll daher irgendwie besser sein – wirklich besser ist aber angeblich DKIM !!! Zur kompletten Verwirrung reicht es mir aber zum Glück noch nicht – denn noch (!) habe ich eine ungefähre Vorstellung von dem, was ich glaube machen zu müssen bzw. machen zu wollen… ;-)   Müßte ich ja nur noch irgendwie checken, ob ich auch richtig liege – wenn ich genug Sitzfleisch hätte, nach fast jedem Testeintrag gefühlte 10 min zu warten, bis letzterer greift… Und spätestens damit gehen die Probleme dann gleich weiter: Try & Error vom Allerallerfeinsten!

13) Nachdem ich etliche Bestätigungen für einige meiner neuen “Erkenntnisse” auf MSXFAQ.de fand und dort auch noch solche selten schönen “xml-artigen Outputse” ;-)   wie diesen hier

C:\Users\root>nslookup
Standardserver:  fritz.fonwlan.box
Address:  192.168.178.10
> set q=TXT
> _ep.netatwork.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
Nicht-autorisierende Antwort:
_ep.netatwork.de        text =
"<ep xmlns='http://ms.net/1' testing='false'><out><m><a>80.66.20.18</a><
/m></out></ep>"
>

sah, war ich der irrigen Annahme, ich könnte jetzt meinen bei der Testdomain faett-boys.de gesetzten  SPF-Record auch mit nslookup auslesen. Das war aber ein Trugschluß – zumindest noch zu diesem Zeitpunkt. Mein schnödes Ergebnis sah leider so aus und entsprach nun so überhaupt nicht meinen Vorstellungen:

C:\Users\root>nslookup
Standardserver:  fritz.fonwlan.box
Address:  192.168.178.10
> set q=TXT
> faett-boys.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
faett-boys.de
primary name server = ns5.schlund.de
responsible mail addr = hostmaster.schlund.de
serial  = 2015080801
refresh = 28800 (8 hours)
retry   = 7200 (2 hours)
expire  = 604800 (7 days)
default TTL = 600 (10 mins)
>

Den Abfragetyp kann man zwar auf alles mögliche festlegen (A, AAAA, A+AAAA, ANY, CNAME, MX, NS, PTR, SOA, SRV – TXT ist witzigerweise nicht aufgeführt) – nur eben nicht auf SPF. Was zum Geier ist _ep im ersten Beispiel zu nslookup? Und warum zeigen einige der bis dahin noch unverständlichen Bilder solche “Subdomains” wie _spf? Daß eine scherz- bzw. testhalber getätigte Abfrage auf _spf.1und1.de sogar ein scheinbar nützliches Ergebnis hervorbrachte, merkte ich erst wesentlich später….

> set q=TXT
> _spf.1und1.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
Nicht-autorisierende Antwort:
_spf.1und1.de   text =
"v=spf1 a:moi.1and1.com a:moint.1and1.com a:mxint01.1and1.com a:mxint02.1and1.com a:mbulk.1and1.com a:mout.kundenserver.de a:mout.perfora.net -all"
>

Zumindest war das die Bestätigung, daß auch mein nslookup funzt und keine versionsbedingten Eigenarten aufweist… Bloß faett-boys.de ist störrisch… Also ist wohl was mit meinem SPF-Record faul… Oder so ähnlich. Da ich jedenfalls nicht das sah, was ich glaubte sehen zu wollen oder zu müssen, suchte ich natürlich weiter. Der Wizzard wizzzzzzzzardete ja bekanntlich nicht mehr – aber die Sektion “Tools” auf OpenSPF bot ja noch mehr – so z.B. das Beveridge Hosting DNS Lookup – das mir doch tatsächlich zumindest so lange einen SPF-Record zu faett-boys.de anzeigte, wie sein Ergebnis neutral war. Ich schaffte nämlich natürlich wie jeder rumspielende DAU ohne Peilung ziemlich schnell im Laufe meiner Tests, ein permerror und ein fail zu erzeugen – und von SPF-Records sah ich dann bei diesem grandiosen, auf dig basierenden Test weit und breit nichts mehr! Als wenn gar kein Eintrag existieren würde! Der geneigte Leser wird spätestens jetzt erahnen, daß ich noch eine andere Möglichkeit des Testens gefunden habe – und er liegt damit richtig! Nachdem ich dummerweise kurz mal abschweifte und Richtung DKIM luscherte (weil ich zwischenzeitlich den Anflug einer vollen Nase in Sachen SPF verspürte…), kam ich auf die überaus geniale Idee, bei SenderScore.org Zeit zu investieren. Schließlich fand ich im Laufe meiner Recherchen folgenden Text bei ReturnPath.com:

Denken Sie auch an Systeme, die in Ihrem Namen bzw. im Namen Ihrer Domains E-Mails verschicken. Um sicherzugehen, dass Sie alle diese Domains erfasst haben, empfehle ich das Return Path-Tool Reputation Monitor. Um sich einen ersten Eindruck zu verschaffen können Sie auch die kostenlose senderscore.org Webseite nutzen. Bei Sender Score geben Sie den Namen der von Ihnen genutzten Domain ein. Am Ende der Seite erhalten Sie dann unter dem Punkt „Related Sending Domains“ eine Übersicht über alle Domains, die E-Mails unter Ihrem Brand versenden. Außerdem ist es sinnvoll, sich mit den Kollegen vom Kundenservice, Ihren internen IT-Administration und natürlich Ihrem E-Mail-Service Provider kurzzuschließen, um die Einführung von DKIM-Signaturen für alle E-Mail-Ströme sicherzustellen.

Klar – ich gab die Domain (faett-boys.de) ein – ich wollte ja sehen, welche Systeme so Mails in diesem Namen versenden. Das “kostenlose Tool” toolte aber nicht -  ich sollte mich erst registrieren. Gleich mit einem komischen Gefühl in der Magengegend zog ich los, diesem Ansinnen Folge zu leisten. Widerwillig, wohlgemerkt !!! Das gipfelte darin, daß ich eine Trash-Mail-Adresse als E-Mail angab, eine 0190-6×6-Rufnummer und lächelnd von 50 Mio versandter Mails pro Monat schwärmte. Es hat mich wirklich gewundert, daß ich nicht noch Schuhgröße, Gewicht und  Brustumfang ein- bzw. angeben mußte. Und wat sah ick anschließend? Nüscht. Nix. Nada. Niente! Nothing! Ok – fast nichts: Ich hatte lt. Sender Score mind. einen MX-Record. Und ein SSL-Zertifikat. Man zeigte mir sogar die Domain dafür an! Woooooooooow! Der (mittlerweile erfolgreich woanders getestete) SPF-Eintrag wurde hingegen nicht ermittelt. Wozu auch? Immerhin will mir die Truppe ja die Vollbetreuung in Sachen DKIM verkaufen, wenn ich meine kursorische Lesebegabung nicht über Nacht verloren habe…. Die verschwommenen Grafiken über den Listen waren weg – aber die vorher angedeutetetn Listen waren dafür jetzt leer. Also Luftnummer! Daß mein ungutes Gefühl richtig war, merkte ich daran, daß ich bei jeder Abfrage – auch als Registrierter – mit der Lupe so ein bescheiden schönes Captcha für Leute entschlüsseln mußte, die irgendwas zwischen halbblind und halbblöd sind… Sorry Leute – nichts zu finden ist das eine (das mag ja sein – gerade ich als DNS-/SPF-DAU kann da nicht mitreden – habe vielleicht was falsches erwartet….)… Mutwillig mit solchen als Captcha getarnten Exkrementen gequält zu werden steht aber auf einem ganz anderen Blatt. Ungerecht? Beschwerden zu meiner bösen Captcha-Kritik könnt Ihr gern an wurst@trash-mail.com senden! Zur Ehrenrettung muß ich anführen, daß zu einer anderen mir bekannten Domain die “versendenden Systeme” korrekt ermittelt wurden…  Aber weiter…

14) Ich stellte mir gerade die Frage, ob ich Selbstmord begehe oder stattdessen lapidar die Spam-Opfer bemitleide und mich anschließend doch einfach zurücklehne – oder ob ich meine gesammelten Erfahrungen für die Nach- oder auch Jetztwelt niederschreibe – je nachdem, ob ich nun doch noch Suizid begehe oder nicht…. (Denn den Eimer für die Mäusemilch habe ich immer noch nicht. Ich bin also gaaaaaanz dicht davor…)  Doch nun kommts: Da – endlich! Es geschehen doch noch Zeichen und Wunder! Nun schon bei Pkt. 14 der “Schnell”-Fortbildungs-Odyssee angelangt kommen wir, wie es scheint. doch endlich in den grünen Bereich!  Ein Tool hat sich tatsächlich als nützlich erwiesen: Im Tool-Bereich von OpenSPF findet man nämlich folgenden Hinweis:

“Port25.com provides another tool to test whether your SPF record is working. Send an e-mail to check-auth@verifier.port25.com and you will receive a reply containing the results of the SPF check.”

Und soll ich Euch was sagen? Das scheint auch ganz hervorragend zu funzen!

15) Der Eintrag “v=spf1 a ptr ip4:212.227.146.25 mx:mx00.kundenserver.de mx:mx01.kundenserver.de -all” lieferte ein klassisches, aber dennoch extrem unschönes fail - aber ich erfuhr so (über den Inhalt der Ergebnis-Mail) von der Existenz geschätzer 18.743 1&1-Mail-Ausgangsserver-IP-Adressen hinter mout.kundenserver.de.

16) Der Eintrag “v=spf1 a ptr ip4:212.227.146.25 mx:mx00.kundenserver.de mx:mx01.kundenserver.de mx:mout.kundenserver.de -all” lieferte ebenfalls ein gepflegtes fail - logisch! Was war MX doch noch gleich? (Der MX Eintrag in ihrer DNS-Zone teilt allen anderen Mailservern der externen Welt mit, auf welche IP-Adresse diese ihre Post für ihre Domäne einwerfen können.) Nun ja – ein sogenannter gedanklicher Schnellschuß – mout hört sich schließlich irgendwie nach etwas anderem an!

17) Übrigens  – und ich hoffe mal, daß ich halbwegs alles richtig übersetzt und kapiert habe: Diese Einträge wurden sogar mit dem Mikro-Saft-Wizard erstellt… ;-)   So langsam verstehe ich, warum die Fuzzis von OpenSPF ihren “Zauberer” in die Verbannung geschickt haben… *lol*… Scheiß DAUs! ;- ) ;- ) ;- )  Ich gucke ja niemanden komisch an – und erst recht nicht in den Spiegel!  Irgendwas scheint wohl zu fehlen… Nun ja – es war schön spät… Oder früh? Egal – es war dunkel… Aber weiter:

18) Nach noch ein wenig mehr genossener Test- und Wartezeit erzielte ich tatsächlich ein relativ unverdächtiges neutral - wahrscheinlich, weil ich in dem Moment den Quatsch im vorigen Punkt noch nicht als solchen verstand und nun erst einmal testhalber die Anführungszeichen bei 1&1 wegließ… Die Quittung kam prompt: Kein SPF-Record in der Result-Mail von Port25 erkennbar! Neutraler gehts nicht! Haha!

19) Ein fast spartanisch anmutendes “v=spf1 a include:faett-boys.de +a +mx -all” (alle A-Records, alle MX-Records… und dummerweise auch alles, was von faett-boys.de kommt – z.B. wenn ein Formular versandt wird – so die Überlegung…) gipfelte in einem überaus verführerischen permerror. Ich steigerte mich also! ;-) Was ich zu diesem Zeitpunkt wohl hinter a vermutet haben mag, frage ich mich jetzt lieber nicht… Außerdem hatte ich da noch nicht verinnerlicht, daß ich mit include: sozusagen SPF-Records von irgendwoher (z.B. dem Provider) importieren will… Insofern war faett-boys.de zu inkludieren natürlich hochgradiger Käse. Tja, ich habe scheinbar ADLS – alt, debil, mit Limburger-Syndrom…

20) Aber sowas macht mich ja erst richtig geil. Jeder andere – wenn er denn überhaupt so lange ausgeharrt hätte – hätte spätestens jetzt seinen Computer mit seiner Schwiegermutter erschlagen. Oder wenigstens umgekehrt… ICH aber nicht. Denn ich bin geizig: Computer sind teuer! ;-)

21) Zurück zum Thema: Wie war das gerade? Geradezu spartanisch? Das war ja wohl nur ein Witz! Es geht doch noch viiiiiiiiiiiel kürzer! Wozu etwas inkludieren, wenn es gar nicht da ist… (Denn: Weitere Records zu SPF sind ja unter der Adresse nicht zu finden, oder?) A-Records, MX-Records – und fertig! Oder so ähnlich. Der Ansatz “v=spf1 +a +mx -all” brachte zwar auch nur ein dämliches fail zu Tage – aber ich näherte mich zumindest der Lösung, wie es mittlerweile scheint! Sieht ja fast so aus wie der ominöse Eintrag unter Pkt. 4)… Ich hätte den mal einfach abmalen sollen – und gut…

22) Aber der Denkprozeß begann allmählich. Wenn A-Records und MX-Records nicht ausreichen – was fehlt denn dann noch? Mein DSL-Netz, in dem mein Client steht? Mit NITRO oder NAPALM als HELO? Oder gar NITRO/NAPALM.local ??? Wird das übermittelt? (Klar – früher gab es unter  http://schizo-bl.kundenserver.de sogar eine Blacklist bei 1&1, auf der man landete, wenn man zu oft mit einem anderen HELO-String mailte…) Jemand, der einen originalen Mail-Header von mir anguckt, kann seinen Rechner doch auch so nennen – dann wäre das alles doch ziemlicher Blödfug. Oder sollte ich als ip4: ein 93.214.0.0/16-Netz eintragen – weil aus diesem Pool meinen Public IPs stammen? Oder eher irgendwo irgendwie noch sowas wie p5DD60789.dip0.t-ipconnect.de ???  So langsam fing ich an, zu überlegen, ob ich nicht doch lieber auf Schuhputzer umsatteln sollte. Für IT a.k.a. EDV war ich wohl zu blöd… Oder doch nicht? Was war noch mal MX? Dann brauche ich ja wohl eher doch sowas wie  mout.kundenserver.de in meinem Record…

23) Hm – toller Trick! Ich weiß ja mittlerweile, wie eine Antwort- bzw. Result-Mail von Port25.com aussieht. Soll ich das jetzt wirklich alles als ip4: einklimpern? Dann droht definitiv ein mittelprächtiger Mittelfinger-Katarrh!

faett-boys.de. 3600 IN A 212.227.146.25
faett-boys.de. 3600 IN MX 10 mx00.kundenserver.de.
faett-boys.de. 3600 IN MX 11 mx01.kundenserver.de.
mx00.kundenserver.de. 1695 IN A 212.227.15.41
mx01.kundenserver.de. 468 IN A 217.72.192.67
187.126.227.212.in-addr.arpa. 86400 IN PTR mout.kundenserver.de.
mout.kundenserver.de. 78284 IN A 212.227.126.133
mout.kundenserver.de. 78284 IN A 212.227.17.24
mout.kundenserver.de. 78284 IN A 217.72.192.75
mout.kundenserver.de. 78284 IN A 212.227.126.135
mout.kundenserver.de. 78284 IN A 217.72.192.73
mout.kundenserver.de. 78284 IN A 212.227.126.131
mout.kundenserver.de. 78284 IN A 212.227.126.130
mout.kundenserver.de. 78284 IN A 212.227.126.134
mout.kundenserver.de. 78284 IN A 212.227.17.13
mout.kundenserver.de. 78284 IN A 212.227.126.187
mout.kundenserver.de. 78284 IN A 212.227.17.10
mout.kundenserver.de. 78284 IN A 217.72.192.74

Doch halt… – gab es da nicht noch PTR ??? Und siehe da: Der SPF-Record “v=spf1 a mx ptr:mout.kundenserver.de -all” erzeugt sage und schreibe ein niedliches pass !!! Ziel erreicht!

Oder? Da man PTR-Queries ja wohl eigentlich vermeiden sollte…
Hm… Hmm… Hmmm ???

Und wenn ich mir dann zu allem Überfluß noch diese Liste mit Mailservern von 1&1 ansehe, habe ich ja eigentlich nur an der Oberfläche gekratzt… Aber stop! Konnte man nicht die SPF-Records des ISP inkludieren? Mit include:_spf.1und1.de?
Hmmmmmmmmmmmmmmm!

Also testen wir mal, welches Resultat “v=spf1 a mx include:_spf.1und1.de -all” liefert…
Und?

PASS !!! ;-) ;-) ;-)


Epilog

Der Gag bei der ganzen Geschichte: Als ich dann zum 83. Male meine Niederschrift hier beäugte, um alles augenkrebsfördernd bunt zu machen und mit zahlreichen Links zu bestücken, fiel mir bei der Suche nach einer unlängst aufgerufenen Seite mit dem Suchwort “SPF-Record” über die Google-Suchergebnisseite der URL http://www.spf-record.de in die Hände… Ein Generator, den sogar ich verstehe, weil er a) kurz und knapp und b) sogar deutsch ist  – und obendrein sogar noch auf Anhieb funzt! Denn was spuckte er aus, nachdem ich die Fragen artig beantwortet habe? Na?

Den anzulegenden Eintrag “v=spf1 a mx include:_spf.1und1.de -all” !!! Und wenn ich erlaube, daß auch Mails über Subdomains gesendet werden, dann kommt in dem Fall das böse, böse PTR ins Spiel: “v=spf1 a mx ptr include:_spf.1und1.de -all”… Geil, wah? :-)

Puh – Schwein gehabt… Brauche ich wohl doch noch nicht zum Schuhputzer umzuschulen… Es wurde nämlich genau das kreiert, was ich mir in einer stundenlangen, schweißtreibenden und wutfördernden Session angelesen und ausgetestet habe… Allerdings hätte mir dieser Generator eigentlich von Anfang an vollauf gereicht… Nun gut – dümmer geworden bin ich durch diese “Session” auch nicht. Aber kann man sowas bitte nicht irgendwo VERNÜNFTIG erklären, so daß DAUs und auch Leute, die immer viel zu kompliziert denken, das auch verstehen, ohne sich Infos von hundert Seiten, von denen ein Drittel veraltet und fast 2 Drittel englisch sind, zusammenklauben zu müssen? Gut – von PC-Enthusiasten wie Bloggern oder Wiki-Betreibern/-Nutzern kann man das nicht verlangen… Ich könnte ja jetzt (FAST :-) ) selbst ‘ne Doku schreiben und mit gutem Beispiel vorangehen… Von 1&1 möchte ich sowas im Hilfebereich aber verlangen dürfen !!!

Übrigens: Daß 1&1 nicht so ganz auf der Höhe der Zeit ist, (SPF-Record statt TXT-Record, RFC4408 vs. RFC7208 oder auch Anzahl der Nameserver nach RFC2182 Sektion 5 (2 NS vs. 3-7 NS) bei Altverträgen), vermutete ich ja schon “auf dem Weg hierher” (bis zu Zeile 17.851 dieses Pamphlets oder so *lol*)… Denn: Nachdem ich bei 1&1 in den DNS-Einstellungen für faett-boys.de meinen letzten Wissensstand einklimperte, stellte ich frecherweise den Eintragstyp von SPF auf TXT um – gemäß RFC! Und siehe da:

Beveridge Hosting DNS Lookup (dig) spuckt im Gegensatz zu vorhin diese Zeile aus:
faett-boys.de.        3600    IN    TXT    “v=spf1 a mx include:_spf.1und1.de -all”

Auch das Lookup-Tool von SPF-Record.de findet JETZT meinen SPF-Eintrag, was es noch nicht tat, als er noch ein “dedizierter SPF-Record” und kein “TXT-Record” war…

Und was soll ich Euch sagen? Sogar bei SenderScore.org  findet man NUN einen SPF-Record…

Auch das zischenzeitlich bei Mail-Tester.com gefundene Test-Tool findet den Eintrag:
1 SPF record found for the domain faett-boys.de :
“v=spf1 a mx include:_spf.1und1.de -all”

Das allerbeste jedoch ist, daß sogar nslookup JETZT endlich die Ausgabe erzeugt, die ich schon vor Stunden sehen wollte:

C:\Users\root>nslookup
Standardserver:  fritz.fonwlan.box
Address:  192.168.178.10
> set q=txt
> faett-boys.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
Nicht-autorisierende Antwort:
faett-boys.de   text =
"v=spf1 a mx include:_spf.1und1.de -all"
>

Ist das Leben nicht schön? ;-)

Bleibt immer noch die Frage was wäre, wenn der böse Spammer auch bei 1&1 Kunde ist und über dieselben Server seinen Dreck verbreiten würde… Inwiefern würde dieser Eintrag dann meine Echtheit beweisen? Also scheint ja noch was zu fehlen (und wenn’s nur bei mir im Kopf ist)… Stichwort HELO oder so… Aber zumindest die Fuzzis in Malaysia, Uruguay und Japan, die in der Vergangenheit die Mail-Adressen der Fätt-Boys so schamlos mißbrauchten, sollten nun eigentlich erst mal außen vor bleiben – sofern die Mail-Server der Provider “unserer” Spam-Opfer den SPF-Record auswerten. Mal sehen, ob der zwischenzeitlich schon mal abgeklungene und seit 3 Tagen geradezu wieder hyperaktiv auftretende Spam in unserem Namen evtl. endlich nachläßt…

Es sei mal dahingestellt, wie sinnvoll dieser Eintrag sein mag – oder eben auch nicht… ;-) Doch entweder ist dieser eigentlich schon alte Hut für manche in Deutschland das ultimativ Neueste auf dem Markt (*lol* – siehe RFC-Datum oder Forenbeiträge von 2006) – oder bei 1&1 hat man Angst, daß jemand SPF nutzen und daran verzweifeln könnte. Denn Halbwissen reicht scheinbar wirklich nicht. Und gar kein Wissen erst recht nicht. Den wirklich tollen Generator von SPF-Record.de in allen Ehren – aber woher bekomme ich die Info, daß 1&1 unter _spf.1und1.de inkludierbare SPF-Records bereitstellt? Wenn man seitens 1&1 schweigt, versucht es niemand – und kann sich dann auch nicht beim Support melden… Oder wie jetzt? Ich kann jedenfall meiner Meinung nach ETWAS mehr, als nur einen Rechner einzuschalten – und ich sehe mindestens auf diesem Gebiet immensen Nachholbedarf. Ich denke jetzt schon, daß DKIM wohl die bessere Wahl ist: Ich besorge mir per OpenSSL ein Schlüsselpaar, lege einen TXT-Record an, benenne meinen  (_)selector._domainkey ggf. in (_)irgendwas._domainkey, (_)dkim._domainkey, (_)MyFirstDKIM._domainkey oder sonstwas um – trage ihn dann als Präfix ein und gebe meinen öffentlichen Schlüssel im Textfeld an. Dieser ist anschließend (je nachdem, ob er mit Unterstrich beginnt oder nicht…) unter dkim._domainkey.faett-boys.de oder eben unter _dkim._domainkey.faett-boys.de abrufbar. Nun kann man sogar Schlüssel oder/und Selektor alle paar Tage ändern, jeder Mail-Kampagne eigene Schüssel/Selektoren usw. verpassen… Was ich noch nicht gelesen habe: Wie ich meinem Mail-Client den privaten Schlüssel einimpfe – wenn das überhaupt geht. Wenn, dann wahrscheinlich importieren, ggf. über den dazugehörigen Browser bzw. die dazugehörige Zertifikatsverwaltung – so wie ein Zertifikat für digitale Signatur… Allerdings steht an der Stelle für die digitale Signatur ja schon mein Comodo-Zertifikat… Gleich schreie ich wieder nach ‘nem Eimer! Grrrrr! Dieses Mal brauche ich aber einen großen – für etwas unschönes anderes… (Mäusemilch ist mittlerweile out.)

Es sieht aber leider gemäß der ersten 384 Dokumente, die ich gerade mal schnell überflogen habe, so aus, als wenn der private Schlüssel auf dem Mail-Server abgelegt werden muß… Zumindest deutet “Please copy the below text into a new file onto your server. You can name the file _dkim.faett-boys.de.pem for easy reference. You can save the file to C:\pmta on windows or /etc/pmta on linux…” verdächtig eindeutig darauf hin… Zumindest verklickert mir das der testhalber mal angeschmissene DKIM-Wizard von Port25.com

Aber habe ich auf den MTA / Mail Transfer Agent / Mailserver Zugriff? Nein… Aber wozu bietet mir 1&1 dann die Möglichkeit an, den DNS-Einstellungen einen TXT-Eintrag samt Selektor und öffentlichem Schlüssel für DKIM hinzuzufügen? Falls ich mir mit PHP einen Mail-Client progge und dann per sendmail des Webservers verschicke? Da schweigt man sich bei 1&1 mal wieder beharrlich aus; es ist alles sogar noch viiiiiiiiiel “besserererer” dokumentiert als SPF… :-(   Zu diesem ebenfalls mittlerweile uralten Hut finde ich nicht mal Bildchen englicher 1and1-Kunden… :-(

Ich glaube, ich werde den Support von 1&1 mal exzessiv nerven!

Oder ich befasse mich lieber erst einmal mit DKIM-Proxy… Das liest sich nämlich auf den ersten Blick ganz gut… :-)

Und wenn ich schon nichts Wichtiges weiß – eins weiß ich: Ich werde diesen subhumanoiden, kriminellen und mafiösen Drecks-Spammern jedenfalls nicht das Feld kampflos überlassen. Nicht ohne Gegenwehr!

Wer ein Hosting-Paket bei 1&1 hat, kann das mit dem SPF-Record in den DNS-Einstellungen zur Domain ja mal testen. Vielleicht hilft es ja gegen die Spoofer… Was allerdings Leute machen können, die nur eine Mail-Adresse irgendwo haben, übersteigt meine Phantasie nun auch…

Auf jeden Fall werde ich bei Gelegenheit mal posten, ob der gespoofte Spam nachgelassen hat…

PS:
Da ich von Natur aus ein sehr neugieriger Mensch bin, ließ mir das Input-Feld “Präfix” mit dem Hinweis “Dieses Präfix wird für den Eintragnamen verwendet. Nur für DKIM-Einträge erforderlich…” in der DNS-Verwaltung von 1&1 natürlich keine Ruhe., zumal mir die oben erwähnten _ep- und _spf-”Subdomains;-) noch im Gedächtnis waren. Die Ähnlichkeit mit den Selektoren für DKIM war ja offensichtlich. Also verpaßte ich meinem SPF-Record ein Präfix: _spf ließ sich zwar nicht setzen (RegEx-Vorgabe seitens 1&1: (_)foo._bar) – dafür aber z.B. _spf._domainkey… Natürlich endete der nächste Test erst mal wieder mit neutral… Da ich es aber scheinbar kompliziert und doppelt gemoppelt :-) mag, habe ich jetzt 2 Einträge nach dem Muster Name | Typ | Wert:
1)
_spf._domainkey.faett-boys.de
TXT
“v=spf1 include:_spf.1und1.de -all”
   und
2)
 faett-boys.de
TXT
“v=spf1 a mx include:_spf._domainkey.faett-boys.de -all”

Das ist zwar eigentlich Blödsinn – zeigt mir aber, daß ich zumindest halbwegs geschnallt habe, wie das läuft. Denn sämtliche Tools finden “meinen” SPF-Record – auch wenn a und mx bei der Anzeige unterschlägt:

;; ANSWER SECTION:
_spf._domainkey.faett-boys.de. 1050 IN    TXT    ”v=spf1 include:_spf.1und1.de -all”

;; ANSWER SECTION:
faett-boys.de.        799    IN    TXT    ”v=spf1 include:_spf._domainkey.faett-boys.de”

Diese Ergebnisse liefert nslookup:

C:\Users\root>nslookup
Standardserver:  fritz.fonwlan.box
Address:  192.168.178.10
> set q=TXT
>
> faett-boys.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
Nicht-autorisierende Antwort:
faett-boys.de   text =
"v=spf1 a mx include:_spf._domainkey.faett-boys.de"
>
> _spf._domainkey.faett-boys.de
Server:  fritz.fonwlan.box
Address:  192.168.178.10
Nicht-autorisierende Antwort:
_spf._domainkey.faett-boys.de   text =
"v=spf1 include:_spf.1und1.de -all"
>

Da ja nun fast alle Mail-Server der Welt ;-) ;-) ;-) erlaubt sind, liefert der finale Test über die Mail-Adresse von Port25.com natürlich auch ein nettes und freundliches pass:

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mailfrom=info@faett-boys.de
DNS record(s):
faett-boys.de. SPF (no records)
faett-boys.de. 972 IN TXT "v=spf1 a mx include:_spf._domainkey.faett-boys.de -all"
faett-boys.de. 972 IN A 212.227.146.25
faett-boys.de. 3600 IN MX 10 mx00.kundenserver.de.
faett-boys.de. 3600 IN MX 11 mx01.kundenserver.de.
mx00.kundenserver.de. 6963 IN A 212.227.15.41
mx01.kundenserver.de. 1822 IN A 217.72.192.67
_spf._domainkey.faett-boys.de. SPF (no records)
_spf._domainkey.faett-boys.de. 969 IN TXT "v=spf1 include:_spf.1und1.de -all"
_spf.1und1.de. SPF (no records)
_spf.1und1.de. 300 IN TXT "v=spf1 a:moi.1and1.com a:moint.1and1.com a:mxint01.1and1.com a:mxint02.1and1.com a:mbulk.1and1.com a:mout.kundenserver.de a:mout.perfora.net -all"
moi.1and1.com. 83091 IN A 212.227.126.208
moi.1and1.com. 83091 IN A 212.227.126.209
moi.1and1.com. 83091 IN A 212.227.17.1
moi.1and1.com. 83091 IN A 212.227.17.2
moint.1and1.com. 72245 IN A 212.227.17.27
moint.1and1.com. 72245 IN A 212.227.17.7
moint.1and1.com. 72245 IN A 212.227.15.7
moint.1and1.com. 72245 IN A 212.227.15.8
mxint01.1and1.com. 600 IN A 212.227.126.206
mxint01.1and1.com. 600 IN A 212.227.17.16
mxint02.1and1.com. 600 IN A 212.227.17.17
mxint02.1and1.com. 600 IN A 212.227.126.207
mbulk.1and1.com. 76885 IN A 212.227.126.223
mbulk.1and1.com. 76885 IN A 212.227.126.222
mbulk.1and1.com. 76885 IN A 212.227.126.221
mbulk.1and1.com. 76885 IN A 212.227.126.220
mout.kundenserver.de. 85194 IN A 212.227.17.10
mout.kundenserver.de. 85194 IN A 212.227.17.24
mout.kundenserver.de. 85194 IN A 212.227.126.133
mout.kundenserver.de. 85194 IN A 212.227.126.134
mout.kundenserver.de. 85194 IN A 217.72.192.74
mout.kundenserver.de. 85194 IN A 212.227.17.13
mout.kundenserver.de. 85194 IN A 212.227.126.130
mout.kundenserver.de. 85194 IN A 212.227.126.135
mout.kundenserver.de. 85194 IN A 217.72.192.75
mout.kundenserver.de. 85194 IN A 212.227.126.187
mout.kundenserver.de. 85194 IN A 217.72.192.73
mout.kundenserver.de. 85194 IN A 212.227.126.131

Irgendwie ist mir das zwar gefühlsmäßig viel zu viel, was ich da erlaube – ich werde doch noch mal 1&1 rausschmeißen, vielleicht nur mout.kundenserver erlauben und etwas mit PTR rumspielen – mal sehen… Erst mal bin ich halbwegs zufrieden.

Tja, da haben die kleinen Mäuschen dieser Welt ja noch mal richtig Schwein gehabt… ;-)