rep

Da hast du recht, aber ist in meinem Fall, und ich gehe mal davon aus das es ein heufiger Fall sein kann, genau so. Denn ich habe nur eine Smarthost nötig, und selbst wenn ein 2. Da wäre. dann hätte er höchstwahrscheinlich identische Konfigurationen nötig. Wenn ich aber auf mehreren Ports horchen woll, dann brauch ich 2 VSMTP, und die Ausgehenden Konfigurationen sind dann doch einfach überflüssig, oder nicht? Ich versuche die "Fehler, schleifen" noch mal als Fehlermeldung zu erhalten und melde mich dann ;)

Hey, es hakt an der Stelle, wo ich in 2 VSMTP die Einstellungen für ausgehende Verbindungen einstellen muss, wobei ich doch nur einen SMTP-Connector habe der die Ausgehenden E-Mails behandelt. Warum muss ich diese Einstellungen 2 Mal machen, bzw. welche greifen wenn ich Einstellungen nur an einem VSMTP mache. Ich habe meine Testumgebung die ich nun mit meinem Kollegen bald noch mal neu aufsetze (er will es ja auch mal mitmachen) kurzerhand mit 3 Exchange ausgestattet. Also nun sind alle DCs und ein Mitgliedserver Exchange. Hoffe so kann ich nun ein bisschen mehr über die Routinggruppen und Co erfahren. Doch ich hoffe, wenn jemand geziehlt einen Anstoss gibt, der logisch ist, geht es bei mir von ganz alleine.... Bespielsweise sind Loops oder sowas enstanden als ich dem SMTP Connector nur meinem neuen VSMPT zugeordnet habe. Ich stehe auch nicht wozu der Connector ist, wenn man sogar beim VSMTP direkt einen SmartHost eintragen kann... Ich hab keine Scheu von ganz unten die sache zu begreifen aber das Grundsätzliche scheint mir schon nicht klar zu sein.

Hallo, das geht damit los, das wir bei einem Kunden am VSMTP mal dran mußsten, um ein Timeout und die gleichzeitige Zahl der Verbindungen zu ändern. Ebenso wie für Greylisting die Zeiten bei denen neu versucht wird. Das hat für mich alles zum Teil eher was mit dem Versandt zu tun. Und da ich nun einen SMTP auf einem anderen Port als 25 brauche, hab ich 2 VSMTP nötig, da ich bei beiden aber solche Dinge für das ausgehende SMTP angebe, ist mein Unverständnis perfekt. Den Namen der beim HELO verwendet wird kann/muss man da auch angeben, das muss ich nun aber immer 2 Mal machen und ich weiß nicht welhce Einstellungen überhaupt gebraucht werden. GRuß

Auch hier ist leider kein Wunschkonzert angesagt. Und man sollte sich schon vor einem Update mit dem Produkt auskennen. Und ein Update ist leider im Moment nicht da. 6 Jahre, hört sich schon alt an, aber man muss ja bedenken das es der direkte Vorgänger ist. ;) Ich habe halt ein Konkretes Projekt wo ich was umsetzen muss, und die haben 2k3 und werden es erstmal behalten. Einen 2k3 den ich nur hier und da betreue im Büro haben wir auch, und da dort noch mehr drüber geht, kann ich auch nicht mal einfach was machen. Daher habe ich mir ja auch erst die Testumgebung gebaut. Momentan hab ich aber Verständnisprobleme mit der logischen Verbindung und Funktion von Virtuellen SMTP Servern unter Protokolle und den Connectoren.... aber das kommt sicher noch weiter im Buch, sonst frag ich hier wieder;)

Darf man dann erfahren welches das ist. Ja, ich arbeite dran das kennenzulernen. Aber Wunschkonzert ist bei uns leider nicht. Nur ist Spambekämpunfung und Mail von A -> B schon ein unterschied. Aber gern hab ich den Exchange nicht... :-)

A Record = Name zu IP-Adresse nslookup NAME [DNS Server] PTR Record = IP-Adresse zu Name nslookup IP [DNS Server] MX Eintrag = Name/domain auf Name hier werden in dem MXer Ziel nur Namen die dann wieder ein A Record sein müssen zugelassen. nslookup -querytype=mx DOMAIN [DNS Server]

Wenn die E-Mails dann nicht weiter verarbeitet werden, oder Gesammelt werden könnten, dann ist vielleicht für Kurze Zeit die Möglichkeit die einem eigene Benutzer zuzuordnern. Also einen Neuen Benutzer anlegen, alle alten Adressen zuordnern und Ihm einen Autoresponder anlegen. Ist aber eher ein Hack. Bei Autorespondern muss man laut RFC auch auf viele Dinge achten, so trivial ist das Thema gar nicht. Weiß leider nicht im Detail wie der Exchange damit umgeht...

