Quantcast
Channel: MDaemon – Andy's Blog
Viewing all 95 articles
Browse latest View live

MDaemon: Schutz vor Rückstreuung (Backscatter Protection)

$
0
0

Bei E-Mail ist wohl nichts ärgerlicher als Spam, aber genauso ungut sind weitere Nebenwirkungen die Spam-Mails verursachen. Wird z.B. eine Spam-Mail mit einer real existierenden legitimen Absender- oder Antwort-Adresse versendet, kommen auf diese sämtliche Blockier- und Fehlermeldungen zurück.

Dies nennt man Backscatter, zu deutsch Rückstreuung. Man ist selbst nicht Absender, bekommt allerdings den ganzen Ärger ab, wenn man das mal so ausdrücken möchte. Während man bei Spam-Filtern durchaus so einiges regeln kann, sieht es bei der Rückstreuung etwas anders aus.

Der MDaemon Messaging Server bringt allerdings mit der Funktion Schutz vor Rückstreuung eine gute Möglichkeit mit, auch dieses Problem anzugehen. Unter „Sicherheit – Sicherheitseinstellungen – Andere Funktionen“ befindet sich der Konfigurationsdialog:

Zu beachten gilt: Erst die Funktion aktivieren und sieben Tage laufen lassen, erst dann das Abweisen zuschalten.

Das Ganze funktioniert nur (richtig), sofern Nachrichten per SMTP zugestellt werden. Wird statt dessen DomainPop oder MultiPop verwendet hilft das nicht. Als Notnagel in solchen Fällen lässt sich allerdings mit dem Inhaltsfilter zumindest vorübergehend etwas Abhilfe schaffen, indem man eine Regel erstellt die auf die betroffene E-Mail-Adresse und typische Fehler-Betreffe reagiert:

Mögliche Betreffszeilen enthalten beispielsweise:

  • Mail delivery failed: returning message to sender
  • Undeliverable: This is a protected Recording from:
  • This is a protected Recording
  • Autosvar:This is a protected Recording from

MDaemon Email Server: Nach Update landen alle Nachrichten in der Störungs-Warteschlange

$
0
0

Nach der Aktualisierung eines MDaemon Email Servers landeten alle eingehenden Nachrichten in der Störungswarteschlange. Wie es dazu kam und die Lösung dazu wird nachfolgend beschrieben.

Den MDaemon Email Server zu aktualisieren ist keine große Sache. Im Regelfall einfach den Dialogen folgen und ggf. mal die Dienste durchstarten wenn’s automatisch nicht klappt. Kleinere Schwierigkeiten wurden hier im Blog das eine oder andere Mal beschrieben, alles nichts Weltbewegendes. Das gilt letztlich auch für diesen Fall.

  • Das Update lief ohne Schwierigkeiten durch und der MDaemon Email Server startete.
  • Nach kurzer Zeit fiel auf das alle eingehenden Nachrichten in der Störungs-Warteschlange landeten. Dies ist immer ein Hinweis darauf, das etwas bei der Prüfung durch AntiVirus, AntiSpam oder den Inhaltsfilter schief läuft.
  • Ein Neustart der Dienste änderte nichts.
  • Ein Blick unter „Sicherheit – AntiSpam“ offenbarte dann ein Problem mit dem Spamfilter:
    Wed 2020-07-15 20:33:11.379: * MDSpamD Error: could not process c:\mdaemon\queues\local\md5001000173476.msg Could not connect to host.
  • Ein weiterer Blick in den Task-Manager zeigte, das der SpamFilter nicht lief, da keine „MDSpamD.exe“ gefunden wurde.
  • Die Konfiguration unter „Sicherheit – Spam-Filter“ wurde überprüt, hier war alles notwendige aktiviert und in Ordnung. Nach einem Klick auf „Spam-Filter neu starten“ passierte offenbar nichts.
  • Ein Blick in das Ereignisprotokoll von Windows zeigte dann auf, das der Spam-Filter-Prozess abstürzt:
    Protokollname: Application
    Quelle: Application Error
    Datum: 15.07.2020 20:43:07
    Ereignis-ID: 1000
    Aufgabenkategorie:(100)
    Ebene: Fehler
    Schlüsselwörter:Klassisch
    Benutzer: Nicht zutreffend
    Computer: SRV01
    Beschreibung:
    Name der fehlerhaften Anwendung: MDSpamD.exe, Version: 3.42.0.0, Zeitstempel: 0x544ec2d0
    Name des fehlerhaften Moduls: perl520.dll, Version: 0.0.0.0, Zeitstempel: 0x550b547c
    Ausnahmecode: 0xc0000005
    Fehleroffset: 0x00001427
    ID des fehlerhaften Prozesses: 0x1ce4
    Startzeit der fehlerhaften Anwendung: 0x01d65ad7c7caf7ed
    Pfad der fehlerhaften Anwendung: C:\MDaemon\SpamAssassin\MDSpamD.exe
    Pfad des fehlerhaften Moduls: C:\Windows\TEMP\pdk-SYSTEM\9edb19631b40514aed6b75eaf89e7593\perl520.dll
    Berichtskennung: 05b872c3-c6cb-11ea-8136-0cc47a82b9ec
    Vollständiger Name des fehlerhaften Pakets: 
    Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
  • Da der zugrundeliegende Windows Server ohnehin wegen der Windows Update neu gestartet werden musste, folgte getreu dem Motto „Ein Boot tut gut“ ein Neustart und danach war alles wieder im Lot. Bislang haben wir dieses Fehlerbild nur einmal beobachtet, hoffen wir, das es dabei bleibt.

MDaemon: Flexible Abwesenheit (Autobeantworter)

$
0
0

Wegen Reise, Urlaub oder schlimmstenfalls Krankheit macht es durchaus Sinn eine Abwesenheitsbenachrichtung für E-Mails einzustellen. So erhält ein Absender automatisch die Info, das man nicht im Büro ist, wer ggf. Vertretung macht und wann man wieder da ist.

Im Regelfall handelt es sich dabei um gewisse Zeiträume, so das man von einem bestimmten Anfangs- und Enddatum ausgehen kann. In Verbindung mit dem MDaemon Email Server geht da allerdings noch mehr, wie beispielsweise das die Abwesenheitsbenachrichtigung nur an bestimmten Wochentagen gesendet oder ein Programm bzw. Befehl ausgeführt wird.

Bei einem Kunden kam die Frage auf, ob man für eine Mitarbeiterin die lediglich drei Tage die Woche da ist etwas einstellen könnte, damit Kunden entsprechend informiert sind. Der Trick neben dem richtigen Weg zur tage-weise Konfiguration (dazu gleich mehr) besteht darin das Enddatum in weiter Zukunft (z.B. 2099) zu setzen.

Die Konfigurationsmöglichkeiten unterscheiden sich je nach Weg. Soll heißen: Via MDaemon (Outlook) Connector können beispielsweise keine einzelnen Wochentage festgelegt werden:

Anders sieht es via MDaemon Webmail aus:

Und die meisten Optionen hat der Administrator via Verwaltungsoberfläche:

