Beiträge von NoHopeNoFear

die david eigenen fehlermeldungen sind irrelevant weil ungenau. wichtig ist was in der smtp kommunikation passiert und welche fehlermeldungen dort geworfen werden.
das speichert david auch für jede mail ab und ist nachprüfbar. es gibt einige verschiedene smtp fehlermeldungen (an sich ja immer eindeutig sind) die david als "temporär beschäftigt" interpretiert. greylisting wird es in 99% der fälle ohne direktversand nicht sein.

du sagst doch selbst dass SMTP direktversand nix taugt und man es per smarthost einrichten soll. jetzt behauptest du dass hier niemand einen relay server benutzt?
natürlich benutzt hier die mehrzahl der installationen keinen direktversand sondern ein relay über den provider, ist schließlich bei kleineren systemen auch so üblich.

ein smtp relay / smarthost an dem ich mich mit login daten anmelde führt KEIN greylisting aus. greylisting wird nur beim empfang von emails durch einen zustellenden client und nicht beim einliefern einer mail des clients für ein relay ausgeführt. man kann das sicherlich auch anders konfigurieren, macht aber niemand da der vorgang vollkommener unsinn wäre. schließlich hat sich der client durch seine login daten ja als vertrauenswürdig erwiesen.

die momentan von 1und1 geworfenen fehlermeldungen (um die es ja hier ursprünglich ging) waren vermutlich hauptsächlich interne fehlermeldungen des mailsystems dort. soweit wir es beobachten konnten waren die smtp fehler hauptsächlich "falscher absender" und nicht die klassischen meldungen für ein greylisting (450, busy, mailbox locked for policy reasons oder ähnliches).

ein smtp relay server (den wohl fast jeder hier nutzt) wird niemals einen client der sich erfolgreich authentifiziert hat greylisten. das wird nur für nicht angemeldete clients gemacht die an ein ziel postfach mails zustellen wollen.
greylisting ist nur dann ein problem (für den absender) wenn er direkt versendet, sofern der versand über einen relay server / smarthost läuft kann das greylisting auf empfängerseite zwar passieren, der absender hat aber keinen einfluss darauf.

der 2. punkt macht idr. keinen unterschied, ist der relays server korrekt konfiguriert (was die maschinen der großen provider idr. sind) ist es absolut egal über welches konto die anmeldung erfolgt. der empfänger prüft die reputation des absendenen servers, wie der anmeldevorgang ausgesehen hat ist ihm egal und er kann es auch nicht prüfen.

das hier gerschilderte problem ist definitiv ein provider problem (das geht auch klar aus dem smtp logs hervor wenn man sich die mühe macht mal rein zu schauen) und hat nichts mit der client seitigen konfiguration zu tun.

scheint an 1und1 zu liegen, problem besteht bei mehreren kunden sporadisch seit (mindestens) montag.
gibt wohl auch probleme beim empfang, teilweise bekommt der absender ein NDR obwohl die mail zugestellt wurde.

selbst wenn du einen längeren betreff eingeben könntest ist es fraglich ob das beim empfänger korrekt ankommt.

natürlich geht das. dafür brauchst du aber ein gültiges zertifikat und einen absender der das ganze mit macht.

die aussage von arno ist sowieso nur bedingt richtig. wenn du per pop3 deine mails verschlüsselt abholst ist das zwar schön und gut, wo die mail vorher (zwischen mail relays) unverschlüsselt durch die gegend geflogen ist kannst du aber schwer bis garnicht nachvollziehen.

wer wirklich verschlüsselt mailen will muss die mails verschlüsseln, nicht den transfer weg da man nie sicher stellen kann dass alle beteiligten server ebenfalls die kommunikation verschlüsseln.

wenn du auch selbst versenden willst brauchst du zwingend eine echte statische IP inkl. reverse DNS.
das funktioniert nicht mit "normalem" tdsl business oder ähnlichen einwahlleitungen. dafür brauchst du ein entsprechendes produkt mit eigenem subnetz. sonst werden die meisten großen mail provider deine mails nicht annehmen da ersichtlich ist dass die absendende IP zu einem dial in pool des providers gehört.

in dem fall brauchst du zwingend weiterhin die möglichkeit über einen smarthost versenden zu können.

faustregel ist hier wenn du login daten bekommst für eine pppoe verbindung wirds vermutlich nicht gehen. das trifft zumindest auf die großen provider zu.

mx record auf deine statische ip legen (erfordert je nach domain hoster / dns system) evtl. dass zuerst ein a record für die ip angelegt wird. (mx muss immer auf a verweisen, viele hoster legen automatisch einen a record für das mx ziel an, z.B. hosteurope)
in postman unter datenbanken -> gültige domains die anzunehmende domain eintragen
prüfen dass der postman keine weiterleitung/relay ohne anmeldung macht
port 25 im router aufmachen

empfehlenswert ist es die umstellung am we zu machen. manche provider killen sofort bei einrichtungen eines alternativen mx eintrags die mailkonten so das kein pop3 abruf mehr geht. ist das nicht der fall kann man das auch unter der woche machen da parallel smtp/pop3 funktioniert. bis alle dns server weltweit den neuen mx kennen dauert es idr. bis zu 24h. in der zeit hast du dann eingänge auf dem alten system (pop3 abruf) und direkt empfang.