Du musst für jedes Postfach des Exchange Servers auch ein Postfach auf seiten des Providers (POP3) haben. Stelle Dir doch mal BCC vor. Das bedeutet as ist kein Header der irgendwo reingeschrieben wird. Die E-Mail wird per SMTP mittels des Envelope (der ja nicht im Header stehen muss) weitergeleitet, und am Ziel in ein POP Postfach gesteckt. Dort ist die Information für welches Ziel die Mail war dann verloren. Wenn Du das nun abrufst, dann weißt du so oder so nicht wohin damit. Bei Rundmails steht da sogar im To dann eine Adresse die gar nicht von Dir ist. Lösen kannst du das nur, wenn Du wie oben beschrieben, per SMTP weiterleitest, oder für jedes Postfach ein POP3 Konto hast.

Also wir haben auch mit Kunden aus China und Co keine Probleme, und im Zweifel kann man da auch Flexibel reagieren. Wenn es einen guten Grund gibt ausnahmen zu machen, wir es auch gemacht, daher ist der Anbieter auch so "gut". :) Man kann über alles reden. Bei Postfix braucht man übrigens keine Liste von Adressen die Gültig ist, das macht der Dynmisch selbst. Funktioniert mehr als super. Gruß

Rechtfertigen, ne, so weit würde ich nicht gehen, wobei man in diesem Thema oft den Eindruck hat, da gebe ich Dir recht. Ich habe im Bereich E-Mail das letzet Jahr viel gerlernt, komme so aus der Linux/Postfix Welt. Ich würde immer einen Postfix vor einem Exchange stellen, das wirkt Wunder. weiterhin würde ich immer Spams ablehnen und nicht in einen Ordner legen. Wir haben auch erst, gerade im Firemenumfeld gedacht das geht nicht, doch da die Erkennungsrate hoch ist, und das false positiv gegen NULL geht (wirklich wahr) war es kein Problem für uns und unsere Kunden. Das System (auch wenn man es selbst Einsetzt) ist sehr flexibel und absolut Kostenlos. Da kann man die Kosten dann in das stecken was Sinn macht, in das aufbauen von KnowHow in dem Bereich. Aber auch wenn man das nicht will, über den Provider läuft es wie eine Eins... Produkte die also was kosten, UND wo man meistens gar nicht weiß wie genau Sie arbeiten, dann noch Bugs oder Probleme entstehen die man erstmal umfangreich Analysieren muss, sind mir einfach ein bissche Suspekt. Die Philosopihie muss aber jeder für sich entscheiden, Nur so viel. Für sehr sehr viel Spam E-Mail setze ich für sehr viele kunden "nur" auf eine Effe normale kleine Hardware, nix besonderes. Das ist also von mehreren Standpunkten aus super, und wenn man dann noch mit dem Budget die Leute ans arbeiten bekommt (haben keine Spam mehr) Und das Know How der Admins steigt, oder eben Zeit für andere Dinge bleibt, dann haben alle gewonnen.

Das ist richtig... jeder hat eine andere Meinung ;) Aber ist das nicht überall so? Spamfilterung klappt meistens nur in der Masse gut... und wir sind mehr als zufrieden mit unserem Provider. Der kann das und ist in dem Bereich wirklich einer der TOP Anbieter in Deutschland. Ich könnte das auch selbst, doch durch die Masse können Sie einfach bessere und andere Regeln schreiben. Außerdem habe ich seit dem vor diesem Problem Ruhe. Und es kommt alles was kommen soll. Falls da jeamnd bedenken hat

Ich würde schon einen Provider nehmen mit Spamfilterung, bzw. einen der MXer macht und als Smarthost fungiert... dann hast du mit dem meisten einfahc keinen Ärger. Man kümmert sich lieber um andere Sachen :)

Ok, dann ist aber das ursprüngliche Probleme behoben, oder? das freut und dann doch alle ;) Die DNS Server scheinen dann aber korrekt eingestellt zu sein. Warum die dann angemeckert werden kann ich mir nur wie sonst erklärt vorstellen, nämlich das die keine Antworten für 127.0.01. haben. Wobei das hier gerade klappte C:\>nslookup -querytype=ptr 1.0.0.127.in-addr.arpa 194.25.2.129 Server: dns03.btx.dtag.de Address: 194.25.2.129 Nicht autorisierte Antwort: 1.0.0.127.in-addr.arpa name = localhost Wobei er eigentlich diese Anfgrage als Autorisiert geben können sollte. Ist dann aber ein zu vernachlässigender Fehler.