Tipp: Direkt in der Konfigurationsoberfläche von MDaemon bzw. dem jeweiligen Benutzerkonto Adressen bzw. Domänen hinterlegen, auf die der Autobeantworter nicht reagieren soll. Meist ist innerhalb des Büros oder der Firma ja bekannt, wann wer wie lange nicht da ist und in Folge macht es wenig Sinn das die Kollegen dann sozusagen ständig daran erinnert werden, wenn sie interne Nachrichten schicken.

Im Detail fehlt jetzt nur noch die Möglichkeit z.B. von Mittwochs 15:00 Uhr bis Montags 08:30 Uhr den Autobeantworter zu aktivieren, aber was nicht ist, kann ja noch werden.

Vielen Dank an den Support von EBERTLANG für den Tipp mit der MDaemon Verwaltungsoberfläche.

E-Mail-Fehlermeldung: 571 Delivery not authorized message refused & 550 Administrative prohibition

$
0
0

Bei einem Kunden trat seit ein-zwei Tagen das Problem auf, das ein bestimmter Empfänger nicht mehr erreicht werden konnte, zuvor war das gar kein Thema. Als Fehlermeldung kam immer „571 Delivery not authorized message refused (in reply to end of DATA command)“ zurück. Alle anderen Empfänger waren hingegen kein Problem. Laut Empfängerin sei zudem bei ihr alles in Ordnung.

Sucht man im Netz nach dieser Meldung findet sich dazu einiges. Das Ganze scheint hauptsächlich in Verbindung mit Microsoft’s Exchange Server aufzutreten. Unser Kunde verwendet den MDaemon Email Server, anhand der Kopfzeilen der Mails konnte nicht eindeutig geklärt werden, was auf der Empfänger-Seite für ein Mail-System zum Einsatz kommt.

Sucht man nach dieser Fehlermeldung findet man verschiedene, (imho) teils kuriose Ursachen:

bobcares – How to fix ‘571 Delivery not authorized message refused’ error in Exchange server

ATVIRTUAL – Mailserver Fehlercodes

MCSEboard – Exchange 2010 / Requested #571 Delivery not authorized, message refused ##

Aufgrund des Beitrags im MCSEboard und um auszuschließen das es am Outlook des Absenders liegt wurde die Nachricht nochmals via MDaemon’s Webmail versendet und kam prompt erneut mit gleicher Fehlermeldung zurück.

Um sicher zu gehen, das nicht der Absender irgendwie Spamfilter-mässig geblockt wird, wurde die Mail-Domain als auch der Provider hinsichtlich Einträgen in Blacklists überprüft:

heise – Spam-Listen

DNSBL Spam Check

MX Toolbox – Blacklists

Auch das Verlief ohne neue Erkenntnisse bzw. der Absender sowie Provider steht auf keiner Blacklist. Als nächstes wurde der E-Mail-Provider unseres Kunden kontaktiert, von dort hieß es das die E-Mail evtl. aus inhaltlichen Gründen abgelehnt wird, da der Abbruch nach dem „DATA command“ kommt. Zugegeben, an der E-Mail ist eine PDF-Datei angefügt, da es sich um eine Auftragsbestätigung handelt. An den PDFs hat sich allerdings ebenfalls nichts grundlegendes verändert und auch eine Prüfung zeigte keinerlei Aufälligkeiten.

Alles in allem weißt alles darauf hin, das es an der Empfänger-Seite ist, das Problem zu lösen. Da bis vor ein paar Tagen die Kommunikation erfolgreich war und sich bei unserem Kunden nichts verändert hat, ist es naheliegend, das beim Empfänger irgendetwas verändert wurde. Das kann ein neuer Spamfilter sein oder auch geänderte Richtlinien, das bestimmte Anhänge nicht mehr akzeptiert werden oder ähnliches.

An dieser Stelle wurde die Empfängerin ein weiteres mal kontaktiert, mit der Bitte die Fehlermeldung an ihren IT-Support weiter zu geben.

Einen weiteren Tag später kam bei einem anderen Empfänger noch folgende Fehlermeldung hinzu:

550 Administrative prohibition (in reply to end of DATA command)

Auch hier die Auffälligkeit mit dem „DATA command“, an dieser Mail hängt ebenfalls eine PDF dran, diesmal allerdings eine Rechnung.

Im weiteren Verlauf wurde mit E-Mails ohne Anhang getestet, selbst diese wurden abgewiesen, bei letztgenannten Empfänger interessanterweise mit der 571er-Fehlermeldung wie oben.

Wieder ein paar Tage später und trotz bitte das sich der jeweilige IT-Support der Empfänger mit uns in Verbindung setzt vermeldete unser Kunde, das es zumindest bei einem Empfänger eine Rückmeldung von einem Mitarbeiter gab, das man auf der Blacklist gewesen sei und es jetzt wieder funktioniert. Einen Grund für die Sperrung und um welche Blacklist (vmtl. irgendwas internes, da nichts öffentliches feststellbar war) es sich handelte wurde nicht genannt.

Von dem zweiten Empfänger wurde uns zuletzt von unserem Kunden berichtetet, das bei diesem zwischenzeitlich wohl die gesamte IT zusammengebrochen sei, diese und andere Umstände wären dort schon öfter vorgekommen.

Outlook: Termin mit Erinnerung bei weiterem Konto nicht möglich

$
0
0

Verwendet man Outlook mit zwei oder mehr Konten und trägt einen Termin mit Erinnerung in einen Kalender dieser zusätzlichen Konten ein, kann es vorkommen das einem folgende oder ähnliche gemeinte Fehlermeldung begegnet:

"Die Erinnerung für <Betreff> wird nicht angezeigt,
weil das Element sich in einem Ordner befindet,
der Erinnerungen nicht unterstützt. Sind Sie damit einverstanden?"

Den Termin kann man eintragen, aber es geht z.B. 15 Minuten vorher kein Fenster auf.
Handelt es sich um POP3- oder IMAP-Konten sowie weitere Datendateien wie z.B. Archive kann man in den Eigenschaften der Datendatei die notwendige Funktion aktivieren. Siehe dazu:

Mailhilfe.de – Eine Erinnerungsfunktion für Ordner in Archiven und zusätzlichen pst-Dateien

MSOutlook.info – Reminders support for folders in archives and additional pst-files

In Verbindung mit dem MDaemon Email Server samt MDaemon Connector for Outlook und z.B. dem persönlichen und zusätzlich dem Info- oder Support-Postfach haben wir diese Meldung ebenfalls beobachtet. Etwas kurios dabei ist, das der Support von EBERTLANG den Fehler nachstellen konnte, allerdings dennoch (im Gegensatz zu uns) eine Erinnerung erhielt.

Die Angelegenheit wurde an den Hersteller weitergeleitet und man wartet auf Rückmeldung.

Securepoint UTM: Schwierigkeiten beim Versand der Alerting Center-Nachrichten

$
0
0

Das Alerting Center in der Securepoint UTM ist eine feine Sache um über etwaige Probleme unterrichtet zu werden. Wir nutzen dieses Feature sehr gerne sind allerdings bei einem Kunden auf ein Problem gestoßen.

Im Regelfall sollte es so sein, das die UTM an den Unternehmens-eigenen Mailserver (sofern vorhanden) zustellt. Soweit, sogut. Bei Kunden gibt es folgende Konstellation in Sachen Mail-Flow:

Securepoint UTM -> MDaemon - > Weiterleitung zu uns

Das Ganze scheint irgendwie (mal wieder) mit 1&1 Ionos zusammen zu hängen, denn die gleiche Kombi funktioniert mit All-inkl.com ohne Überraschungen. Um es etwas ausführlicher auszudrücken:

Die Securepoint UTM hat als SMTP-Relay den MDaemon Email Server des Kunden konfiguriert. Das macht nicht nur wegen der Alerting Center-Nachrichten Sinn, sondern auch wegen des Spamfilters, wenn Nachrichten aus der Quarantäne zugestellt werden sollen.

Im MDaemon wiederum gibt es einen administrativen Benutzer, der unter anderem Postmaster, etc. ist. Bei diesem ist eine Weiterleitung zu uns eingerichtet. So erhalten wir alle Systrem-relevanten Nachrichten.

Kommt jetzt allerdings eine Nachricht vom Alerting Center der UTM schlägt die Weiterleitung fehl. Die Nachricht landet in der Defekt-Warteschlange mit der Erläuterung

undeliverable forwarded message

Um mehr Informationen zu dieser Meldung zu erfahren ist es hilfreich ins „C:\MDaemon\Logs\MDaemon-<Datum>-SMTP-(abg.).log“ zu schauen. Zum entsprechenden Zeitpunkt findet man z.B. folgende Einträge:

...
Wed 2020-07-15 02:01:59.775: 01: Sending <c:\mdaemon\queues\remote\pd50000017829.msg> to [212.227.15.183]
Wed 2020-07-15 02:01:59.834: 01: Transfer Complete
Wed 2020-07-15 02:01:59.903: 02: <-- 554-Transaction failed
Wed 2020-07-15 02:01:59.903: 02: <-- 554-Reject due to policy restrictions.
Wed 2020-07-15 02:01:59.903: 02: <-- 554 For explanation visit https://www.ionos.com/help/index.php?id=2425&ip=<Eigene IP-Adresse>&c=hd
Wed 2020-07-15 02:01:59.903: 03: --> QUIT
Wed 2020-07-15 02:01:59.905: 01: Dies ist eine weiter- oder umgeleitete Nachricht; sie wird in die Defekt-Warteschlange verschoben.
Wed 2020-07-15 02:01:59.938: 02: <-- 221 kundenserver.de Service closing transmission channel
Wed 2020-07-15 02:01:59.938: 04: SMTP session terminated (Bytes in/out: 5010/43588)

Ruft man die vorgeschlagene URL von 1&1 Ionos auf bekommt man zum Fehlercode 554 gleich mehrere mögliche Ursachen. Für die protokollierte Meldung wäre diese hier die passendste Begründung:

554 Reject due to policy restrictions
Problem:

The email was rejected as it violates IONOS policy. The sending server is mostly sending spam messages.

Solution:

Contact us IONOS to have the facts of the case examined.

Kurzum der Spam-Filter des Providers verhindert den Versand. Wahrscheinlich deswegen, da es sich um eine weitergeleitete Nachricht handelt, die als Absender im Header

From: Alerting-Center [firewall.domain.local] <spalertd@firewall.domain.local>

stehen hat. Leider ist dies in der UTM nicht so ohne weiteres änderbar. Lösen lässt sich in Verbindung mit dem MDaemon Email Server das Problem dadurch, das man die Header-Zeile umschreiben lässt:

  • Auf „Einstellungen – Server-Einstellungen – Kopfzeilen-Umsetzung“ klicken.
  • Im Feld „Bestehender Kopfzeilentext“ die ursprüngliche Angabe der UTM eintragen, z.B. „From: Alerting-Center [firewall.domain.local] <spalertd@firewall.domain.local>“
  • Im Feld „Neuer Kopfzeilentext“ den neuen Absender eintragen, z.B. „From: Administrator <administrator@domain.tld>
  • Auf „Hinzufügen“, „Übernehmen“ und „OK“ klicken.

Ab sofort wird in allen Nachrichten, in denen die betreffende Header-Zeile gefunden wird, diese ersetzt.

Was bei anderen Konstellationen womöglich auch hilft (in diesem Fall allerdings nicht) sind die erweiterten Einstellungen zur Weiterleitung:

  • Das betreffende Benutzerkonto bearbeiten.
  • Zu „Weiterleitung“ wechseln.
  • Im Abschnitt „Erweiterte Einstellungen zur Weiterleitung“ im Feld „Nachrichten an folgende Domäne weiterleiten:“ entweder die Zieldomäne eintragen oder wenn es gezielt an einen Server gehen soll, diesen in eckigen Klammern eintragen.
  • Im Feld „Adresse für SMTP-Umschlag“ die für den Versand zu verwendete E-Mail-Adresse eintragen. An dieser Stelle kann also die etwas ungünstige Altering-Center-Adresse ersetzt werden.
  • Ggf. noch den Port eintragen.

Zum Abschluss noch ein Tipp für bereits in der Defekt-Warteschlange hinterlegten Nachrichten:

  • Die betreffende Nachricht bearbeiten.
  • Die „FROM“-Zeile ändern und speichern.
  • Mit der rechten Maustaste auf die „Defekt-Warteschlange“ klicken und „Jetzt verarbeiten“ auswählen.

Die Nachricht wird zeitnah verarbeitet und im Idealfall, wenn alles passt, auch gleich versendet.

Quelle:

Securepoint – Support-Forum – Smarthost Test ?

MDaemon – Help – Header Translation

1&1 Ionos – Weiterleitung von Mails wird mit „554-Reject due to policy restrictions“ abgelehnt

$
0
0

Da hat einem 1&1 Ionos doch wieder so ein Ei ins Nest gelegt. Neulich erst die Sache mit der Weiterleitung von E-Mails die vom Securepoint UTM Altering Center kommen, was ja noch nachvollziehbar und lösbar war, diesmal mit Mails die von einer USV stammen.

Im Gegensatz zu den Nachrichten von der Securepoint UTM konnte ich in diesem Fall beim besten Willen nicht verstehen bzw. nachvollziehen, was die Montabaur’rer jetzt (wieder) stört. Absender, Empfänger, Date, usw. sowie weiteres was in der zugehörigen „Hilfe“ angegeben ist wurde mehrfach überprüft, testweise sogar umgeschrieben, keine Besserung. Ein Versuch mit dem Versand über einen anderen Provider klappte.

So nebenbei bemerkt, der Mail-Flow sieht wie folgt aus:

USV -> MDaemon Messaging Server -> E-Mail-Konto mit Weiterleitung -> Versand via Smarthost zu 1&1 Ionos

Im SMTP-Log für ausgehende Nachrichten bekommt man dann folgendes zu lesen:

Fri 2020-10-09 11:00:32.777: 02: <-- 554-Transaction failed
Fri 2020-10-09 11:00:32.777: 02: <-- 554-Reject due to policy restrictions.
Fri 2020-10-09 11:00:32.777: 02: <-- 554 For explanation visit https://www.ionos.com/help/index.php?id=2425

Der persönliche Ansprechpartner beim Provider war (wie immer) nicht zu erreichen, die Hotline selbst gab nur folgendes zum Besten:

"Moment, ich schau mal. Bei uns ist alles grün, muss am Kunden liegen."

Das war’s dann auch schon. In diesem Moment dachte ich mir: „Das ist ja wie bei der Deutschen Telekom“.

Jedenfalls konnte es diesmal so gelöst werden, das im betreffenden E-Mail-Konto im MDaemon, bei dem die Weiterleitung eingerichtet ist, die Ziel-Domäne angegeben wurde. D.h. der Mailserver stellt direkt (ohne den Smarthost bzw. 1&1 Ionos) dann die weiterzuleitenden Mails an den Mailserver der Ziel-Domäne zu. Alternativ kann man auch direkt den Ziel-Mailserver angeben, dazu den Namen in eckige Klammern setzen.

Fazit

Ja, wieder „irgendwie“ gelöst, dennoch bleibt die Frage nach dem „Warum?“. Zumal es in der Vergangenheit funktioniert hat. Irgendwas wurde seitens des Providers geändert. Man liest von diesem Problem auch an anderer Stelle im Netz.

Zum Glück sind nur noch drei Kunden bei 1&1 Ionos, der Rest ist schon seit langem bei anderen Providern, wo es diese Schwierigkeiten und vor allem diesen „Service“ nicht gibt.

Quelle:

MDaemon – Weiterleitung

MDaemon: Diskrepanz zwischen lizenzierten und aktuell verwendeten MDaemon Connector-Benutzern

$
0
0

Bei der Neuanlage eines weiteren Benutzers im MDaemon Messaging Server bei einem Kunden fiel auf, das für Diesen die Nutzung des MDaemon Connectors (zur Outlook-Anbindung) nicht aktiviert werden konnte.

Die Anzahl der MDaemon- sowie Outlook-Nutzer ist dabei in gleicher Höhe lizenziert, daran konnte es also nicht liegen. Beispielsweise via

Einstellungen - MDaemon Connector - Benutzerkonten

oder

Rechtsklick auf "MDaemon Connector  - Benutzerkonto bearbeiten - Benutzerkonten"

können die aktuell für die Nutzung des Connectors aktivierten Konten angezeigt werden.

An dieser Stelle wurde dreimal durchgezählt und es ergab sich eine Differenz von fünf Benutzerkonten im Vergleich zur Gesamtanzahl der tatsächlichen MDaemon Connector-Benutzer.

Nachdem über einen der beiden oben genannten Wege das zuvor neu erstellte Benutzerkonto zu den Connector-Benutzern hinzugefügt wurde korrigierte sich von selbst die Anzahl der genutzten Lizenzen.


MDaemon: Die Blacklist eines Benutzers bearbeiten

$
0
0

Aus der MDaemon-Verwaltungsoberfläche heraus lässt sich zwar die Whitelist eines Benutzerkontos bearbeiten, nicht aber die Blacklist. Mit Hilfe eines Text-Editors kann der Administrator auch ohne Zugriff auf das jeweilige Postfach die benutzer-eigene Blacklist anpassen.

Der Pfad zur Blacklist lautet:

LW:\MDaemon\Users\<Domain>\<User>\BlackList.IMAP

In der Datei „AddrBook.mrk“ befinden sich die jeweiligen Einträge. Diese Datei kann einfach mit Notepad geöffnet sowie bearbeitet werden und hat beispielsweise folgenden Inhalt:

<addressBook version="9.5.5" encoding="utf-8" lastModified="2020-01-09T10:03:21.180Z">
<contact>
<guid><![CDATA[597911357aa24a4aa1d884df3f35c8ca]]></guid>
<modified>2020-01-09 11:03:21</modified>
<fullName><![CDATA[Vorname Nachname]]></fullName>
<email><![CDATA[info@HierStehtDieAbsenderDomain.com]]></email>
</contact>
</addressBook>

Pro Blacklist-Eintrag gibt es einen entsprechenden Absatz der von „<contact>“ bis „</contact>“ reicht. Durch Löschen des entsprechenden Absatzes wird der Blacklist-Eintrag entfernt. Nachdem die Änderung gespeichert wurde, greift diese bereits. Ein Dienst-Neustart o.ä. ist nicht notwendig.

Gibt es bereits Nachrichten in der Defekt-Warteschlange, die wegen des Backlist-Eintrags nicht weiterverarbeitet wurden, so können diese nach einem Rechtsklick und der Auswahl von „Verschieben“ in die lokale Warteschlange übergeben werden. Von dort aus werden sie zeitnah (wieder) verarbeitet und zugestellt.

MDaemon: Neustart nach Update vermeiden

$
0
0

Für die Dauer eines Updates müssen beim MDaemon Email Server die Dienste beendet sein, soweit so sinnvoll und nachvollziehbar. Aktualisierungen laufen zudem im Schnitt (und je nach Maschine) sehr schnell durch.

Manchmal kommt es vor, das nach dem erfolgreichen Einspielen eines Updates allerdings nicht die Dienste neugestartet werden (das Feld beim letzten Update-Dialog ist ausgegraut) und stattdessen das Setup einen Neustart des Hosts vornehmen möchte:

Dies kann man vermeiden indem man zum einen den geforderten Neustart nicht durchgeführt und zum anderen die entsprechenden MDaemon-Dienste wieder startet:

Es läuft dann bereits die aktualisierte MDaemon-Version. Den Neustart des Hosts kann man zu einem späteren Zeitpunkt durchführen (lassen).

MDaemon Email Server inkl. Datenübernahme neu installieren

$
0
0

Ein MDaemon Email Server lässt sich schnell und einfach installieren sowie aktualisieren und migrieren. Was aber wenn man einmal neuinstallieren muss und die Daten behalten möchte?

Normalerweise kann der MDaemon-Ordner einfach umkopiert werden und mit wenigen Schritten erneut als Dienst installiert und die Lizenz (re-)aktiviert werden. Anleitungen dazu findet man beispielsweise hier:

Andy’s Blog – Ein paar Notizen zur Migration von MailStore- und MDaemon-Servern

EBERTLANG – Umzug/Migration der MDaemon Installation auf einen neuen Server mit identischem Laufwerksbuchstaben

Möchte man allerdings bewusst die bisherigen Programmdateien nicht übernehmen, so kann man die Konfiguration sowie Nutzdaten wie folgt übernehmen:

  • Zuerst erstellt man eine aktuelle Sicherung der Konfiguration in der Verwaltungsoberfläche unter „Datei – Konfigurationsdateien sichern…“.
  • Sofern der MDaemon auf der gleichen Maschine neuinstalliert werden soll, dann die Dienste beenden und den bisherigen Ordner umbenennen.
  • Einen neuen MDaemon-Ordner anlegen.
  • Die zuvor erstellte Sicherung aus dem Ordner „LW:\<Alter MDaemon>\Backup“ in den neuen Ordner entpacken.
  • Als nächstes den Ordner „LW:\<Alter MDaemon>\Users“ in den neuen Ordner kopieren.
  • Ggf. vorhandene Zertifikate importieren.
  • Das aktuelle MDaemon-Setup herunterladen und die Installation durchführen.
  • Die Installationsroutine erkennt die vorhandene Lizenz und versucht diese zu aktivieren.
  • Leider muss man händisch nochmal die Domain und den Postmaster angeben. Danach kann man, sofern sich sonst nichts weiter wie z.B. Pfade oder die IP-Adresse, etc. geändert haben, den Dienst starten.

