Posts by chrko

    und dass hier jemand was einträgt - simple registrierung genügt - was so gar nicht past,

    läßt SPAM dann auch leichter durchflutschen ...

    Du hast dich anscheinend bereits registriert und Eintragungen vorgenommen, sehe ich das richtig?

    Die Eintragungen werden reviewed.


    Und wenn auch nicht, würde ich deine SPAM-Filterung für sehr fragil halten, wenn es nur dieser eine Faktor aus macht ;)


    Und Jimi : Ich kann es nur noch mal betonen: Verwende deinen eigenen lokalen Resolver. Irgendwelche gemeinsam genutzten DNS Resolver, wie netcup, Google oder ähnliche, laufen halt gerne ins Rate Limit.

    Hallo netcup und Kunden,


    gerade spiele ich mal wieder das Spiel mit dem Support, dass darauf bestanden wird, dass die Absenderadresse (also der FREI wählbare From-Header einer Mail) nicht mit dem hinterlegten Account übereinstimmt.

    Wieso wird nicht durch das Antworten an die hinterlegte Adresse verifiziert? Im konkreten Fall setze ich sogar den Reply-To-Header, so dass der Support-Mitarbeiter mit mir sogar über die hinterlegte Adresse kommuniziert.


    Mal ganz wild gesponnen: Setze ich die Mail-Adresse beim Kontaktieren des Support auf irgendeinen Quatsch (wie z.B. die Mail-Adresse von [netcup] Felix ), habe ich dann "erhöhte"/andere Berechtigungen durchs Ticket-System? (Oder böswillig: Ich setze die Mail-Adresse eines anderen Kunden und autorisiere dann Änderungen an dessen Infrastruktur?)


    Um es noch mal zu betonen: Die Absender-Adresse einer Mail kann völlig freigesetzt werden, und das setzen eines Reply-To-Headers wird ohne Beachtung des Ziel auch einfach durchgeführt und akzeptiert.
    Kann daher die Verifikation durch des Empfangen auf der eingetragen Mail-Adresse erfolgen?


    Viele Grüße

    Ich habe ein paar (wirklich) kleine Fehler in den Texten gefunden:


    "Anzahl der Kunden die Sie in dem Reseller Webhosting anlegen können." - Hinter Kunden fehlt ein Komma.

    "Der Speicherplatz für Ihre Kunden in der Cloud für Webseite. E-Mails und Datenbanken." - Hinter Webseite steht anstatt einem Komma ein Punkt.

    "Für jede Domain die Sie über uns beziehen erhalten Sie in einem Expert-Tarif kostenlos ein SSL-Zertifikat von Let's Encrypt. Unser System richtet die SSL-Zertifikate innerhalb weniger Sekunden ein und sorgt für regelmässige Aktualisierungen der SSL-Zertifikate." - Hinter "Domain" und "beziehen" fehlt ein Komma.


    Viele Grüße

    Prometheus <3

    Ich bin nie mit den anderen Tools warm geworden - also die Klassiker Icinga, Zabbix…


    Mein eigentliche Prometheus Konfiguration ist auch ziemlich nackt, denn die eigentlichen Targets kommen via Service Discovery herein.

    da netcup diese möglichkeit herrvorhebt um nach support zu fragen landen dann auch solche "ärsche" wie ich hier und schreien mal darauf los. kontakt zu netcup ist aufgebaut, aber seit ca. 2h keine Rückmeldung. da scheint es hier wohl mehr leute zu geben die hier mehr zeit haben privat als manche kollegen von NC@job

    Warum eskalierst du es dann nicht via Notfall Hotline? :o

    Also in dem Sinne verstehe ich die Aufregung nicht. Wenn es ein Problem gibt, dass im Zuständigkeitsbereich von netcup liegt und außerhalb der regulären Arbeitszeiten auftritt, Mail schreiben und bei Dringlichkeit anrufen.


    Und wenn dein Server so wichtig ist, verstehe ich auch nicht, warum man eine Erinnerung braucht, oder das System nicht redundant ausgelegt ist. :o


    Hübsch und nett wäre die Anzeige der Reboot Zeitfenster im CCP und/oder SCP, aber die zwingende Notwendigkeit erkenne ich da nicht.

    Wieso hast du "post-up ifup […]" gesetzt? Wendern sind die Interfaces eh schon Up…

    Laut https://askubuntu.com/a/795543 müsstest du übrigens auch gar keine zusätzlichen Interfaces oder komische Kommandos wie ich verwenden, sondern kannst stattdessen folgendes machen:


    Ich würde auch noch vermuten, dass die weiteren Gateways allesamt nicht funktionieren werden.

    Es ist der feine Unterschied zwischen blockieren und drauf hören/reagieren:

    Im Netcup v6 Setup werden auch vom Router Router Advertisments gesendet. Da dies aber gerne mal zu Problemen führt, sollte man die default route statisch konfigurieren und das Verarbeiten derer deaktivieren, siehe die Empfehlungen sysctl Einstellungen im netcup Wiki.

    Ich bin persönlich der Meinung, dass ICMP in irgendeiner Art abdrehen nicht sinnvoll und ratsam ist. Es fällt in der Regel einfach unter das Konzept "Security by Obscurity" und naja, die meisten Informationen, die man via ICMP bekommen kann, – wenn nicht alle – gibt es auch über andere Wege und Optionen.

    Bei IPv6 MUSST du gewisse ICMPv6 Typen in der Firewall freischalten, sonst kann IPv6 nicht ordentlich funktionieren.

    Der Effekt ist in meinen Anwendungsszenarien analog zu preferred lifetime auf 0 zu setzen. Wenn nicht explizit eine Absenderadresse gesetzt ist, wird beim Nutzen der entsprechen Route diese Adresse genutzt.

    the source address to prefer when sending to the destinations covered by the route prefix.

    Man muss nur verstehen, dass man dort mit einen anderen Mechanismus arbeitet.


    Und nein - der Server antwortet z.B. auf ICMP(v6) Echo Requests nicht immer mit dieser Adresse; ich muss aber gestehen, dass ich erst noch mal nachlesen müsste, mit welcher Priorität das den Source Address Selection Prozess genau beeinflusst.


    Ehrlich gesagt grübel ich gerade auch, wieso ich eigentlich diesen Weg gewählt habe… (und woher ich den initial habe).

    Code: /etc/sysctl.conf
    1. net.ipv6.conf.all.accept_ra=0
    2. net.ipv6.conf.eth-extern.accept_ra=0
    Code: /etc/udev/rules.d/70-persistent-net.rules
    1. SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="b6:db:d5:c8:3c:b1", NAME="eth-extern"


    resultiert in


    Code: ip -6 route
    1. 2a03:4000:6:x::/64 dev eth-extern proto kernel metric 256 pref medium
    2. fe80::/64 dev eth-extern proto kernel metric 256 pref medium
    3. default via fe80::1 dev eth-extern src 2a03:4000:6:x::1 metric 1024 pref medium

    Ich mach die primäre Absender etwas anders:

    Code
    1. post-up ip -6 route change default via {{ network.gateway }} dev {{ network.iface }} src {{ addr | ipv6('address') }}


    Bzgl. der Frage, wie viele IPs an Interface: Bei IPv6 so viel du willst, es nur irgendwann nicht effizient. Man kann aber auch auf ganze Präfixe lauschen - es ist nur nicht ganz trivial. Zusätzlich zu den erwähnten Dingen im Artikel muss man bei netcup beachten, dass das erste IPv6-Netz "geswitched" und nicht geroutet ist, d.h., dass man dem Router via Neighbor Discovery Protocol mitteilen muss, dass es diese Adresse gibt…

    https://blog.cloudflare.com/how-we-built-spectrum/

    https://blog.widodh.nl/2016/04…et-to-your-linux-machine/

    Das ist doch zumindest eine halbwegs erfreuliche Nachricht!

    Gab es eine Begründung, wieso andere Next Header gesperrt sind/waren?

    Mir erschließt sich nämlich nicht der Unterschied Richtung IPv4; also weshalb dort glücklicherweise alles frei ist.

    Prinzipiell schon, wenn man die im Wiki angesprochenen Besonderheiten beachtet. Das kann ich mit einem kleineren Setup bestätigen, bei dem ich es seit einigen Jahren als (mittlerweile dauerhafte) Notlösung in Kauf nehme. Aber von der Performance her kann ich mir kaum vorstellen, dass Du groß dazu gewinnen wirst.


    Wenn ein richtiger Suchindex bei Dir Overkill ist, wäre das eines jener Paradebeispiele, wo ein SSD-Server auf jeden Fall Sinn macht. Ich muss immer schmunzeln, wenn User meinen, dass es bei Mailservern nichts Kritisches gibt, das schnell reagieren muss. Tja… ^^

    Es gibt übrigens eine (meiner Meinung nach) bessere Alternative, wodurch Postfix nicht selbst in die Mailbox schreiben muss: https://wiki.dovecot.org/LDA/Postfix

    Naja, es ist nicht nur eine alternative, dass Postfix nicht direkt ins Maildir kritzelt. Wenn Postfix ins Maildir schreibt, sind die dovecot-Caches und Indizes hinfällig…

    Also via dovecot-lda oder via LMTP (via Unix-Socket oder Port) an Dovecot übergeben.