Wenn deni Exchange im Lokalen Adresseraum Beispiel: 192.168.2.0/24 liegt und per NAT vom Router nach außen geht, dann würde Trotzdem der Exchange per SMTP oder sonst wie mit anderen Mailservern reden. Beim SMTP Dialog stellt sich der Exchange dann mit einem EHLO oder HELO und seinem Namen vor. Ein Server auf der Gegenseit kann nun also prüfen ob der Kommunizierte Name dem Reversenamen der IP-Adresse mit dem er die Verbindugn aufgebaut hat, übereinstimmt. Passiert das per NAT, dann ist das nicht die IP-Adresse vom Exchange. In der Regel würde man hier denke ich den HELO NAmen des Exchanges ändern. Der oben genannte Check ist nicht der einzieg, mann könnte auch "nur" prüfen ob überhaupt ein Reverse vorhanden ist, oder ob der Name der Kommuniziert wurde ein FQDN ist, oder ob der Name vorhanden ist. Da aber irgendwo immer jemand alles fragt, und es keine Arbeit ist, muss hier alles korrekt eingestellt sein. Exchange Name (im HELO/EHLO) muss gleich dem Reverse der Öffentlichen IP-Adresse sein, der Name muss auch selbst im DNS auf die IP-Verwesen. Zur Sicherheit sollte es auch kein Namen sein wie er von Dial-IN Providern genutz wird wie t-dialin.de der so, auch die Anzahl der Punkte kann entscheidend sein. Leider ist hier viel Regelwerk draußen im Netz, einen Normalen Hostnamen wie "exchange01.domain.tld" oder "standort01.firma.tld" ist meiner Meinung nach die beste Idee, und auch später zu anderen Zwecken zu verwenden... GRuß

Das ist eien Termporäre Fehlermeldung vom Ziel, kann also Theoretisch Greylisting sein, im Logfile müsste aber der genaue String stehen den der Server sendet... ich gehe mal einfahc davon aus da steht mehr drin. Der Code DSN 4.3.2 sollte für die Ursache stehen, aber da hab ich auf die schnell nichts gefunden was ich hier als Fakt niederschreiben würde. Es scheint eine Art überlastung auf der Gegenstelle zu sein einfach mal warten und schauen wann die E-Mail raus geht. Und ins Logfile schauen ob da mehr steht

das sind aber viele Weiterleitungen, kann das sein? Wo genau hast du die eingetragen, vielleicht einen Screenshot der Maske? Die Meldung die da kommt sagt aber nur das die Zone "localhost" und auch die Reverse Zone von 127.0.0.0/8 nicht beantwortet wird, was laut RFC normal jeder DNS beantworten soll. Daher geht der Test davon aus, es sei kein korrekter DNS Server. Zur Sicherheit würde ich aber noch mal prüfen wie diese Weitergeleitet sind, oder falls vorhanden, deinen Router nehmen. Die haben ja auch meistens einen DNS Server, und leiten diesen dann wiederum zum Server, was den Vorteil hat, das die Server vom Provider ja schon mal anders sein können, die bekomm man (Vorrausgesetzt ein Dial-IN Account oder ähnlich) dann ja dynamisch. Aber Funktioniell, wenn deine DNS Server beim Provider mittels nslookup korrekt funtkionieren, und die Weiterleitung korrekt eingetragen ist, macht ads kein Problem: nslookup DNS_NAME EXPLIZITER_DNS_SERVER Wenn heir drauf geantwortet wird, dann sind das acuh Server die man für eine Weiterleitung nutzen kann

Klar, verstanden, ich meinte nur wenn die Strecke down ist, also keien Replikation laufen kann (in der Zeit) aber an beiden Standorten (selbe Domain) das gleiche Object (Benutzer) geändert wird. Dann will er doch in beidr Richtungen Replizieren, und hat an beiden Seiten eine Änderung, wie macht der das? Gewinnt die neuere. Oder muss der PDC Master die Kennwortänderung bestätigen, hat also das letzet Wort. Dann dürfte aber ohne WAN strecke der Benutzer in dem Standrot wo der DC ohne PDC-Master steht keine Änderung machen können solange dieser nicht erreichbar ist. Oder? Also zwei Standorte, eine Domain, zwei DCs, je Standort ein DC.