Ein weiterer Weg kann sein, den MDaemon Email Server komplett neu zu installieren, den Dienst am Ende der Installation nicht zu starten, die Konfigurationssicherung und den „Users“-Ordner einzuspielen und den Dienst zu starten.

Dieser Beitrag wurde durch die sehr merkwürdigen Verbindungsprobleme bei dem Kunden eines Kollegen (Grüße nach Euskirchen) inspiriert, wo im Zuge der Fehlersuche und der möglichen Lösungswege auch eine Neuinstallation mit Datenübernahme in Erwägung gezogen wurde.

Windows: Eine Anwendung im Benutzerkontext starten, ohne auf den Benutzer Zugriff zu haben

$
0
0

Aus der Reihe „Geschichten aus dem Supporter-Alltag“ heute mal eine Geschichte die mich am vorigen Tag sowie in der Nacht beschäftigt haben.

Dieses Stück in sagen wir mal drei Akten begann damit, das eine Mail ankam, das bei einem Mitarbeiter das Outlook nicht mehr startet. Keine Fehlermeldung oder sonstigen Umstände oder Infos wurden genannt. Als man sich das Ganze ansehen wollte war kein Ansprechpartner inkl. dem betroffenen Mitarbeiter telefonisch zu erreichen, immerhin versuchte man dies den halben Arbeitstag lang. Selbst auf den Vorschlag, das man uns einfach mitteilen soll, wann wir an den PC mal per Fernwartung ran könnten und das Benutzerkennwort in eine Datei auf dem Desktop des Benutzers hinterlegt werden soll (der Administrator kommt da ja dann ran) reagierte man überhaupt nicht.

Eineinhalb Stunden nach Feierabend dann seit Stunden wieder eine Reaktion, man solle sich unbedingt melden, bevor der Mitarbeiter durchdreht. Ach, wie dramatisch. Man ist ja gewillt zu Helfen, nur wenn man nichts genaues weiß und auch nicht ran kommt ist das schwierig. Ich verstehe ja, das da mitunter die Nerven blank liegen, gerade wenn es wichtig ist und man, gerade in der Vorweihnachtszeit, vielleicht gerade einiges los ist. Je nach Branche ist das ja gerade sozusagen Saison. Es müssen allerdings auch alle Beteiligten mitspielen, sonst klappt’s halt nicht so einfach.

Jedenfalls mangels Zugriff auf das Benutzerprofil dann eben als Administrator via RDP am PC angemeldet um zumindest mal die generelle Lage zu prüfen. Es stellte sich heraus, das dies ein Glückstreffer war. Beim Versuch Outlook einzurichten erhielt man eine Fehlermeldung vom MDaemon Connector. Wie ein Blick in die installierten Anwendungen zeigte, wurden an diesem Tag einige Programme installiert (Ja, in diesem Fall kann das der Kunde). Vermutlich hat sich dadurch der Connector bzw. Outlook verabschiedet, genau weiß man es allerdings nicht. Den MDaemon Connector de- und erneut installiert, so war zumindest beim Administrator alles ok, wie aber sieht es nun beim Benutzer aus?

Da das Kennwort immer noch nicht bekannt war musste ein anderer Weg gefunden werden. Eine Möglichkeit bestünde darin das Kennwort zurückzusetzen, das würde aber spätestens am nächsten Morgen weiteren Unmut mit sich bringen.

So kam der Gedanke auf Outlook im Kontext des Benutzers auszuführen. Also kurzerhand eine Aufgabe erstellt, die nur für diesen Benutzer gilt und diese dann ausgeführt:

Via Task-Manager kann dann schonmal sehen, das eine „outlook.exe“ vorhanden ist, soweit ein gutes Zeichen. Im MDaemon Messaging Server an sich kann im „Verbindungen – IMAP“-Tab beobachtet werden, das es eine Verbindung über den Connector mit dem Anwender-Konto gibt, folglich kann man davon ausgehen, das Outlook nun wieder läuft.

Da mittlerweile wieder ein halber Arbeitstag rum ist und ich bis dato keine weitere Reaktion erhalten habe, scheint wohl wirklich alles wieder in Ordnung zu sein. Angenehmer, schneller, einfacher und letztlich auch günstiger (denn Einsätze nach Feierabend kosten extra, wie z.B. beim Handwerker auch) hätte das Ganze laufen können, so gab’s wenigstens was zu erzählen.

Windows: Ist Office und der MDaemon Connector in der 32- oder 64-bit Version installiert?

$
0
0

Im Idealfall lässt sich einfach anhand des Installationsordners erkennen, ob eine Anwendung als 32- oder 64-bit Version vorhanden ist.

So ist die Aufteilung auf einem 64-bit Windows die folgende:

  • „C:\Program Files (x86)“ für 32-bit Programme
  • „C:\Program Files“ für 64-bit Programme

So könnte man einfach beispielsweise via Batch ermitteln, ob ein bestimmtes Programm als 64-bit Ausgabe installiert ist:

if exist "C:\Program Files\...\Sowieso.exe" ...

oder

cd "C:\Program Files"
dir Sowieso.exe /s 
if %errorlevel%==0 ...

Ausgerechnet am Beispiel von Microsoft’s Office ist darauf alleine leider kein Verlass, denn die 32-bit Ausgabe befindet sich dennoch im 64-bit Ordner. „Schuld“ daran ist einmal mehr Click-to-Run (C2R, dt. Klick-und-Los) oder wie man es auch gerne schimpft: Klick-und-Weglaufen.

Bei den Office-Paketen die Outlook enthalten kann man via Registry die Bitness ermitteln. Wenn nicht klar ist, welche Office-Version installiert ist, kann man generell den gesamten Office-Schlüssel durchsuchen:

reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office /s | find /i "Bitness REG_SZ x86"
if %errorlevel%==0 ...

reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office /s | find /i "Bitness REG_SZ x64"
if %errorlevel%==0 ...

Ein Rückgabewert (Errorlevel) mit dem Wert null bedeutet dabei immer gefunden, größer null oder eins entspricht nicht gefunden.

Beim MDaemon Connector ist die Sache einfacher:

rem 32-bit
"C:\Windows\SysWOW64\MDCONNECTOR32X.DLL"

rem 64-bit
"C:\Windows\System32\MDCONNECTOR32X.DLL"

Hier unterscheiden sich lediglich die Pfade.

MDaemon: Wiederherstellen einzelner Elemente oder Ordner

$
0
0

Da wollte ich vor Weihnachten nochmal ein wenig in meinem Outlook aufräumen und löschte doch prompt ein paar Aufgaben, die eigentlich noch erhalten bleiben sollten.