Zitat von mechworm

Es ist richtig, das dies wohl ausschließlich via TLS über Port 443 und einem selbst erstellten Zertifikat in Zusammenhang mit einem iPhone funktioniert.

ist es nicht, es geht definitiv unter iOS auch unverschlüsselt oder über andere ports.

meines wissens nach ist das normal, gelesene mails werden bem pop3 abruf vom maserver ignoriert. war schon immer so.
sollte bei imap nicht auftreten.

mein auto fährt nicht, warum?

ernsthaft, was soll jemand mit dieser fehlerbeschreibung (die absolut keine ist) anfangen können?

Zitat von hueb

Hallo,

iPhones können aktiv sync grundsätzlich nur über den Port 443. Mit Port 81 geht da nichts.

Ob das mit der installierten david-Version geht, wage ich zu bezweifeln.

Gruss

Klaus

doch doch, das geht.
du kannst sowohl SSL als auch standard HTTP über andere ports einrichten. einfach server:port im iphone angeben.
unter android habe ich es nie getestet, aber unter ios geht es auf jeden fall.

prinzipiell kannst du (auf verzeichnis/windows ebene) den ganzen user sichern, arc util laufen lassen und falls danach alles im eimer ist wieder rücksichern.
viel schief gehen kann nicht - sofern denn ein funktionierendes backup vorhanden ist.

und ja, die archive.dat musst du nicht anfassen wenn nur die ordner struktur selbst und nicht der inhalt der ordner im eimer ist.

tobit partner gibts wie sand am meer, gute vermutlich weniger. das muss auch keiner vor ort sein da sich das meiste idr. remote erledigen lässt. wenn du wirklich mal ein ernsthaftes problem mit dem server hast wirst du einen partner brauchen der auf die schnelle helfen kann. das forum hier ist zwar schön und gut aber wenn es um geschäftskritische ausfälle geht nicht die erste wahl.

Zitat von beltiga

Hallo,
ja richtig, es antwortet nicht der Postman, sonder der IMAP:

Code

* OK IMAP4rev1 DvISE Mail Access Server MA-8.10a (0126)

Wenn Lizenzen fehlen, dann sollte sich aber doch zumindest die Einstellungen für den "Mail Access Server" öffnen lassen, oder denke ich da falsch?
Kann ich die Lizenzen in der Verwaltung des Servers denn irgendwo kontrollieren, oder gibt es für IMAP überhaupt eine Log-Möglichkeit?

Ja leider ist die David Version wirklich alt.

funktionieren sollte der dienst schon ohne lizenz. also zumindest die config aufgehen.
was du machen kannst: den ordner david\apps\maserver umbenennen in irgendwas
installations cd drüber ziehen
letztes update drüber ziehen

damit werden alle files vom maserver neu erstellt, evtl. hats da mal was zerhauen.

vorher natürlich eine komplette sicherung vom gesamten david ordner anlegen. ich halte es allerdings auch für fragwürdig ob aktuelle mail clients noch mit einem V8 IMAP zurecht kommen.

Zitat von beltiga

Der Dienst läuft allerdings, ein Telnet auf Port 143 funktioniert soweit, dass der DvISE Postman antwortet.

sicher das auf port 143 der postman antwortet? wenn ja is da was faul, da muss der ma server antworten.
bin mit bei V8/V8+ auch nicht mehr so ganz sicher aber ich glaube v8 brauchte noch remote access lizenzen pro user.

schau dir mal das verzeichnis david\apps\faxware\out\api an, liegen dort files drin? wenn ja verschieb alle aus dem ordner raus, starte den service layer neu und teste den versand erneut.
wenns dann geht die files einzeln zurück kopieren, eine davon ist defekt und blockiert alle weiteren. hat tobit nach 20 (?) jahren immer noch nicht in den griff bekommen.

wenn du noch'n backup der alten david.usr hast lässt sich damit evtl. was machen.
sind die original ordner auf windows ebene noch vorhandenen reicht es evtl. die .usr zurück zu kopieren.

hab das lange nicht mehr gemacht, meine aber dass das (zumindest früher) möglich war.

zumal man auch sagen muss dass die EAS verbindung (sowie imap, und DAV) im vergleich zu anderen systemen nicht sonderlich stabil ist.
webboxx abstürze, einzelne geräte die nicht syncen etc. ist auch heute noch ein problem.

das sollte sich umgehen lassen wenn per registry die vorlagen nochmal definiert werden.
macht natürlich nur wirklich sinn wenn es nicht x verschiedene gibt.

Neue eMail:

HKEY_CURRENT_USER\Software\Tobit\Tobit InfoCenter\Servers\%SERVERNAME%\TemplateFN "UNC-PFAD ZUR 001 DATEI"

Antworten:

HKEY_CURRENT_USER\Software\Tobit\Tobit InfoCenter\Servers\%SERVERNAME%\TemplateREPFOR "UNC-PFAD ZUR 001 DATEI"

Beispiel:

Key: HKEY_CURRENT_USER\Software\Tobit\Tobit InfoCenter\Servers\123david\TemplateFN

Wert: \\123david\david\archive\user\10014000\txtmdl\IDE0199F.001