Posts by ThomasPr

    Und deine DNS-Einstellungen stimmen auch mit den Angaben im CCP überein? Also MX Record für domain.tld zeigt auf mail.domain.tld und mail.domain.tld auf die IP 46.38.249.34? Wenn dem so ist, dann wende dich an den Support. Meiner Meinung sollte das dann eigentlich so passen.

    Für welche Domains möchtest du denn E-Mails empfangen? Nur für user@domain.tld oder auch für user@webmail.domain.tld. Einen MX-Eintrag benötigst du nur für die Domains, die auch zum E-Mail-Empfang genutzt werden sollen.
    Du hast für domain.tld zwei MX-Eintrage, die beide auf unterschiedliche IPs verweisen. Sind denn die Mailserver auf beiden IPs so konfiguriert, dass sie E-Mails für domain.tld annehmen?
    Kannst auch mal auf mxtoolbox.com schauen, die haben ein paar nette Helferlein, die bei der Fehlersuche behilflich sein könnten.

    Hallo Oli,


    auch mit der von dir vorgeschlagenen Konfiguration tritt das Problem auf, aber in deutlich abgemilderter Form. Auch hier ist die Zusatz-IP erst erreichbar, wenn es Traffic über die Haupt-IP gab. Ich denke, dass einer der Services, die während des Bootvorgangs gestartet werden recht bald Daten verschicken. Tun sie dies über die Haupt-IP fällt es kaum auf, dass die Zusatz-IP nicht gleich von Beginn an erreichbar ist.


    Ich habe mal einige Screenshots zur Illustration angehängt. Alle Screenshots wurden mit der Konfiguration von Oli erstellt, iptables-Regeln gab es nicht.
    Screenshot 1 zeigt die Console des Servers, sowie ein ping zur Haupt-IP (links) und zur Zusatz-IP (rechts). Beide IPs antworten, sobald am Server "Configuring Network Interfaces" abgeschlossen ist.


    Screenshot 2 zeigt den Startvorgang erneut, diesmal ohne Ping auf die Haupt-IP. Selbst nach "Configuring Network Interfaces" gibt es noch keine Antwort von der Zusatz-IP. Erst 30 Sekunden später (Screenshot 3) ist auch Zusatz-IP erreichbar.


    Viele Grüße
    Thomas

    Hallo,


    ich habe ein sehr eigenartiges Problem auf meinem Server. Meine Zusatz-IP [46.38.230.26] ist nach einem Neustart des Servers von außerhalb des netcup-Netzes zunächst nicht zu erreichen. Erst wenn Traffic (ein ping genügt) auf der Haupt-IP [46.38.235.158] ankommt, ist auch die Zusatz-IP erreichbar. Das Problem tritt nur mit der IPv4-Zusatz-Adresse auf, mit IPv6 gibt es keine Probleme. Was ich hier aber besonders eigenartig finde, die besagte Zusatz-IP ist von einem anderen netcup-server sofort nach dem Reboot zu erreichen ist, jedoch nicht von meinem Heim-Anschluss oder einem anderen Provider. Die Konfiguration ist vielleicht etwas ungewöhnlich, da ich jeglichen ausgehen Traffic über die Zusatz-IP schicken möchte. Bin für jegliche Tipps zu Fehlersuche dankbar!


    Viele Grüße
    Thomas



    Ich verwende Debian Wheezy, meine /etc/network/interfaces im Folgenden:


    Auch ich kann dieses Verhalten auf einem meiner Server beobachten. Als einziger hat dieser ein zweites IPv6-Subnetz, vielleicht hängt es damit zusammen. Was genau diese Meldung bedeutet oder was der Grund dafür ist, habe ich bisher aber auch noch nicht herausgefunden. Google spuckt ja einiges aus, jedoch nur wenig mit konkreten Erklärungen. Wird echt Zeit, dass mich mich mal genauer in IPv6 einarbeite.

    Oli : Ist der Link zum SmartScreen wirklich der, den du von Microsoft bekommen hast? Ich kann nicht nachvollziehen, was dieser SmartScreen mit deinen E-Mails zu tun haben soll. Das scheint eher was für den Internet Explorer zu sein.
    Was mich aber besonders schockiert: Du hast es tatsächlich geschafft mit jemandem von Microsoft in Kontakt zu treten und selbst dieser jemand kann dir nicht sagen, warum E-Mails einfach so verschwinden? *kopfschüttel*


    Mainboarder : Welche Onlinedienste meinst du denn konkret? Ich kenne nur http://mail-tester.com und http://dane.sys4.de, sowie irgendwelche Tools, die massenhaft Blacklists abfragen, z.B. http://mxtoolbox.com/blacklists.aspx


    Noch ein paar Vorschläge, die vielleicht helfen könnten:
    - Feedback-Loop von Microsoft
    - Empfangen von DMARC-Records
    - DKIM eingerichtet? Gleicher DKIM-Key für alle Server?
    - Eintragen in Whitelists, wie http://dnswl.org oder mit genug Kleingeld bei returnpath.com


    Viele Grüße
    Thomas

    Dann will ich mich an diesem Wunschkonzert auch mal beteiligen: Ich wünsche mir, dass Hardlinks auch als solche berechnet werden und nicht die volle Dateigröße auf die ein Hardlink zeigt.

    Das iPhone kann aber mit dem Autoconfiguration von Thunderbird nichts anfangen. Hier orientiert sich Apple an dem von Microsoft erdachten Autodiscover. Laut den Anleitungen im Wiki muss Outlook, und damit auch das iPhone, manuell konfiguriert werden.

    Wo hast du das denn gelesen?
    Port 587 ist der sog. Submission-Port und dient dazu um E-Mails der eigenen Kunden anzunehmen. Ein user@aol.com kann damit seine E-Mails nur noch über Port 587 an Aol einliefern, aber nicht mehr über Port 25. Für die server2server-Kommunikation und alle anderen Provider ändert das aber nichts.

    Ich glaube, du verwechselt hier die Begrifflichkeiten etwas. Ein Reject lehnt eine eingehende E-Mail mit einem 5xx ab und ist meist das bevorzugte Mittel um unliebsamen E-Mails zu begegnen. Bei einem Bounce hingegen wird eine neue E-Mail von deinem Server generiert, die den Absender darüber informiert, dass die E-Mail nicht angekommen ist. Letzteres will man meist vermeiden (Backscatter).

    Welcher Nameserver beantwortet denn jeweils diese Anfragen? Wenn du mal das +short weglässt, steht dabei, von welchem Nameserver die Antwort liefert.

    Code
    1. ;; SERVER: 46.38.252.230#53(46.38.252.230)


    Was mich aber sehr stutzig macht ist folgende Zeile in zwei deiner drei Listings:

    Code
    1. ;; Truncated, retrying in TCP mode.


    Dies deutet darauf hin, dass irgendetwas große UDP-Pakete blockiert und als fallback deshalb TCP genutzt wird. Ich konnte das aber auf keinem vserver bei netcup reproduzieren. Interessanterweise tritt das Problem auf dem problematischen Server genau nicht auf. Dieser Server hat dafür eine sehr geringe reply size. Laut der Website ist das aber nicht eindeutig, nur bei einer size von weniger als 1400 is das ein Indikator für Blockade.

    AOL antwortete insufficient mailer history, was auch bei der übersetzung von insufficient in ungenügend sich auf die history bezieht


    Ich würde das so deuten, als dass AOL sich über zu schlechte E-Mails (Spam) in der Vergangenheit beklagt und nicht über zu wenig E-Mails. Möglich wäre auch, dass einige User von AOL Nachrichten von deinem Mailserver manuell als Spam markiert haben. Verschickst du denn irgendeine Art von Newsletter?


    Hast du auch schon deine Nachbar-IPs bei so einem DNSBL-Test eingegeben? Vielleicht treibt einer deiner Nachbarn Schindluder und AOL blockiert dann das ganze Netz.


    Ich habe nicht vor den Aufwand von DKIM zu betreiben, nur um unsinnige Regeln von AOL und Hotmail zu befriedigen. Mails haben auch ohne diese anzukommen. DKIM ist kein Spamschutz, sondern stellt nur sicher, dass der Absender berechtigt ist diese Domain zu nutzen. Ich habe gültige DNS MX und PTR Einträge, alles weitere sollte sich damit erübrigen.


    Auf welche unsinnige Regel beziehst du dich denn hier? Gibts einen Link dazu?


    DKIM sehe ich als unerlässlich an. Wie du selbst sagst, dient DKIM zur Absenderauthentifizierung. Aber genau dies ist ein großer Gewinn um gegen Spam-Mails mit gefälschten Absendern vorzugehen. Ob dies jedoch dazu führt, dass AOL und Hotmails deine Nachrichten annehmen, kann ich dir nicht sagen.


    https://www.senderscore.org/lookup.php Insufficient Email Seen - We have not seen a sufficient volume of email from 12.34.56.78 to calculate scores or delivery rates. - Da steht es schwarz auf weiß, zu wenig Emails, was nachvollziehbar ist


    Nix schwarz auf weiß. Die haben einfach wenig bis gar keine Information über deine IP und sagen deshalb, dass sie keinen Senderscore berechnen können. Ich nehme aber an, dass dies auf sehr viele Mailserver zutrifft.


    Helfen würden fähige Admins bei AOL und Hotmail, die nicht unsinnige Spamregeln einführen


    Mit so einer Aussage wäre ich sehr vorsichtig. Solange du nicht weißt, wo genau das Problem liegt, ist eine derartige Anschuldigung ziemlich aus der Luft gegriffen. Und auch hier noch einmal: Auf welche unsinnige Regel beziehst du dich? Gibts einen Link dazu?


    Solero wrote:

    Das Hotmail Deliverability Support Team teilte mir letztendlich mit, den Antispam Programmen (Junk Mail Reporting Program (JMRP), Smart Network Data Services program (SNDS)) zu joinen, da mein SmartScreen ranking zu niedrig ist.


    Warum machst du das nicht einfach? Oftmals gibt es hier sehr viel genauere Infos, warum deine Nachrichten blockiert werden.

    Es scheint, als würde die E-Mail nicht versendet, wenn der Server vor der Installation ausgeschaltet war. Hier wird dann sogar im VCP kein root-Passwort angezeigt und im neu installierten Server der Hostname nicht korrekt gesetzt. Ich kann dies mit zwei Servern reproduzieren, Image ist Debian Wheezy minimal.

    Für mich klingt das so, als hätte AOL deine E-Mails abgelehnt, weil in der Vergangenheit Spam von deiner IP kam. "Unsufficient" würde ich nicht mit "zu wenig", sondern mit "ungenügend" übersetzen. Wie lange hast du diese IP denn schon? Hast du schon mal einen Online DNSBL Test mit deiner IP gemacht? Hotmail scheint für mich ganz ähnlich gelagert zu sein. SPF ist oftmals sogar schädlicher als es nützt, DKIM kann ich dagegen dringend empfehlen. Siehe hierzu einen Vortrag von Peer Heinlein.

    Hm, irgendwas ist da faul. Folgender Befehl bringt mir ein Timeout:

    Code
    1. dig @2a03:4000:6:401b::1 MX serverkostenlos.eu +dnssec


    Lasse ich aber die Option +dnssec weg oder nutze deinen anderen DNS-Server (2001:41d0:52:d00::cc3) funktioniert es.


    Auf dem Responses-Tab von dnsviz sieht man, dass manche Antworten von diesem Server deutlich kleiner sind als von den drei anderen Servern. Dies deckt sich aber nicht mit dem PMTU_EXCEEDED von MX und DNSKEY.