Blöd gelaufen und freilich selbst Schuld, allerdings Zusammen mit dem MDaemon Messaging Server auch kein wirkliches Problem. Wie bereits an anderen Stellen erwähnt speichert der MDaemon die Daten (E-Mails, Termine, Aufgaben, etc.) in Form von *.msg-Dateien im Dateisystem. Folglich ist sowohl eine Datensicherung als auch eine Wiederherstellung extrem einfach, da keine spezielle Groupware-kompatible Software benötigt wird. Bei Exchange Server und Co. sieht das ganz anders aus.

  • Also jedenfalls hab‘ ich Outlook geschlossen und
  • mich kurz per RDP mit unserem Server verbunden,
  • bin zum Ordner „C:\MDaemon\Users\<Domain>\<User>“ navigiert,
  • habe den „Aufgaben.IMAP“-Ordner mit der rechten Maustaste angeklickt und
  • aus den Schattenkopien („Vorgängerversionen wiederherstellen“) die letzte Kopie von gestern geöffnet.
  • Dann beide Ordner-Fenster neben einander platziert,
    schlicht den Inhalt verglichen und
    die fehlenden *.msg-Dateien aus der Kopie zurück kopiert.
  • Einmal Outlook neu gestartet und fertig ist der Lack.

So einfach kann das mit den Schattenkopien sein. Statt einzelner Dateien können so auch ganze Ordner wiederhergestellt werden. Hat man die Schattenkopien nicht konfiguriert oder nicht in Verwendung kann auf die (hoffentlich) vorhandene Datensicherung zurückgegriffen werden und quasi genauso vorgegangen werden.

Wenn man nicht genau weiß was man sucht, kann man die Dateien nach Schlüsselwörtern durchsuchen lassen, da *.msg lediglich Text enthalten. Hilfreich können neben der Windows eigenen Suche die Tools aus folgendem Beitrag sein:

Alternative Datei-Suche für Windows

So sieht beispielsweise eine Suche samt Ergebnis in SearchMyFiles aus:

Als „Base Folder“ kann z.B. auch eine eingehängte Datensicherung dienen.

MDaemon Connector: MDaemon-Konto im Offline-Modus nicht verwenden, alle anderen Konten allerdings schon

$
0
0

Bei der neuen Mitarbeiterin eines Kunden befinden sich im Outlook nicht nur ein MDaemon-Postfach, sondern unter anderem ein POP3-Konto.

Befindet sich die Mitarbeiterin mit ihrem Notebook außer Haus und startet Outlook, erscheint nach kurzer Zeit der Hinweis vom MDaemon Connector das nicht auf das Postfach zugegriffen werden kann und ob man Offline arbeiten möchte.

In diesem Szenario ist es tatsächlich so, das kein Zugriff von Außen auf den MDaemon Email-Server möglich ist, daher bleibt nur das „Offline arbeiten“. In dieser Konstellation hat dieser Modus dann allerdings den Nachteil, das auch POP3- und IMAP-Konten betroffen sind. Da dies nicht gewünscht ist, musste eine kleine Änderung her.

In den Einstellungen der „Senden-Empfangen-Gruppe“ kann man das Verhalten für die Modi geändert werden. Ausgehend von den Outlook-Voreinstellungen gibt es nur eine Gruppe die man bearbeiten kann:

  • Outlook starten.
  • Zur Registerkarte „Senden/Empfangen“ wechseln.
  • Auf „Senden-Empfangen-Gruppen“ klicken“.
  • „Senden-Empfangen-Gruppen definieren“ auswählen.
  • Bei „Im Offlinemodus“ den Haken setzen bei „Automatische Übermittlung alle“.

Die Abfrage beim Start von Outlook bleibt, aber im Offline-Modus funktioniert dennoch das automatische Senden und Empfangen von POP3- und IMAP-Konten aus. Möchte man den Modus wieder wechseln kann man entweder Outlook neu starten oder auf der Registerkarte „Senden/Empfangen“ auf die Schaltfläche „Offline arbeiten“ klicken.


Apple iPhone synchronisiert keine Termine mehr via ActiveSync

$
0
0

Wenn der wie auch immer realisierte Abgleich von Terminen und Co. bei einem mobilen Geräte (Smartphone, Tablet) nicht mehr funktioniert, kann das einige Gründe haben.

Vor ein paar Tagen rief ein Kunde an und meldete, das neuere Termine nicht mehr auf seinem iPhone abgeglichen werden. Ein erster Blick aus der Ferne auf den verwendeten MDaemon Email Server, speziell die Verbindungsstati und das Protokoll von ActiveSync offenbarten zunächst keinerlei Probleme.

Der Dienst ist online, das iPhone aktuell verbunden, soweit keine Spur von Schwierigkeiten. Nach kurzer Rücksprache stellte sich zunächst heraus, das die Firmware auf dem iPhone nicht aktuell war. Der Kunde versprach eine baldige Installation.

Es folgten ein paar Tage Stille bis das wir ein erneutes Telefonats, diesmal wegen eines anderen Anliegens hatten. Auf Nachfrage kam dann heraus, das auch das Update der Firmware nicht möglich war. Kurzum: Beide Probleme, fehlender Abgleich und fehlgeschlagene Update-Installation, hingen damit zusammen, das schlicht kein Speicherplatz mehr auf dem iPhone frei war.

Der Kunde löschte seiner Aussage nach um die 60.000 Bilder und siehe da, alles läuft wieder.

E-Mail: SPF, DKIM und DMARC für Absender einrichten

$
0
0

Um sich vor Spam zu schützen oder selbst nicht auf einer Sperrliste zu gelangen gibt es einige Maßnahmen die man ergreifen kann. Wer eine eigene E-Mail-Domäne verwendet muss in Sachen SPF, DKIM und DMARC selbst Hand anlegen. Am Beispiel der beiden Anbieter Ionos by 1&1 sowie ALL-INKL zeige ich nachfolgend auf an welchen Stellen was einzutragen ist und wie man das Ganze testet.

Die Reihenfolge der einzelnen oben genannten Techniken ist relevant, denn das Eine baut auf dem Anderen auf. Zumindest ist SPF und DKIM Voraussetzung für DMARC.

Ionos by 1&1

Ionos bietet über mehrere Seiten bzw. Stellen hinweg Informationen zu den genannten Techniken (siehe die Links und Quellen am Ende dieses Beitrags). Alle notwendigen Schritte werden im Kundencenter vorgenommen.

SPF

  • Auf „Domains & SSL“ klicken.
  • Bei der gewünschten Domain bei Aktionen (Zahnrad-Symbol) „DNS“ auswählen.
  • Auf „Record hinzufügen“ klicken und „SPF (TXT)“ auswählen.
  • Der „Hostname“ kann so belassen werden. Im Feld „Wert“ folgendes einfügen und speichern:
    v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de ~all

In der Vorschau kann man erkennen, was nun konkret „zusammengebaut“ wird. Ein Beispiel:

meinedomain.de 3600 IN TXT "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de ~all"

Damit ist der SPF-Eintrag gesetzt.

DKIM

Ionos selbst bietet kein Tool an um den Wert des DKIM-Eintrags erzeugen zu können. In der Hilfe verweist man auf den EasyDMARC – DKIM Record Generator. Ironisch mutet dabei folgende Aussage in der Ionos-Hilfe an: „Die meisten E-Mail-Provider nehmen Ihnen diese Arbeit ab.“ Ja, ok, aber dieser Anbieter offenbar nicht.

Als weiteres kommt erschwerend hinzu, das Ionos für die eigenen Mailserver kein DKIM unterstützt, Nutzer die ihre Postfächer direkt dort haben bleiben also außen vor!

