complusit warum nutzt Du nicht einfach den "Verteilpräfix" auf dem Reiter Erweitert der Portkonfiguration? wenn Du möchtest kannst Du dort sogar Dein kompletter 0049VORWAHLRUFNUMMER eintragen. Bei nur zwei Rufnummern die auch noch auf zwei getrennten Ports reinkommen ist das ja kein echtes Dilemma.
Wenn ich das mit fast 100 Faxnummern machen müsste würde ich Sipgate wohl den Rücken kehren, aber bei nur 2 Nummern...
Das ich mal einen Absender über einen von ihm versendeten Virus informiert habe kam in den vergangenen 20 Jahren vielleicht 2 mal vor.
Die restlichen Vieren kamen aus Quellen mit denen wir entweder eh nichts zu tun haben, oder wo trotz dessen das die mail behauptete von einem uns bekannten Absender zu sein eh klar beweisbar der Absender gefaked wurde. In solchen Fällen nerve ich die vermeintlichen Absender sicher nicht damit ihnen mitzuteilen was da so in ihrem Namen versendet wurde. Ich würde mir solche Infos schließlich auch nicht wünschen, weil ich eh nichts dagegen tun kann. Nur wenn etwas tatsächlich aus einem unserer Systeme kommt wünsche ich mir eine Meldung und handhabe das eben andersherum daher genauso.
Die Meldungen des David nehme ich zur Kenntnis, weiß aber eh das die Dateien dann bereits gelöscht sind und ich mich nicht mehr drum scheren muss.
Den Samstags Scan lasse ich immer gern durchlaufen, weil er schon auch mal was finden könnte das erst nach dem ursprünglichen einlaufen bekannt wurde, was er also damals nicht erkennen konnte.
Vorsichtig muss man mit dem Grund oder Samstags Scan nur sein wenn man selbst nachträglich Ausschlüsse hinzufügt, wie z.B. keine Excel Dateien mit Endung die auf Makros hinweist mehr zulassen zu wollen, denn dann räumt er einem auch alle schon im System befindlichen alten Dateianhänge mit gleicher Endung gnadenlos weg.
ammermueller Du hast vermutlich den Hinweis bereits gegeben was da passiert.
Es kommt zu einer Weiterleitung an ein catchall Postfach, was bedeutet das es eigentlich einzelne Postfächer für die verschiedenen Empfänger gibt, welche dann aber so eingestellt sind das von dort aus eine Weiterleitung erfolgt.
Das führt dann natürlich zu dem von Dir beobachteten Verhalten.
Es gibt da im Grunde nur zwei Lösungsmöglichkeiten:
1. löschen oder wenn das nicht geht umbenennen der einzelnen Postfächer, so das die Mails dann gleich per wildcard im catchall Postfach auflaufen und keinen Umweg über eine Umleitung gehen.
2. löschen der Weiterleitungen auf das Catchall Postfach und statt dessen einsammeln der Mails aus den einzelnen Postfächern welche bislang auf das Catchall Postfach weitergeleitet werden. Eventuell sollte dabei das catchall Postfach dennoch weiterhin mit abgerufen werden um so auch fehladressierte Mails welche in keinem der explizit eingerichteten Postfächer auflaufen mit abzuholen, alternativ das catchall Postfach auf Mails ablehnen stellen, so das Empfänger fehlerhaft adressierter Mails informiert werden statt das die Mails versanden.
All das gilt natürlich nur wenn es tatsächlich so ist das ihr da aktuell ein Setup vor Euch habt bei dem die Mails nicht direkt per wildcard im Catchall Postfach landen, sondern tatsächlich aus individuellen Postfächern per Weiterleitung in das Catchall Postfach eingeleifert werden.
Wizzard haha, jetzt ja, ich hatte das eingangs beschriebene tatsächlich nicht so verstanden wie es da aber ehrlich gesagt klar und deutlich beschrieben ist. Das muss schlicht an meinem "Unglaublich das es sowas gibt" Filter hängen geblieben sein 
Wizzard welcher Provider macht denn sowas bei Catchall Postfächern?
Ich betreue schon sehr lange verschiedene Mailserver Installationen bei verschiedenen Providern, aber das ein Provider den Namen des Catchall Postfachs in den Envelope-To: oder X-Envelope-To: Header einträgt ist mir noch nicht untergekommen.
Das würde ja nur dann passieren wenn man beim Provider eigentlich für jeden User ein einzelnes Postfach unterhält und von dort aus dann per Regel in ein Catchall Postfach weiterleiten lassen würde.
Das wiederum wäre dann aber auch eine wirklich unsinnige Konfiguration.
Guckt Euch den kompletten Mail Header der eingehenden Mails an und sucht nach dem korrekten Mail Header welcher die jeweilige Zieladresse angibt. die Received Zeilen welche Du oben angefügt hast sind dafür normaler Weise nicht zuverlässig brauchbar.
Je nach Provider gibt es ein Feld wie z.B. "Envelope-To:" oder bei unserem z.B. "X-ENVELOPE-TO:" mit dem tatsächlichen Empfänger.
Dieser Feldname muss bei "Auszuwertendes Adressfald" des POP3 Postfachs angegeben werden.
Nur wenn der eigene Provider kein sinnvoll auswertbares Adressfeld im Header der im Catchall Postfach einlaufenden Mails bereitstellt braucht es einen Wildcard-Eintrag im Feld "Zieladresse", dieser verhindert dann das auch Mailadressen außerhalb Eurer Domain in den Header Zeilen wie Empfänger bei Euch ausgewertet werden. Wenn der Eintrag "Auszuwertendes Adressfald" dann leer bleibt werden alle Header Zeilen ausgewertet die auch nur ansatzweise eine Zieladresse beinhalten können. Das Ergebnis kann dann aber unvorhersehbar chaotisch aussehen.
Besser ist es nur "Auszuwertendes Adressfald" mit einem zum eigenen Provider passenden Inhalt zu befüllen und das "Zieladresse" Feld leer zu lassen.
PeterPan hast Du das bei Tobit bereits gemeldet?
Ansonsten schließe ich mich nordtech an das auch ich den Fehler noch nicht beobachtet habe.
Wobei das natürlich nur bedeutet das er noch nicht aufgefallen ist, nicht das er noch nicht vorgekommen ist. Wir haben halt recht viele Nutzer, da kann es etwas dauern bis einer eine Auffälligkeit bemerkt und meldet, ausschließen kann ich also nichts, aber Stichproben haben bis jetzt keine Auffälligkeiten ergeben.
Ich konfiguriere die Windows Updates so, dass sie mit 2 Wochen Verzögerung automatisch an Wochenenden installiert werden. So kann ich bei bekannt gewordenen Problemen noch eingreifen, bevor das Update installiert wird. Gibt es keine Probleme läuft die Installation unbeaufsichtigt.
Ändert halt nichts dran das der Server unter dem David allein schon dadurch nicht Monatelang durchläuft 
es ändert nur den Zeitpunkt des monatlichen Neustarts...
Und wenn der Kunde das neue Jahr für Sitecare bezahlen soll, dann tauchen die Fragen auf, WoFÜR !?
Nun, zu dem Thema habe ich meine Meinung oben ja schon mal deutlich kund getan. Wer nicht versteht warum er SiteCare zahlen sollte braucht Nachhilfe in Sachen Geschäftsführung. Sorry, aber das muss man so deutlich sagen.
Nur gut das ich hier keinen Händler vertrete, sondern mich nur um unsere Sicht als Kunden kümmern muss
hmm, wenn nicht jeden Monat Windows Service Packs einzuspielen wären welche einen Neustart des Servers erfordern würden könnte man das sogar mal versuchen.
Dank der teils langen Zeiträume zwischen zwei David Releases hab ich da jedenfalls häufiger auf den David Server zu schauen weil ich neue Nutzer anlegen oder alte löschen muss als wegen dem David Server selbst.
Ich würde jedenfalls glatt sagen monatelang laufen ohne das ich ihn anschauen muss würde unser David Server durchaus auch, wenn ich mal ne Weile drauf verzichte Microsoft Service Packs einzuspielen und ne Weile keine Benutzer ändern brauche.
Wenn natürlich tatsächlich ca. alle 14 Tage neue David Rollouts kämen wie manche scheinbar wünschen (siehe die ersten Kommentare) wäre es natürlich vorbei mit der Ruhe...
Ich habe das gleiche Problem hier auch bei einem David Nutzer, da der bei uns allerdings gerade keine Mails verschicken muss / soll hatte ich das erst mal nicht weiter beachtet und auf die "muss mal geprüft werden Liste" gelegt
Bei diesem einen Nutzer handelt es sich in meinem Fall um eine vor einiger Zeit ausgeschiedene Aushilfe welche nun für eine Woche wieder aktiviert wurde.
Seine sämtlichen Archive existierten auf dem Server noch und so wurde der Benutzer vom David Server wieder reaktiviert und seinen bisherigen Archiven wieder zugeordnet.
In dem Fall ist aber nur dieser eine Benutzer betroffen, das allerdings unabhängig davon an welchem Rechner er sich anmeldet.
Andere Benutzer am gleichen Rechner haben das Problem nicht.
Die Rechte des Benutzers auf seinen David Ordner und alle Unterordner davon habe ich geprüft, die scheinen allesamt o.k. zu sein, es gibt dort auch das Verzeichnis \Archive\User\<userid>\temp und der Benutzer kann dort auch Dateien anlegen und löschen.
Der Benutzer kann ansonsten problemlos Dateien im David ablegen und im Rahmen seiner zugewiesenen Rechte auch ändern, er kann nur nichts senden.
Da es bei dem betreffenden Nutzer im Grunde recht einfach ist und er kaum Daten im David liegen hat würde ich hier jetzt im Grunde dazu tendieren den einfach mal im David vollständig zu löschen und vollständig neu anzulegen.
Allerdings bin ich auch irgendwie neugierig und frage mich ob man das auch anderes reparieren kann
Der Hinweis von nordtech darauf das alle Nutzer Rechte am Ordner \David\apps\faxware\out\api brauchen haben mich allerdings auf die Lösung des Problems gebracht. Denn auf den Ordner haben alle David Nutzer einzig über die lokale Sicherheitsgruppe DVG-SERVERNAME Zugriff, deren Mitglieder sie dazu sein müssen. Nach dem ich den fraglichen Benutzer welcher kein Mitglied der Gruppe mehr war wieder dieser Gruppe hinzugefügt hatte, ihn einmal vom Client PC ab und wieder angemeldet und dann dort den David Client gestartet habe kann er nun auch wieder an beiden von diesem Nutzer genutzten PCs aus Mails versenden.
Danke nordtech (y)
Keine Ahnung ob diese Erkenntnis auch Thomas Mixa hilft, aber vielleicht macht es ja Sinn mal in der Richtung zu gucken?
SiteCare kündigen weil nicht alle 14 Tage ein Update kommt?
Uns sind gut getestete Updates mehr wert als agile Entwicklung die alle 14 Tage raushaut was gerade verfügbar ist!
Ansonsten ist SiteCare nicht teurer als beim Wettbewerb und immer noch günstiger als alle jubel Jahre mal den aktuellen Stand in Form eines Upgrades zu kaufen.
Wichtiger als dieser 14 Tage Marketing Quatsch - auf den offenkundig auch einige Tobit Partner abgefahren sind - ist das wenn notwendig auch Sicherheitsupdates kommen und das man im Zweifel zügig nachbessert wenn doch mal beim testen eines Updates etwas durchgerutscht ist.
Ja, auch David hat noch einiges an Potential welches gerne mal gehoben werden könnte, aber das gibt es in jedem Produkt und letztlich muss man sich das Produkt auswählen welches einem am besten zusagt.
Davon unabhängig gehört es heutzutage aber schlicht zur Sorgfaltspflicht im geschäftlichen Einsatz Wartungsverträge für die eingesetzte Software zu haben um sowohl Updates einspielen zu können wenn sie Verfügbar und der Sicherheit zuträglich sind, aber auch um dem Hersteller zu ermöglichen sich um das bereitstellen solcher Updates zu kümmern.
Wesen Kunden die SiteCare kündigen weil zu lange nicht alle 14 Tage Updates kamen sollte sich mal überlegen ob er das Produkt tatsächlich sachgerecht angepriesen und verkauft hat.
Sorry, aber in diesen Chor kann ich nicht mit einstimmen.
kann es sein, dass Vorgabe = schwarz ist?
schwarz steht eigentlich immer ganz unten in der Liste:
Mir ist allerdings das Problem noch nicht untergekommen und entsprechend auch keine Lösung dafür bekannt.
diese 3 Einstellungen sind für das Verhalten des Navigator Bereichs verantwortlich:
Hat schon irgendjemand mal versucht und war sogar erfolgreich dem Smart Client bzw. der Smart Client App am Smartphone eine eigene Vorlage für Mails zu verpassen, oder auch nur herausgefunden wo der seine Vorlage her zieht?
Das ist sehr schwer zu ergründen wenn man erst Monate später nach einem Tipp fragt.
Die Ursache wird mit hoher Wahrscheinlichkeit nicht an der David-Client Installation selbst liegen, sondern an anderen Veränderungen auf Euren Systemen. Man hätte also zu dem Zeitpunkt als es erstmalig aufgetreten ist genau gucken sollen was sich kurz vorher auf allen Systemen verändert hat.
Es gab in den letzten mindestens 6 Monaten jeweils mindestens einen Microsoft Patch welcher meist gravierende Auswirkungen auf das Windows Drucksystem hatte. Es kann aber durchaus auch sein das die Ursache in einer gänzlich anderen Komponente bei Euch liegt welche auf alle Arbeitsplätze und sogar den Server zutrifft.
Wenn Dir hier jemand Tipps geben soll wären allerdings mindestens noch Informationen zur Windows Version an den Arbeitsplätzen und am Server sinnvoll, sonst ist das reines im Trüben fischen.
Unsere Leute mit Notebook arbeiten von unterwegs aus durchgehend mit dem normalen David Client über LTE, DSL zu Haus und WLANs in Hotels oder bei Kunden.
Der Web Access wird hier schon seit Jahren nicht mehr genutzt.
Wobei so eine Datenbank wirklich sinnvoll wäre.
Da gebe ich Dir definitiv recht und ich hätte da auch schon einen Absender den ich mit genau einer einzigen Dateiendung in die Datenbank eintragen würde.
Aber das sollte halt echt eine separate Datenbank mit genau definiertem Zweck und einzeln festzulegenden Dateiendungen bzw. Typen sein und kein überraschender Seiteneffekt der hier genannten Liste.
Oder wird aufgrund der Domäne der PostMan komplett übergangen?
genau das
Das hat je derartige Auswirkungen gehabt?
Gut das es diese Auswirkungen nicht mehr hat, denn das ist nicht wofür diese Datenbank gedacht ist.
"email/PostMan/Datenbanken/erlaubte Adressen" soll einzig dazu dienen einzelne Adressen einer Domain welche man in "email/PostMan/Datenbanken/Nicht erlaubte Adressen" für eingehende Mails blockiert hat doch zu erlauben Mails zu senden.
Zusätzlich wird für Adressen welche in "email/PostMan/Datenbanken/erlaubte Adressen" eingetragen sind ein eventuelles Greylisting deaktiviert, was notwendig sein kann wenn ein Absender mit Greylisting nicht klar kommt.
Jeglicher Einfluss auf den Virenschutz wäre für diese Datenbank aber weder dokumentiert noch sinnvoll.
Ich habe festgestellt, daß der Zugriff auf das david-Verzeichnis über die NW-Freigabe auf den Systemem wo das Problem auftritt langsam ist. Will man das david-Verzeichnis öffnen dauert das ca. 4 Sekunden. Bei anderen Systemen geht das sofort. Es macht keinen Unterschied, ob über den Servernamen oder IP (\\Server08\david, \\192.168.0.108\david). Ist man einmal im david-Verzeichnis ist der Wechsel in andere Unterverzeichnisse schnell.
Nun, da hast Du Deine Ursache welche es genauer zu analysieren und zu beheben gilt.
SMB 1.0 ist auf allen Systemen aktiviert.
Wozu ? braucht die da noch wer? David jedendfalls nicht, wobei das mit dem Problem wahrscheinlich kausal im Zusammenhang steht.