Ich bin heute glaub ich falsch aufgestanden, was genau meinst du, den ROOT Server? Das Problem war doch erledigt. Das mit der Repliktaion kann vielleicht jemand anderes beantworten, oder ist dcpromo vielleicht schon "ein bisschen" gelaufen. Wenn dcdiag, netdiag und dnslint keine Probleme haben, dann würde ich einfach mal loslegen... also versuchen mit dcpromo einen DC neu zu erstellen.

Das er keine Anmeldungen mehr haben wollte ist klar, aber warum wurde dann der 2. nicht mehr gefragt? Dazu sind doch mehrere DCs da. Und wenn es nur einen gibt, dann sollte eine replizierung doch gar nicht da sein, oder habe ich hier gerade einen Gedankenfehler? Key? Du meinst den Regeintrag? Also ist nun wieder alles im Lot, und dein Ursprüngliches Problem das die Domain und das AD strubelig sind sind erledigt? Dann kannst du nun ja mit dem Austausch der DCs anfangen, oder?

Wie sieht es denn aus wenn man bei der Site (längere Replikationsintervale) an zwei Standorten das PW ändert. Oder werden diese Einträge auch Sofort repliziert. Oder was ist wenn man das machen würde wenn gerade die WAN strecke ausgefallen ist? Gibt es dann Fehler, kann man diese korregieren. Solche Fehler würden bei einer Subdomain doch nicht eintreten, oder?

Also wie oben zu lesen ist in den Fehlermeldungen macht es nach wie vor den Anschein das er Namensauflösungen nicht so korrekt hinbekommt. Das ist alles ein bisschen mergwürdig. Ansonsten auch noch mal nach den Fehlermeldungen Googlen. Aber ich denke das zumindest das mir den Sicherheitsrichtlinien daran liegen kann. Und was hat er nach den 5 Minuten die oben angekündigt wurden nun gesagt? Gruß

Also in der Regel klappt direkter Versandt per DNS und auch der Empfang wenn der MX auf Deine IP steht. Aber da gibt es schon einiges zu beachten. ICh würde einen Smarthost vom Provider empfehlen, und auch vom Provider per SMTP die E-Mails bekomen wollen. So kann rein und raus der Provider alles leisten was er soll. Spam und Virenfilter, deine Firewall kann Dich gemacht werden, und alles ist schön. Zum Empfang von E-Mails, Greylisting kann da verzögern, ist mit regelmäßigen Kontakten aber nur eine Frage der Zeit bis das "normal" arbeitet, weil das System lernt. Ausgehend kann es mehr oder weniger am Gegenüber liegen wie auch am Provider. Ein Beispiel: Dein Provider benutzt 254 Server zum versenden (Cluster) jeder Deiner E-Mails hat immer eine andere Absender-IP vom Provider wenn es zum ziehl geht. Dann kann das Ziel die IP-Adresse im Greylisting erst sehr viel Später lernen (da es über Masse geht) als wenn es immer nur eine Ist. Wenn du auch wegen Spamfilter und Co einen ordentlichen Provider suchst, kann ich Dir per PM gerne eine Empfehlung aussprechen. Die sind nicht so die Windows Fachmännger, aber beim Standard SMTP ist das auch quatsch... die sprechen dafür E-Mailprotokolle fließend und ohne Dialekt :) Zum testen, für eine Zieldomain, würde ich einen neuen Connector anlegen und nur die Domain darüber lenken, das Logging hoch drehen und dann einfach mal schauen was der da bringt, vielleicht geht genau wegen Greylisting ja auch bei Dir die E-Mail dann erst nach 30 Minuten oder länger raus (einstellungssache) Aber das sollte man in den Logs dann sehen können. Gruß

Da bei BCC als Beispiel der Empfänger eh ein anderer ist sollte man ein komplettes Postfach (POP3) einem Postfach vom Exchange irgendwas.local zuordnen. Dann ist der Empfänger egal. Diese Probleme haben eigentlich sehr viele unserer Kunden die Sammelpostfach versuchen mit allen möglichen Produkten auseinander zu suchen. Entweder sollte es ein POP Postfach für jeden Benutzer geben, oder den Exchange direkt per SMTP anbinden.

Ich habe Version 6.0 und ich habe laut hilfe ja die /admin Funktion, nur das man /console angeben kann ohne einen Fehler, und ich das schon aus gewohnheit mache :) Gruß

Wozu ist denn die Option /admin, kann es sein das die nicht bei allen RDP Clients dabei ist? Ich sehe gerade die von mir verwendete Option /console Also "mstsc.exe /console" gibt es gar nicht mehr? Oder ist die inder Hilfe "mstsc.exe /?" nur nicht aufgeführt? Nun bin ich ein bisschen verwirrt