Betreibt man einen eigenen Mailserver wie z.B. MDaemon müssen dort die DKIM-Schlüssel erzeugt werden. Im DNS der betreffenden Domäne wird dann der öffentliche DKIM-Schlüssel eingetragen.

  • Auf „Domains & SSL“ klicken.
  • Bei der gewünschten Domain bei Aktionen (Zahnrad-Symbol) „DNS“ auswählen.
  • Auf „Record hinzufügen“ klicken und „TXT“ auswählen.
  • Bei „Hostname“ den Selektor + die Erweiterung „._domainkey“, z.B. „MDaemon._domainkey“ eintragen.
  • Im Feld Wert ist zwingend „v=DKIM1;p=<Öffentlicher Schlüssel>“ einzutragen.
  • Den Record speichern.

DMARC

Auch für die Erzeugung des DMARC-Eintrags bietet Ionos kein eigenes Tool an und verweist auf den EasyDMARC – DMARC Record Generator.

Man macht alle notwendigen und gewünschten Angaben und erzeugt den Wert. Anbei ein Screenshot:

Bei Ionos pflegt man die Daten dann wie folgt ein:

  • Auf „Domains & SSL“ klicken.
  • Bei der gewünschten Domain bei Aktionen (Zahnrad-Symbol) „DNS“ auswählen.
  • Auf „Record hinzufügen“ klicken und „TXT“ auswählen.
  • Bei „Hostname“ „_dmarc“ eintragen.
  • Als Wert die Ausgabe aus dem Generator einfügen.

ALL-INKL

All-inkl macht es einem einfach auf die relevanten Informationen zuzugreifen und diese einzupflegen. Im KAS gibt es den Menüpunkt „Hilfe / FAQ“ über dessen Suchfeld man bequem nach den genannten Techniken suchen kann. Als Ergebnis erhält man Beschreibungen samt Erklärungen sowie Links zu den passenden Stellen. Der Zugriff auf diese Inhalte ist selbstverständlich auch ohne Anmeldung und über die Homepage möglich. Über’s KAS hat man es etwas schneller und einfacher.

SPF

Um den SPF-Eintrag anlegen zu können geht man wie folgt vor:

  • Am KAS anmelden.
  • Auf „Tools – DNS-Einstellungen“ klicken.
  • Die betreffende Domain bearbeiten.
  • Auf „neuen DNS-Eintrag erstellen“ klicken.
  • Bei „Typ“ „SPF (TXT)“ auswählen.
  • Bei „Data“  „v=spf1 mx a ?all“ einfügen.

Das war’s für den SPF dann auch schon.

DKIM

Im Gegensatz zu Ionos kann man bei ALL-INKL für den dortigen Mailserver den DKIM-Schlüssel ganz einfach erzeugen lassen:

  • Im KAS auf „Domain“ klicken.
  • Die betreffende Domain bearbeiten.
  • Bei „DKIM Signierung“ aktiviert auswählen.

Die DKIM-Schlüssel werden erzeugt und man sieht kurze Zeit später in den DNS-Einstellungen der Domain den dazugehörigen Eintrag.

Selbstverständlich kann man auch den öffentlichen DKIM-Schlüssel seines eigenen (lokalen) Mailserver eintragen:

  • Im KAS auf „Tools – DNS-Einstellungen“ klicken.
  • Die betreffende Domain bearbeiten.
  • Auf „neuen DNS-Eintrag erstellen“ klicken.
  • Bei „Typ“ „TXT (DKIM)“ auswählen.
  • Bei „Name“ den Selektor + die Erweiterung „._domainkey“, z.B. „MDaemon._domainkey“ eintragen.
  • Bei „Data“ „v=DKIM1;p=<Öffentlicher Schlüssel>“ einfügen.

DMARC

  • Im KAS auf „Tools – DNS-Einstellungen“ klicken.
  • Die betreffende Domain bearbeiten.
  • Auf „neuen DNS-Eintrag erstellen“ klicken.
  • Bei „Typ“ „TXT “ auswählen.
  • Bei „Hostname“ „_dmarc“ eintragen.
  • Als Wert die Ausgabe aus den im Ionos-Abschnitt genannten Generator einfügen oder das Beispiel von All-inkl für die eigenen Bedürfnisse anpassen:
    v=DMARC1; p=reject; rua=mailto:mail@ihre-domain.de; ruf=mailto:mail@ihre-domain.de; adkim=s; aspf=r

Tests

Zum Testen der neuen Einstellungen kann man auf die Dienste von mxtoolbox.com zurückgreifen. Konkret geht es dabei um die E-Mail-Adresse „ping@tools.mxtoolbox.com“, wo man nach kurzer Zeit einen Bericht per Mail zurückerhält oder diesen auf der Homepage unter

https://mxtoolbox.com/deliverability

abrufen kann. Im Idealfall sieht der relevante Teil des Berichts dann so aus:

Weitere detaillierte Abfragen sind unter

EasyDMARC – SPF Record Lookup

EasyDMARC – DKIM Record Lookup

EasyDMARC – DMARC Record Lookup

möglich. Ein kompletter Bericht unter

EasyDMARC

angefordert werden. Zusätzlich kann man noch den Header der versendeten E-Mails analysieren:

MxToolbox – Email Header Analyzer

Fazit

Ein Allheilmittel gegen Spam oder das man selbst auf einer Blacklist landet sind diese Möglichkeiten nicht. Ein Stück weit mehr Schutz und Sicherheit stellen sie dennoch dar und spätestens wenn bei einem Empfänger den man erreichen muss, die eigenen Mails abgewiesen werden oder im dortigen Spam-Ordner landen sollte man reagieren.

Die gezeigten Werte lassen sich weiter anpassen, siehe dazu die nachfolgenden Links und Quellen. Persönlich finde ich macht es einem Ionos by 1&1 etwas schwieriger, ALL-INKL bringt das Ganze schneller und übersichtlicher auf den Punkt. Funktionieren tut es letztlich bei beiden.

Links und Quellen:

Ionos – SPF-Record verstehen und anwenden

Fehler in der Dokumentation:

„ping.tools.mxtoolbox.com“ ist definitiv keine E-Mail-Adresse, sondern eine URL. Offenbar wurde der erste Punkt und das @ vertauscht. Die richtige E-Mail-Adresse lautet also: „ping@tools.mxtoolbox.com“.

Ionos – Spam-Versand vermeiden mit SPF-Record

Ionos – DKIM (DomainKeys Identified Mail) einrichten für eine bessere E-Mail-Zustellbarkeit

rapidmail – DKIM-Key für IONOS erstellen – So geht´s!

Global Cyber Alliance – DKIM setup for 1&1 Ionos

Ionos – DMARC: Missbrauch der Mail-Domäne rechtzeitig erkennen

ALL-INKL – DNS-Werkzeuge: SPF

ALL-INKL – DNS-Werkzeuge: DKIM (bei Versand über unsere Mailserver)

ALL-INKL – DNS-Werkzeuge: DKIM (bei Versand über externe Mailserver)

ALL-INKL – DNS-Werkzeuge: DMARC

Windows: base64-Daten erzeugen oder lesen

