Das längste Thema

    Ich versuche hier gerade anhand einiger Log-Zeilen herauszufinden, was hier mailtechnisch genau passiert ist.

    Angefangen hat alles mit einem DMARC-Report von Google betreffend eine meiner Domains, die nicht bei netcup registriert ist, aber mein Mailserver bei netcup ist der (einzige) MX der Domain. Google hat mir im Report mitgeteilt, dass von der IP 188.68.63.162 eine Mail mit Absender von meiner Domain versendet wurde mit DKIM:fail und SPF:fail. Vermutlich an eine Google-Adresse, sonst wäre der Report sicher nicht von Google gekommen, ich habe da keine Konten und auch nichts an eine Mail bei Google geschickt, schon gar nicht von dieser Domain.


    Die IP ist die vom Mailgateway von netcup (relay.yourmailgateway.de), insofern ist klar, dass SPF und DKIM beide nicht ok sind, versenden dürfen im Namen dieser Domain nur mein Mailserver und die SMTP-Server vom grünen Postfach aus Berlin. Aber wie kommt der netcup Server dazu, eine Mail mit Absender von dieser Domain zu verschicken? Habe erst mal alles mögliche durchgedacht, dass vielleicht auf einem meiner Webhostings eine Website die Adresse als Administrator-Adresse benutzt und die Mail verschickt hat, nicht über den SMTP-Server sondern vielleicht sendmail oder wie auch immer. Aber ich hatte keinen Plan, wie dabei Google ins Spiel kommen soll.


    Also nochmal das Journal meines Mailservers durchsucht und folgende Einträge gefunden... Aber was will mir das sagen? Ich verstehe es mittlerweile so, dass eventuell ein Spammer versucht hat, mit einer Absenderadresse aus meine-domain.de über das Gateway von netcup eine Mail an eine Google-Adresse zu versenden. Vielleicht weil der MX bei netcup liegt oder warum auch immer. Google hat SPF und DKIM gecheckt, die Mail abgelehnt und mir den DMARC-Report geschickt. Die Journaleinträge sehen mir aber eher as, als ob das netcup Mailgateway die Mail "zurück"-geschickt hätte, bloss wie kommt dann Google ins Spiel? :/?( Der einzige Journaleintrag mit google ist die problemlos empfangene Mail mit dem Report. Wer hat da jetzt mit wem Ping Pong gespielt?

    Code
    Jul 06 10:49:06 army.tabserver.de policyd-spf[898478]: : prepend Received-SPF: Pass (sender SPF authorized) identity=helo; client-ip=188.68.63.102; helo=relay.yourmailgateway.de; envelope-from=<>; receiver=meine-domain.de
Jul 06 10:49:07 army.tabserver.de postfix/cleanup[898479]: 0CFD95F220: discard: header Subject: Undelivered Mail Returned to Sender from relay.yourmailgateway.de[188.68.63.102]; from=<> to=<webmaster@meine-domain.de> proto=ESMTP helo=<relay.yourmailgateway.de>: Looks like a bounce (Undelivered Mail), sender probably forged
Jul 06 10:49:07 army.tabserver.de policyd-spf[898478]: : 550 5.7.23 Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=webmaster@meine-domain.de;ip=188.68.63.162;r=meine-domain.de
Jul 06 10:49:07 army.tabserver.de postfix/smtpd[898472]: NOQUEUE: reject: RCPT from relay.yourmailgateway.de[188.68.63.162]: 550 5.7.23 <webmaster@meine-domain.de>: Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=webmaster@meine-domain.de;ip=188.68.63.162;r=meine-domain.de; from=<webmaster@meine-domain.de> to=<webmaster@meine-domain.de> proto=ESMTP helo=<relay.yourmailgateway.de>
Jul 06 10:49:07 army.tabserver.de postfix/smtpd[898472]: using backwards-compatible default setting smtpd_relay_before_recipient_restrictions=no to reject recipient "webmaster@meine-domain.de" from client "relay.yourmailgateway.de[188.68.63.162]"
Jul 06 10:49:07 army.tabserver.de policyd-spf[898478]: : prepend Received-SPF: Pass (sender SPF authorized) identity=helo; client-ip=188.68.63.162; helo=relay.yourmailgateway.de; envelope-from=<>; receiver=meine-domain.de
Jul 06 10:49:07 army.tabserver.de postfix/cleanup[898479]: A76635F220: discard: header Subject: Undelivered Mail Returned to Sender from relay.yourmailgateway.de[188.68.63.162]; from=<> to=<webmaster@meine-domain.de> proto=ESMTP helo=<relay.yourmailgateway.de>: Looks like a bounce (Undelivered Mail), sender probably forged

    Bei all der Kritik muss ich mal sagen: gerade meine Hauptmaschine auf Deb. 12 hochgezogen (mein Kalender sagt Debian-Security ist ende des Monats EOL für 11). Und die Kiste läuft halt seit 290 Tagen durch mit autoupdates etc. Das ermöglicht mir trotz Vollzeitjob mit Reisen meine Projekte weiter laufen zu lassen. Danke Netcup.


    Ich nutze fairerweise aber auch keine vLANs, DNS-Sec, kritische Mail auf der Kiste o.ä. und halte die ewig. Dafür läuft da schon zu viel drüber.


    Bin hier nur noch sehr selten am schreiben, da ich den Login für den Kundenaccount nicht so einfach zugänglich habe unterwegs (aka mal eben am Handy ist nicht). Und da der Forenaccount an den Kundenaccount gebunden ist. Etwas unglücklich.

    Im gleichen Atemzug muss ich mal meinen Frust loswerden über die Netcup Website auf Mobilgeräten.


    Wieso um alles in der Welt gibt es diesen lästigen Banner für WhatsApp quer über die ganze Website, der sich beim Versuch die Produktdatenblätter zu lesen einfach ständig wieder ein und ausblendet (im versuch Intelligent aufs Scrolling zu reagieren). Und dabei keinen einzigen "schleich dich und komm nie wieder" button besitzt. Nicht mal den modernen "später vielleicht" Quatsch :cursing:

    pasted-from-clipboard.png

    Debian 12 Upgrade hat mir erst mal 2 Dienste zerschossen. Offenbar musste /usr/bin noch zusätzlich in ExecPaths und bisher lief das so.. Fragt mich nicht ob sich da was geändert hat, oder systemd in dem 12er Debian jetzt endlich ein paar mehr Lockdowns unterstützt, welche vorher nicht liefen. ProtectDevices ist anscheinend immer noch unbekannt. Aber 2 Stück ist quasi nichts, erst recht, wenn ich die selber angelegt habe.


    Debian bleibt mal wieder ein absolutes Zugpferd. Das schwierigste war eigentlich nur postgres. MySQL ist da einfach komplett automatisch im Upgrade*

    * Ja ich weiß, den Upgrader sollte man auch mal laufen lassen..

    Für diejenigen, die meinen Google API Beitrag gelesen haben, und etwas zum schmunzeln haben wollen, eine kurze Zusammenfassung:


    Der API Schlüssel und die Kalenderdaten kamen von zwei unterschiedlichen Accounts, weshalb der Zugriff nicht funktioniert hat. Aufgefallen ist das ewig nicht, weil die geteilten Kalender vom API-Account schon seit Jahren vollständig verwaltet werden, und deswegen in meinem Kopf nicht als „fremd“ hinterlegt waren…

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Haha 1 Happy Duck 2
    Quote from aRaphael

    Kann man bei den G11 RS/VPS eigentlich weiterhin problemlos vom 1 Monat Laufzeit auf 12 Monate Laufzeit sidegraden, wie das bei den alten der Fall war?

    Ja, geht noch. Zumindest letzte Woche noch, da habe ich genau das gemacht :)

    WH 8000 SE BF22, Mikro G11s, VPS 500G11s BW24, VPS1000 G11 JA24, RS1000 G11

    Thanks 2

    Ich möchte für meinen Beruf gerne eine Website mit Altfragen zum Examen aufsetzen. Es gibt weder welche zu kaufen, noch welche von den Schulen. Alle Altfragen sind aus Gedächtnisprotokollen ehemaliger Prüflinge.


    Kann mir jemand eine entsprechende Software / CMS empfehlen?


    Die Fragen müssten mit mehreren Tags versehen werden können, Kategorien wären ebenfalls hilfreich. Bzw. eine gute Filterfunktion, da man nach folgenden Kriterien filtern muss:

    - Tag: 1, 2, 3

    - Fach

    - Prüfungsjahr

    - Regierungsbezirk


    Ich möchte mir die Option vorbehalten das ganze noch aufs mündliche Examen auszubreiten.


    Theoretisch wäre eine gute FAQ-Software gut…?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Hab mal eine Frage zu den kleinen Servern Piko/Nano/Mikro:


    Hier steht ja max. 5 / Kunde.


    Wie ist das zu verstehen?

    Max. je Produkt 5 Stück gleichzeitig pro Kundenaccount betreiben oder ein Kunde kann max. 5 Stück bestellen und dann nie wieder?


    Hintergrund:

    Ich habe mehrere kleine Server und werde wohl in den nächsten Monaten mache Dienste auf einem größeren VPS zusammenführen.


    Die kleinen Server werde ich dann entweder kündigen oder ans schwarze Brett hängen. Dennoch möchte ich wissen ob ich mir später mal wieder kleine VPS kaufen kann. Die gefallen mir ziemlich gut, weil da halt alles schön getrennt ist.

    Das ist teils auch alternativlos, mangels Virtualisierungsflag (sonst würde ich wohl auf einem RS selbst kleine VMs betreiben).

    Mal eine Frage an die IPv6 Experten. Ich bin dabei meine Kubernetes Cluster auf Dual-Stack umzustellen. Jetzt stehe ich allerdings vor der Frage welche Cluster / Service CIDR ich hier definieren soll.


    Spontan hätte ich gesagt, dass ich hier Präfixe aus fd:: (Unique Local) wählen sollte (z.B. fd:cafe:42::/56 für die Cluster Cidr). Jetzt lese ich aber überall, dass die empfohlenen Netze diese hier sind

    Code
     cluster-cidr: "10.42.0.0/16,2001:cafe:42::/56"
 service-cidr: "10.43.0.0/16,2001:cafe:43::/112"

    Aber warum 2001 und nicht fd? Für mich macht das gerade wenig Sinn. Übersehe ich hier etwas? Vielleicht hat ja von euch jemand eine Idee oder den passenden Hinweis für mich oder hat das vielleicht sogar selbst schon mal gemacht.

    Quote from Paul

    Aber warum 2001 und nicht fd? Für mich macht das gerade wenig Sinn. Übersehe ich hier etwas? Vielleicht hat ja von euch jemand eine Idee oder den passenden Hinweis für mich oder hat das vielleicht sogar selbst schon mal gemacht.

    Es gibt auch "fd-Gegenbeispiele" (beispielsweise hier); ich wüßte nicht, welchen Sinn es machen sollte, öffentliche und private IPv4-/IPv6-Adresspaare zu kombinieren.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Thanks 1 Happy Duck 1

    Danke! Das bestätigt mich in der Annahme, dass die 2001er Empfehlungen eher ungünstig sind. Wundert mich etwas, dass sie trotzdem überall genannt werden. Vermutlich einfach C&P. Ich dachte erst, dass wäre ein weiteres nicht geroutetes Präfix. Aber ich habe diesbezüglich gar nichts finden können und war dann entsprechend skeptisch.