Beiträge von Aleph

    thys,


    das "freut" mich, dass ich nicht der einzige mit dem Problem bin.

    Wo hast du ein Feedback-Formular gefunden welches ohne Anmeldung bei yahoo funktioniert ?

    Leider gar nicht, ich habe mir einen Account angelegt.
    Wie ich gerade feststellen durfte, ist meine Mail von vor 4 Tagen nun durchgekommen, auch weitere Testmails konnten zugestellt werden. Allerdings habe ich glaube ich am Dienstag wieder dieses elende Formular ausgefüllt.


    MfG Aleph

    Dachte ich zuerst auch, aber wie es scheint, ist das eine generische Fehlermeldung - zumal bei Yahoo selbst nichts von einer Nutzerinteraktion steht.
    Der Server läuft unter dieser IP-Adresse erst rund 2 Monate. Laut Mail-Log kann ich die Yahoo-Empfänger in dieser Zeit an einer Hand abzählen. Vor allem gingen zwischen dem zweimaligen Auftreten des Problems nur Testmails an meinen eigenen Yahoo-Account raus - das wüsste ich, wenn ich diese Mails als Spam markiert haben sollte ;)


    MfG Aleph

    Guten Morgen,


    ich habe wiederholt das Problem, dass an Yahoo gehende E-Mails nicht ankommen:

    Zitat

    (host mta6.am0.yahoodns.net[66.196.118.36] said: 421 4.7.0 [TSS09] All messages from 185.170.112.133 temporarily deferred due to user complaints - 4.16.56.1; see Error: "421 4.7.0 [XXX] Messages from x.x.x.x temporarily deferred - 4.16.56.1" | Postmaster Help- SLN3326 (in reply to MAIL FROM command))

    Das Problem bestand vor rund einem Monat schon einmal, das lag aber wohl daran, dass ich DKIM noch nicht eingerichtet hatte.
    Laut Error: "421 4.7.0 [XXX] Messages from x.x.x.x temporarily deferred - 4.16.56.1" |Postmaster Help- SLN3326 sollen folgende Voraussetzungen erfüllt sein:

    • URL reputation
    • Sender reputation
    • Domain reputation
    • IP address reputation
    • (DMARC) authentication
    • DomainKeys Identified Mail (DKIM) signatures

    Ich habe dann also DKIM eingerichtet, ein "Complaint Feedback Loop"-Formular bei Yahoo ausgefüllt und nach rund 2 Tagen gingen die Mails endlich raus.
    Seit 4 Tagen hängen nun wieder Mails in der Warteschleife. Ich habe mehrere Checks durchgeführt und kann bislang keinen Fehler entdecken. Laut DKIM Test - DKIM Verify - DKIM Validator (Ergebnisse gibt es unter Perl Nopaste) etwa gibt es bei den Tests zu SPF, DKIM, PTR und RBL keine Probleme. DMARC und DomainKeys sind (noch) nicht eingerichtet, scheinen aber auch keine zwingende Voraussetzung zu sein.


    Der Mailserver (postfix, dovecot, etc.) wird gegenwärtig von 4 Personen genutzt. Ich kontrolliere die Logs mit tenshi gewissenhaft und kann ziemlich sichergehen, dass da kein Schindluder getrieben wird - aber ich scheine ja auch auf keiner RBL gelandet zu sein. Fast schon unnötig zu erwähnen, dass sonst alles läuft - GMX, Web.de, Gmail etc. bereiten keine Probleme.


    An DMARC will ich mich langfristig zwar sowieso setzen, aber das wollte ich eigentlich in aller Ruhe an einem Wochenende erledigen...


    Hat jemand eine Idee, woran das Problem liegen könnte?


    MfG Aleph

    gunnarh und chrko,


    vielen Dank für eure Antworten. chrkos Hinweis hat letztendlich den Ausschlag gegeben. Falls noch jemand vor dem Problem stehen sollte. Einmal den ZSK und einmal den KSK angeben, die entsprechenden Flags und Algorithmen auswählen und beim DNSKEY die 5 Zahlen am Anfang weglassen.


    MfG Aleph

    gunnarh,


    vielen Dank für deine Antwort und den Hinweis mit SHA1 - die Schlüssel werde ich, wenn das grundsätzliche Prozedere klar ist, dann wahrscheinlich nochmal ersetzen.


    Ich habe die Schlüssel aus der Datei "dsset-syncookie.de." entnommen, diese Datei wurde beim Erstellen der Schlüssel angelegt und hat folgenden Inhalt:

    Zitat

    syncookie.de. IN DS 29115 7 1 BB3553956DC52388B7A36DC526DBC2DD5D36A82D
    syncookie.de. IN DS 29115 7 2 9008BC78042FA31CF513DA72670C15E63C29B98A2858683900CDE3C0 6E541D7C

    Auch wenn ich jetzt beide Schlüssel als KSK angebe, werden keine gültigen DS-Records gefunden. Einigermaßen verwirrend ist halt, dass bei ormanns.net andere Angaben notwendig / möglich sind als bei syncookie.de - bei letzterer Domain kann ich nur den öffentlihen Schlüssel, die Flags (0 / ZSK(256) / KSK (257)) und natürlich den Algorithmus angeben.


    MfG Aleph

    Hallo zusammen,


    ich verwalte mit drei Nameservern mehrere Domains, bei zweien davon habe ich nun DNSSEC eingerichtet. Bei einer davon funktioniert alles wie gewünscht, bei der anderen werden zwar die DS-Records im CCP übernommen, allerdings werden nach mehr als 2 Tagen immer noch keine DS-Records gefunden.


    1.
    ormanns.net funktioniert problemlos (siehe ormanns.net | DNSViz oder DNSSEC Analyzer - ormanns.net)
    Im CCP sind die Angaben wie folgt:

    Zitat

    Öffentlicher Schlüssel: 36D135565E4FD83871C5A2829548BC495AD565ED52CEE4EF5C79F5281FD17B6F
    Hashtyp: SHA-256 (2)
    Keytag: 64101
    Algorithmus: RSASHA1-NSEC3-SHA1 (7)

    Zitat

    Öffentlicher Schlüssel: 859E544AC10965403C0C666FCD5D4368A5F0E383
    Hashtyp: SHA-1 (1)
    Keytag: 64101
    Algorithmus: RSASHA1-NSEC3-SHA1 (7)

    Im Zonefile sind Kormanns.net.+007+38219.key und Kormanns.net.+007+64101.key eingebunden.



    2.
    für syncookie.de werden keine DS-Records gefunden (siehe syncookie.de | DNSViz oder DNSSEC Analyzer - syncookie.de)
    Im CCP sind die Angaben wie folgt:

    Zitat

    Öffentlicher Schlüssel: BB3553956DC52388B7A36DC526DBC2DD5D36A82D
    Flags: ZSK (256)
    Algorithmus: RSASHA1-NSEC3-SHA1 (7)

    Zitat

    Öffentlicher Schlüssel: 9008BC78042FA31CF513DA72670C15E63C29B98A2858683900CDE3C06E541D7C
    Flags: KSK (257)
    Algorithmus: RSASHA1-NSEC3-SHA1 (7)

    Im Zonefile sind /var/cache/bind/Ksyncookie.de.+007+29115.key und /var/cache/bind/Ksyncookie.de.+007+63779.key eingebunden.



    Ich habe das Gefühl, irgendwas simples übersehen zu haben...vielleicht findet jemand ja einen - womöglich offensichtlichen - Fehler?


    MfG Aleph

    Der Vollständigkeit halber - mit folgenden Settings in sshd_config laufen die Tunnel mittlerweile absolut stabil:
    ClientAliveInterval 60
    ClientAliveCountMax 5


    MfG Aleph

    Ich habe mich nochmal an das Problem gesetzt und hierzu einen Server (Server1) bei einem weiteren Hoster so eingerichtet, dass diese jeweils einen SSH-Tunnel auf den beiden netcup-Servern öffnet. Diese loggen dann zu Server1.


    1. Mir fiel auf, dass mittlerweile nur noch einer der beiden Tunnel Probleme bereitet. Der andere Tunnel arbeitet einwandfrei.
    2. Die Disconnects geschehen nicht scheinbar willkürlich, sondern in festen zeitlichen Abständen:

    3. Die Kernelconfig, ssh_config und sshd_config sind auf beiden Gentoo-Systemen identisch.


    ssh_config

    Zitat

    Host *
    ServerAliveInterval 60
    ServerAliveCountMax 1000


    SendEnv LANG LC_*

    sshd_config

    4. Es bestehen derzeit keine iptables-Regeln.
    5. Auf Server1, der die Tunnel aufmacht, sind keine Host-spezifischen SSH-Einstellungen gesetzt, die etwa die Verbindung zu einem bestimmten System beeinflussen.
    6. Die Disconnects geschehen nicht aufgrund von Inaktivität. Lasse ich syslog-ng etwas loggen, was dann durch den Tunnel läuft, wird der Tunnel trotzdem "zeitplanmäßig" unterbrochen.


    -> Trotz gleicher Einstellungen verhalten sich die Gentoo-Systeme unterschiedlich.


    So langsam gehen mir die Ideen aus, woran es liegen könnte, wenn es denn ein Softwareproblem sein soll.


    MfG Aleph

    Ich nutze das Setup auch nur privat - wenn hier und da _mal_ die Verbindung abreißt, ist es nicht so dramatisch


    TCPKeepAlive ist aktiviert und ServerAliveInterval habe ich nicht geändert, es sollte also per default deaktiviert sein. NAT nutze ich nur, um die auf einem Nicht-Standard-Port eingehenden SSH-Verbindungsversuche auf 22 weiterzuleiten.
    Witzigerweise sind die SSH-Verbindungen von einem anderen Rechner zu den Gentoo-Systemen seit über 12 Stunden stabil....ich bin ein bisschen ratlos.


    MfG Aleph

    Hallo zusammen,


    ich habe gestern 2 Server in Betrieb genommen, einen RS 1000 G7 SE und einen Root-Server 500. Beide laufen mit Gentoo (4.7.10-hardened) und sind alles andere als ausgelastet.
    Von meinem Monitoringsystem zuhause habe ich nun mit autossh mehrere SSH-Tunnel zu jedem der beiden Server eingerichtet (nach dem Schema autossh -N -M12345 -R 5140:localhost:514 -f user@netcup-server).
    Leider bricht der Tunnel regelmäßig, d.h. mehrfach pro Stunde zusammen. Er wird zwar natürlich jedesmal neu aufgebaut, die Verbindung sollte aber grundsätzlich nicht so instabil sein.


    An meiner Internetverbindung zuhause sollte es nicht liegen, da von hier aus ebenfalls ein Tunnel zu einem dritten Server bei einem anderen Hoster besteht. Dieser Tunnel ist deutlich stabiler - die Verbindung wird im Schnitt alle paar Tage kurz unterbrochen.


    Da ich mein Logging- und Monitoringsystem langfristig auf den Root-Server 500 verlagern wollte, stehe ich aktuell natürlich vor einem Problem: wenn die Tunnel dauerhaft instabil sind, ist an ein gescheites Logging ja nicht zu denken.


    Hat jemand Ideen, was ich checken könnte? Momentan sieht es halt stark danach aus, als würde es an der Verbindung zum Hoster liegen.


    MfG Aleph