$
0
0

Es gibt einige Stellen wo base64-Daten zum Einsatz kommen, die bekannteste ist wohl die gute alte E-Mail.

Um eben mal schnell Daten von oder zum base64-Format zu bringen gibt es zahlreiche Tools und Hilfsmittel, eines davon ist das gleichnamige portable Tool Base64 von Samuel Lucas.

  • Einfach herunterladen und ausführen.
  • Im oberen Feld den Text einfügen und anschließend über die gewünschte Schaltfläche de-/kodieren.

Persönlich nutze ich dieses Tool recht gerne um base64-kodierte E-Mails die z.B. in der Defekt- oder Quarantäne-Warteschlange des MDaemon Email Servers sind lesen zu können, ohne gleich auf ein E-Mail-Programm wie Outlook zurückgreifen zu müssen.

MDaemon: Antivirus aktualisiert nicht (mehr)

$
0
0

Unter Umständen kommt es vor, das die automatische Aktualisierung der Virenschutz-Pattern/-Signaturen unter MDaemon Email Server nicht mehr funktioniert.

Ein Grund, bei Einsatzes von MDaemon AntiVirus, kann eine abgelaufene Lizenz oder fehlerhafte Aktivierung sein. Ein weiterer Grund kann ein nicht-vorhandener oder fehlerhafter Zeitplan sein.

Den aktuellen Stand der Signaturen kann man unter „Sicherheit – AntiVirus – AntiVirus – AV-Aktualisierung“ einsehen:

Ein manuelles Aktualisieren, die Ergebnisse der Aktualisierung sowie den Zeitplan kann man über die entsprechend beschrifteten Schalflächen einsehen. Funktioniert die Aktualisierung trotz eines vorhandenen Zeitplans nicht, dann diesen Löschen und neu erstellen:

MDaemon: Kein ActiveSync mehr seit der Windows Updates vom März’21?

$
0
0

Die Windows Update vom März 2021 sorgen weiter für Ungemach, zwar hauptsächlich in Sachen Drucker oder Druckvorschau, aber manchmal gibt es noch weitere „Kollateralschäden“.

Bei einem recht neuem Kunden der seine IT selbst verwaltet und seit langem den MDaemon Email Server auf einem Quasi-Server unter Windows 10 Pro verwendet streikte ActiveSync seit dem Patchday.

Ein näherer Blick zeigte, dass das Problem weit- und tiefergehender ist. Beim ersten Verbindungstest via Browser und URL (ganz gleich ob via Internet oder lokal) fiel zunächst auf, das auf die https-Anfrage sogar mit dem richtigen Let’s Encrypt-Zertifikat geantwortet wird, aber dann kam gleich ein „404 Not Found“.

Beide URLs, sprich die zum Webmail (aka WorldClient)

https://<fqdn>

und die zu ActiveSync

https://<fqdn>/Microsoft-Server-ActiveSync

zeigten diesen Fehler.

Die entsprechenden Teile im MDaemon, sprich Webmail und ActiveSync, sind aktiv. Seltsam. Also mit NirSoft’s CurrPorts mal die Port-Belegung angeschaut („netstat -ano“ geht natürlich auch, CurrPorts finde ich persönlich hübscher, zumal man die zugehörigen Prozesse gleich mit aufgelistet bekommt) und da sah man dann, das der Port 443/tcp mehrfach belegt ist.

Da gab es die gewollten Bindungen durch die „WorldClient.exe“, das ist der Webserver des MDaemon für Webmail und ActiveSync, aber auch Bindungen auf „SYSTEM“ mit der PID „4“. Nach der Änderung von Port 443/tcp auf eine andere Nummer konnte der MDaemon-eigene Webserver wieder erreicht werden, die „SYSTEM-Bindung“ blieb allerdings bestehen.

Der erste Gedanke meinerseits in solchen Situationen ist immer: Da läuft bestimmt ein IIS, also der Webserver von Microsoft. Ein Blick in die Dienste-Liste sorgte allerdings für Ernüchterung, da der „WWW-Publishingdienst“ zwar installiert aber nicht gestartet und sogar deaktiviert ist.

Komisch ist zudem, das sozusagen ab Werk der IIS nicht einfach eine Bindung zu 443/tcp für https mit auch noch dem „richtigen“ Zertifikat von selbst macht. Als vorläufigen Workaround wurde zunächst im Firewall-Router des Kunden die Port-Weiterleitung geändert, damit ActiveSync erstmal wieder läuft. Die Abklärung zu diesem Port-Konflikt sollte später erfolgen.

Bei einem weiteren Termin wurde dann zusammen mit dem Support von EBERTLANG danach geschaut. Der IIS ist zwar installiert, wird allerdings nur für FTP genutzt, wie bereits erwähnt ist der WWW-Dienst deaktiviert. Zur Sicherheit wurden dennoch die Bindungen überprüft, dort war allerdings nichts in Richtung 443 vorhanden.

Interessant wurde es dann in der Eingabeaufforderung: Nach Absetzen des Befehls

net stop http

und dem Bestätigen das abhängige Dienst beendet werden dürften kam soweit erstmal die Bestätigung der jeweiligen Dienste-Stops:

Die folgenden Dienste hängen vom Dienst HTTP-Dienst ab.
Das Beenden des Dienstes HTTP-Dienst beendet auch diese Dienste.

UPnP-Gerätehost
SSDP-Suche
Druckwarteschlange
Routing und RAS
Funktionssuche-Ressourcenveröffentlichung

Möchten Sie diesen Vorgang fortsetzen? (J/N) [N]: J
UPnP-Gerätehost wird beendet.
UPnP-Gerätehost wurde erfolgreich beendet.

SSDP-Suche wird beendet.
SSDP-Suche wurde erfolgreich beendet.

Druckwarteschlange wird beendet.
Druckwarteschlange wurde erfolgreich beendet.

Routing und RAS wird beendet..
Routing und RAS wurde erfolgreich beendet.

Funktionssuche-Ressourcenveröffentlichung wird beendet.
Funktionssuche-Ressourcenveröffentlichung wurde erfolgreich beendet.

Systemfehler 1051 aufgetreten.

Ein Stoppzeichen wurde an einen Dienst gesendet, von dem andere Dienste abhängen.

Denn Fehler am Ende ignorieren wir jetzt einfach mal. Anschließend wurde Dienst für Dienst wieder gestartet und dazwischen beobachtet, ob der Port 443 wieder irgendwie belegt ist. Kurzum: Der Übeltäter ist „Routing und RAS“ (RRAS). Warum dieser den Port belegt konnten wir nicht klären. Da bislang nach der Beendigung dieses Dienstes keine Probleme auftraten haben wir ihn auf „Deaktiviert“ gesetzt.

So ganz zufrieden bin ich mit dieser Lösung nicht, konnte allerdings bislang leider noch ermitteln was da genau passiert. Ganz unbekannt sind diverse Probleme in dieser Richtung wohl nicht:

superuser  Why is the ‚System‘ process listening on port 443?

Vielleicht ergibt sich ja noch etwas. Jedenfalls danke ich an dieser Stelle dem Support von EBERTLANG für die tolle Unterstützung.

Viewing all 95 articles
Browse latest View live