Falk Sauer wrote:
Hi Sandy,
Am Do 12.Juli 2007 20:13:35 schrieb Sandy Drobic:
Ha?!? Wovon redest du eigentlich?
Nochmal zusammengefasst: Wenn man an einer dynamischen Leitung hängt, bekommt man in der Regel nicht den den DynDNS-Namen als Reverse-DNS-Eintrag gesetzt. Als Folge davon wird der Host (wenn er nicht ohnehin wegen der dynamischen IP direkt abgewiesen wird) vom empfangenden Server als "unknown" geführt, bzw. bei vorhandenem PTR als der Reverse DNS-Name.
jepp
Dieser Lookup kann nicht über die Klammern unterdrückt werden. Die Klammern um einen Hostnamen sind nur für die Unterdrückung der MX-Auflösung des Namens beim Versenden von Mails.
ja wenn du aber intern und extern auf die gleiche konfig setzt und darum ging es ja letztendlich muss beides für den Client zum gleichen Ergebnis führen damit es geht. Das mit dem MX bekommt man hin, dh. das der Client vom DNS gesagt bekommt wo sein smtp-Server mit dem Port 25 auf ihn wartet. -->1
Beim Client sieht es erheblich einfacher aus: er braucht keine Rückwärts-Auflösung. Ihm reicht es, wenn der Hostname auf einen IP-Adresse aufgelöst werden kann oder die IP direkt angegeben wird. Dabei muss dies nicht zum selben Ergebnis führen, sondern nur zum gleichen Server zeigen. Der interne Client kann hier die interne IP verwenden, der externe muss natürlich über die externe IP gehen. Die Namensauflösung des smtp-Clients muss also nicht das gleiche Ergebnis bringen. Viele Wege führen nach Rom bzw. zum Relayserver.
Der erste Absatz ist die Sicht des empfangenden Servers, dem eine Mail geschickt wird. Der zweite Absatz hier ist die Sicht des eigenen sendenden Servers.
Nebenbei ist das Setzen des MX bei DynDNS (andere habe ich noch nicht probiert) nicht kostenpflichtig.
Das sehen aber nicht alle so, als ich mich vor 2-3 Jahren nach einem Dyndns umgeschaut habe wollten die meisten für einen MX-Eintrag Geld, und ich würde jetzt fast wetten das dyndns.org da auch dabei war.
Jetzt jedenfalls nicht mehr, vermutlich auch, weil einige Admins statt in Kenntnis der RFCs nach dem Sitz ihrer Hosen administrieren.
Was genau meinst du jetzt mit "nicht zwingend (je nach Konfig) zu einem Abbruch führen muß"?
1) wenn du überprüfst ob der reverse zu dem übermittelten Namen passt, und er passt nicht wird der Sender abgewiesen. Wenn man das nicht macht geht es. So wie du oben schon geschrieben hast. Dieses Problem bekommt man aber nicht in den Griff wenn man auf dem eigenen per dialin angeschlossenen Server auf den reverse Eintrag testet wenn der eigene Client daher kommt. Denn dann stimmt dessen reverse maximal von innen aber nie von außen - wenn sich der client jeweils als der gleiche Rechner identifiziert.
Was passiert, wenn dein Server (der an der dynamischen IP hängt), eine Mail an einen anderen Server verschickt? Diese Schritte laufen ab: - Dein Server verbindet sich mit dem externen Server. Dieser löst die IP deines Rechners auf und überprüft, ob der Reverse-DNS-Eintrag zurück auf die IP zeigt. Bei Ish ist dies der Fall. Dein Server wird geloggt als xxxxx.xxxx.ish.de. - Jetzt kommt das HELO/EHLO-Kommando, das dein Server absetzt. Dieses ist der Hostname bla.self-ip.org oder was auch immer. Jetzt prüft der externe Server, ob dieser den RFCs genügt: FQDN, muss existieren. Alles klar, der Hostname existiert im DNS. KEIN RFC verlangt, dass der sendende Server seinen eigenen Hostnamen für das HELO verwenden muss! Diesem Aberglauben hängen nur die Admins mit den zu knappen Hosen an. - Als nächstes kommt nun Envelope-Sender/-Recipient, auch diese müssen FQDN sein und die Domain muss existieren. Auch müssen dies gültige Adressen sein. Address-verify kommt jedoch in Verruf, da einige Server so stark durch die Adressproben von anderen Servern belastet wurden, dass einige Admins diese Adressproben schon als Teil der Spambelastung sehen und die entsprechenden Server auf die eigene Blacklist setzen. Danach kommt nur noch die eigentliche Mail. Der Server an der dynamischen IP wird also in diesem Fall nicht als "unknown" geloggt, sondern als xxx.ish.de. Das eigentliche Problem ist, dass die IP in einem Bereich liegt, welcher als Dialin ausgewiesen ist und deshalb durch den Gebrauch der entsprechenden Blacklists abgewiesen wird. Anders sieht es aus, wenn für die IP gar kein Reverse DNS eingerichtet ist, der Eintrag ungültig ist, oder dieser Eintrag auf eine andere IP zeigt. Dann wird der Client vom empfangenden Server als "unknown" geführt.
Na ja, jetzt bin ich an einer statischen IP und kann die Einträge setzen. Und da ich nun schon seit Jahren meinen Hostnamen einsetze, ist dieser eben auch auf der statischen Adresse eingetragen.
ich hatte mal einen isdn dialin Provider mit ner statischen Adresse, das war klasse, lang ists her. Sowas könnte ich zwar wieder per vpn haben aber meine Leitung daheim gibt einen sinnvollen Betrieb leider nicht her, wenn ich das mal machen sollte dann nur bei einem Hoster.
Wenn Kosten ein kritischer Punkt sind, dann sollte man einen virtuellen Server mit offizieller IP mieten und diesen als Mailserver verwenden. Der interne Server ist dann der Backend-Server. Wichtig ist dann nur, dass der Relayserver alle gültigen Adressen kennt und ungültige direkt abweisen kann.
völlig richtig - es sei denn man bekommt vor Ort keine bezahlbare statische Adresse, aber ging es dem OP nicht ursprünglich lediglich darum mit dem möglichst gleichen setting bei sich daheim auf den Server zu kommen?
Ja, bis die Diskussion ausgeufert ist zur Mailannahme etc. (^-^) Wie ich oben geschrieben habe, ist es für den Client nur wichtig, dass er den Hostnamen auflösen kann auf die IP-Adresse. Dies muss jedoch nicht die gleiche IP sein wie die externe. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org