Jump to content

michelo82

Members
  • Gesamte Inhalte

    320
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von michelo82

  1. Ich lese schon fleißig. Ein nslookup auf meine IP gibt mir doch den Hostnamen zurück. Ein nslookup auf den Hostnamen wieder die IP. Wäre das nicht der rDNS? Es sieht aber gut aus. Eine gesendete Firmenmail an GMX: Return-Path: <h.mustermann@meineneuesubdomain.de> Delivered-To: GMX delivery to test249@gmx.de Received: (qmail invoked by alias); 10 May 2012 09:05:34 -0000 Received: from p5545b37e.dip0.t-ipconnect.de (EHLO exchangesrv.firmendomain.de) [80.xx.xx.xx] by mx0.gmx.net (mx060) with SMTP; 10 May 2012 11:05:34 +0200 Received: from exchangesrv.firmendomain.de ([2002:5674:a019::3453:a019]) by exchangesrv.firmendomain.de ([2002:5674:a019::3453:a019]) with mapi id 14.01.0355.002; Thu, 10 May 2012 11:05:34 +0200 From: hans mustermann <h.mustermann@meineneuesubdomain.de> To: "test249@gmx.de" <test249@gmx.de> Subject: TEST Thread-Topic: TEST Thread-Index: Ac0ujA5iWGb/ZdTFQJ6sInKsc1kKTg== Date: Thu, 10 May 2012 09:05:33 +0000 Message-ID: <4F4F40312816884E993541A320546377C4C05F@exchangesrv.firmendomain.de> Accept-Language: de-DE, en-US Content-Language: de-DE x-originating-ip: [2002:8493:a034::8493:a034] Content-Type: multipart/alternative; boundary="_000_4F4F40312816884E993541A320546377C4C05Ffalckexch01comput_" MIME-Version: 1.0 X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p6fGpNEL/qekBFE85I6dEnGzbQL/2H2Ln6ysR+WM5iFAdGgHxO6Ju8BNYdqL prd+umOQN0SFC32zJkWfRUmblHUglDkI/9P6dOjJTcvGYFxgBnaa5b3uIFfa+k/WSuK8W4LhaBBz jJYrwvSRwfL/r6Vf/u2XJImZlmqh73gnnm9NGpXUu8A4p1wfPj9kbaGZIQh2ZbOYl7i2wlnlp175 Y23qVYOKNJQx3k=V1; X-GMX-UID: ODczNM5gCmNlIedBAG9vAZ1yddxVilah X-Flags: 1411 --_000_4F4F40312816884E993541A320546377C4C05Ffalckexch01comput_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TEST --_000_4F4F40312816884E993541A320546377C4C05Ffalckexch01comput_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:= 0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">TEST<br> </div> </body> </html> --_000_4F4F40312816884E993541A320546377C4C05Ffalckexch01comput_--
  2. Das kann aber nur mein Internetprovider? Richtig? Damit meine ich, falls die Telekom-DNS geblockt wären - könnte ich einen anderen DNS nehmen.
  3. So...der Provider hat sich nochmal gemeldet: Er rät nicht dazu, dass ich die Mails über meinen "DNS sende", mit der begründung, dass die IP-Adresse oder der IP-Adressblock des Providers auf einer Blacklist landen könnte. Dies passiert bei größeren Providern (z.B. Telekom) häufiger. Dann soll der Reverse-DNS-Eintrag für die IP-Adresse gesetzt werden. Ich habe gelesen, dass ist notwendig weil: Meint er meinen DNS? Ich kann ja aber auch einen anderen DNS nehmen.
  4. Oh das ist mir jetzt aber neu...ich muss also nicht mehr über den Provider senden? Ich kann direkt mit Exchange senden? :wink2: Bitte ignorieren! Ich habs gelesen, dass ich einfach über die DNS-Einträge der Netzwerkkarte des Hub-Transport Servers senden kann. Oder eben Explizit einen DNS angebe...
  5. Ok...ich glaube ich dreh langsam durch...erneute Kontakaufnahme zum Provider. Es soll kein 2. MX eingerichet werden etc, etc, etc... Nun meint er: Mails müssten vom externen Mailserver abgefragt werden, weil Fehlermails auf diesem ankommen, wenn dieser zum Versenden verwendet wird. Es sei Notwendig, die POP Konten weiterzuführen. Also entweder versteht er es auch nicht richtig, oder wir reden aneinander vorbei :) Ich sende über den Provider meine Mails via Smarthost - also gehen die Mails an mail.meinedomain.de. Authentifiziert wird sich mit einem Benutzerkonto, welches auch als POP3 Postfach verfügbar ist. Nun sollen die Mails ja aber wieder über den A-Record mail.meinedomain.de mit MX auf meinen internen Exchange zugestellt werden. Warum sollen da keine Fehlermails ankommen?
  6. So wirds gemacht! Vielen Dank euch allen...besonders NorbertFe für seine Geduld :wink2:
  7. Nein, sonst würde ich nicht fragen. 1 MX hat den Nachteil, dass alle Absender einen NDR erhalten, falls ich längere Zeit nicht erreichbar bin. Warum auch immer kann es ja sein, das der Exchange ausfällt, Internet nicht verfügbar ist etc...ob nun jemand innerhalb kurzer Zeit einen neuen Exchange aufsetzen kann, oder das Internet kurzzeitig wieder geht steht ja eigentlich gar nicht zur Debatte. Die Mails sollen bei "Abwesenheit" des Exchange zwischengelagert werden und sobald er wieder erreichbar ist, zugestellt werden. Das erreiche ich aber nur mit einem 2. MX. Der wiederum nicht zu empfehlen ist, da ich ihn entweder selbst hosten müsste (um guten Spam- bzw. Antivirenschutz zu garantieren) oder ich überlasse es dem Provider - dem allerdings egal ist was er relayed - dem ich eventuell teuer bezahlen muss, dass er wahrscheinlich sehr Aufwändig die Mails Spam- und Viren prüft. Also sehe ich es nach diesem Thread so: Entweder ich verzichte auf eine Backup MX Lösung, da ich die Mails ohnehin nicht bei einem "Abwesenden" Exchange oder ausgefallener Internetleitung zugestellt bekommen kann. Absender erhalten dann eben eine NDR. Oder der Provider richtet mir einen "temporären MX" beim sehr langen Ausfall meiner Internetleitung ein. Dann eben auf meine 2. Leitung.
  8. Eigentlich mit POP3Connector -> aber das ist ja mist. Also was wäre jetzt die simpelste Lösung?
  9. So langsam komme ich drauf :) Es doch nur so, ich brauche einen Ausfallschutz für den seltenen Fall, dass mein Briefkasten zugenagelt ist oder meine Internetleitung gestört ist. Lösung wäre also mir einen 2. Server hinzustellen mit neuen A-Record auf die 2. Internetleitung. Jetzt habe ich es verstanden! ;) Aber genau aus diesem Grund, bietet mir der Provider ja an die Mails dann an die POP3 Konten zuzustellen. Diese sind Spam- und Virengeprüft.
  10. Gut, der 2. MX wäre ja dann beim Provider selbst. Der hat normalerweise Maßnahmen zur Absicherung (Spam- u. Antivirenfilterung). Dann sollte das ja eingentlich gut gehen die Geschichte mit den 2. MX...
  11. Also ist das auch alles Käse...und ich belasse es einfach bei 1nen MX. Aber noch zum Verständnis, warum würden Spammer den 2. MX benutzen?
  12. Das passiert nur zu Silvester :) , aber ich verstehe... Nur noch so am Rande...ich habe noch eine 2. Internetleitung mit statischer IP. Könnte man die wenigstens dafür nutzen, falls nicht mein Exchange ausfällt, sondern die Telekom die Straße mal wieder aufhackt? Das wäre ja aber auch wieder ein 2. MX...der ja nicht zu empfehlen ist... Gibt es da noch etwas nützliches einzurichten?
  13. Also das mit dem 2. MX habe ich schon gelesen. Also einfach solch einen Backup MX weglassen. Falls mein Exchange kurz nicht erreichbar ist, würde der Absender ohnehin nochmal versuchen zuzustellen. Was ist, wenn der Exchange länger nicht erreichbar wäre?
  14. Ich habe nochmal mit meinem Provider Kontakt aufgenommen. Er soll mir ein store&forward konfigurieren. Eben, dass sein Mailserver die Mails annimmt und nach meiner "Abwesenheit" entprechend an mich weiterleitet wenn ich wieder erreichbar bin. Er meint das geht nicht. Die Mailkonten müssen auf seinen Server parallel geführt werden. Was meint ihr dazu?
  15. Wobei noch die Catchall bzw Store'N'Forward Geschichte zu klären wäre. Was passiert mit den Mails, wenn mein Exchange nicht erreichbar ist? Bevor ich eins aufn Deckel bekomm, ich hab schon was gefunden: http://www.msexchangefaq.de/internet/index.htm ;)
  16. Das wird das Problem gewesen sein, dass Anfangs nichts ankam und mittlerweile die Mail "fast" sofort da ist.
  17. Anscheinend scheint das nslookup jetzt zu gehen. Providerseitg wurde nochmal etwas korrigiert.
  18. Dafür gibt es doch aber solche sehr guten foren wie das MCSE...:wink2: Das kann nur der Provider! Es gibt keine Webgui oder sonstiges, dass ich da selber etwas machen kann! Das funktioniert bereits. Das funktioniert bereits. Adressrichtline ändere ich für den Test erst mal nicht. Das kann auch wieder nur der Provider. Kann es sein, dass der mir dazwischen funkt? Das meine Mails, wegen der falschen Priorität erst woanders zugestellt werden sollen - deshalb dauert die Zustellung schlussendlich so lange?
  19. So halbwegs funktioniert es. Ich kann ja mit SMTPDiagPro von jedem Mailkonto aus meine Mails zu testen versenden: Ich hab Mails von GMX gesendet: an meine "produktive" Firmenmail die ich per Pop3 abhole: das dauert ~ 2min an meine "test" Mail die per SMTP direkt zugestellt werden soll: dauert ~ 16min die 2. Testmail: ~ 7min Ich hab Mails von Freenet gesendet: an meine "test" Mail die per SMTP direkt zugestellt werden soll: dauert ~ 2min Ich hab Mails von meinem Provider gesendet: an meine "test" Mail die per SMTP direkt zugestellt werden soll: da kommt gar nichts an! Was kann ich euch noch zur Diagnose posten?
  20. Ahh...ok mail.meineneuesubdomain.de zeigt ja auf meine öffentliche IP und somit ist ja wiederum der Exchange intern gemeint. Deshalb funktioniert die Zustellung, wenn ich intern eine Mail sende. Von außen wird der Name falsch aufgelöst, vermute ich. EDIT: wieder eine neue Erkenntnis: Hi. This is the qmail-send program at mailout-de.gmx.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <h.mustermann@meineneuesubdomain.de>: Connected_to_80.xx.xx.xx_but_sender_was_rejected./Remote_host_said:_530_5.7.1_Client_was_not_authenticated/ --- Below this line is a copy of the message. Return-Path: <meinaccount@gmx.de> Received: (qmail invoked by alias); 08 May 2012 11:59:20 -0000 Received: from p2354e62a.dip0.t-ipconnect.de (EHLO p2354e62a.dip0.t-ipconnect.de) [80.xx.xx.xx] by mail.gmx.net (mp036) with SMTP; 08 May 2012 13:59:20 +0200 X-Authenticated: #57419952 X-Provags-ID: V01U2FsdGVkX1+IAUNcV0WISdAnSqn/Wvyav0NG1SNWSPlFkcWs1y 1fUigTrBqggy07 From: meinaccount@gmx.de Return-Path: meinaccount@gmx.de To: h.mustermann@meineneuesubdomain.de Content-Type: text/plain Subject: SMTPDiagPro testmail 08.05.12 13:59:19 (3 of 3), remote type: , remote host: mail.gmx.net:25 (No encryption), localhost: p2354e62a.dip0.t-ipconnect.de, username: meinaccount@gmx.de, from: meinaccount@gmx.de, to: h.mustermann@meineneuesubdomain.de, attachments: no attachments, no attachments X-Y-GMX-Trusted: 0 X-GMX-Antivirus: 0 (no virus found) SMTPDiagPro testmail 08.05.12 13:59:19 (3 of 3) remote type: remote host: mail.gmx.net:25 (No encryption) localhost: p2354e62a.dip0.t-ipconnect.de username: meinaccount@gmx.de from: meinaccount@gmx.de to: h.mustermann@meineneuesubdomain.de attachments: no attachments Remote_host_said:_530_5.7.1_Client_was_not_authenticated ... reicht es nicht einen Benutzerpostfach im Exchange die SMTP Adresse h.mustermann@meineneuesubdomain.de zuzuordnen?
  21. Ok :) Nun hab ich aber doch noch was...der Mailversand hat zwar wie oben im Screenshot von intern geklappt... Aber von einem Provider aus, sagen wir mal GMX.net geht es natürlich nicht. Was ist noch hilfreich um das Rätsel zu lösen?
  22. Ok. Mailversand läut noch über den Smarthost mail.meinefirmendomain.de Ich hatte vom Provider die neue Subdomain mail.neuedubdomain.de ja nur zum test einrichten lassen... Ist es jetzt sinnvoll auf mail.meinefirmendomain.de umschalten zu lassen? So das senden und "empfangen" über diese eine Domain läuft?
  23. ipconfig /flushdns hat geholfen... Mhh ich hab da wahrscheinlich ein Verständnisproblem. meineneuedomain.de + meine statische IP gehören ja zusammen. Trage ich jetzt an irgendeinen anderen Exchange-Server in der Welt meineneuedomain.de als "Aktzeptierte Domäne" ein, werden die Mails ja trotzdem nur an meinen Exchange mit meiner statischen IP zugestellt. So ists richtig?!
  24. Ja, ich verdreh da immer was ;). Es liegt an der falschen Namensauflösung. Wenn ich einen telnet auf meineneuesubdomain.de 25 mache funktioniert es nicht! Telnet auf meine IP 80.xx.xx.xx 25 funktioniert! Das hatte ich gestern vergessen zu schreiben. Das kommt wahrscheinlich davon, da ich die Adresse vor der Umstellung einmal angepingt hatte. Somit ist die noch im DNS-Cache von uns. ipconfig /flushdns hilft da weiter... Somit kann ich also mittels SMTPDiagPro auch Mails direkt auf den Exchange zustellen lassen :) Hier tut sich aber eine wichtige Frage auf. Ich muss für die Maizustellung ja keine Authentifzierung angeben. Kann jetzt nicht jeder, der meine IP bzw. meineneuesubdomain.de kennt meine Mails abfangen? Sobald jemand meineneusubdomain.de auch in seinen Server als "Akzeptiere Maildomain" einträgt? Also es einfach ein neuer Connector mit dem Häkchen Anonym! Deaktivere ich den Connector bekomme ich bei Mailversand via SMTPDiagPro: Could not set sender 'test@test.com' (530 5.7.1 Client was not authenticated) Also scheint der Connector korrekt eingerichtet zu sein. Anonyme Sender werden nicht akzeptiert! Ich gelobe Besserung...;)
×
×
  • Neu erstellen...