EuropeanMX

FAQ - Häufig gestellte Fragen

Technisch gesehen kann EuropeanMX auf die E-Mail-Daten zugreifen. Jedoch speichern wir (davon ausgehend, dass keine Archivierung aktiv ist) keine Kopien gültiger Nachrichten, sofern der empfangende Mailserver erreichbar ist und die Nachricht annimmt.

Weiter wird der gesamte E-Mail-Traffic von und zu unserem System per TLS verschlüsselt, sofern dies vom empfangenden bzw. absendenden Mailserver unterstützt wird.

Der User erhält tägliche Reports über verdächtige und aussortierte eingehende Nachrichten.

Bei ausgehenden Mails kann der Benutzer über die Logs im Webinterface prüfen, ob Nachrichten nicht versendet wurden.

Unsere Email-Security-Cloud Filtering Server stehen aufgrund bestmöglicher Verfügbarkeit und Skalierbarkeit in verschiedenen Ländern. Das bedeutet, dass wir zwar Server mit dem Standort Deutschland betreiben, Logging / Spam Daten jedoch nicht ausschließlich in Deutschland vorgehalten werden.

Die Filterung von E-Mails basiert auf verschiedensten Methoden, z.B. Inhalts-Check, URL-Check, ausgewählte DNSBL-Check, Header-Check, Sender-Check. Eine Absender-Adresse, von der einmalig eine Spam-Nachricht versendet wurde, wird nicht automatisch komplett geblockt.

Unser Filterungssystem unterstützt alle Verbindungen, die mit SSL/TLS verschlüsselt werden können. Sofern der Zielserver die verschlüsselte Nachricht empfangen kann wird die Nachricht standardmäßig mittels TLS verschlüsselt.

Die Filterungsmethoden und das EuropeanMX-System wurde speziell dazu entworfen, um "False-Positives"-Nachrichten zu vermeiden. Um Fehler aufgrund einer einzelenen Klassifizierung zu vermeiden, werden eine große Menge verschiedener Prüfungen durchgeführt. Grundsätzlich kann man die Prüfung in 2 Ebenen unterteilen: die SMTP-Ebene und die DATA-Ebene. Dank der Kombination aus vielen verschiedenen Filtersystemen und der Einhaltung der RFC-Richtlinien, die besagt wie eine Verbindung behandelt wird, können wir sicherstellen, dass eine Nachricht niemals verschwinden kann. Der Absender wird immer von dessen Mailserver informiert, sofern eine Nachricht abgelehnt bzw. geblockt und in die Quarantäne verschoben wurde.

SMTP-Ebene:
So oft wie möglich versuchen wir eine Nachricht nicht nach dem "rcpt to:"-SMTP-Kommando zu blockieren. Auf diese Weise kann sicher gestellt werden, dass alle Verbindungen die Empfängerdomain betreffend ordnungsgemäß auf dem Protokollserver gespeichert werden. Dies kann helfen, den Überblick über die Verbindungen zum Empfängerkonto zu bewahren. Bevor die DATA-Ebene erreicht werden noch verschiedene andere Dinge überprüft (z. B. ob die Verbindungsstandards gemäß RFC eingehalten wurden, der Server auf keiner internen und/oder externen Blacklist eingetragen ist, etc.). Wenn die Verbindung von einem unbekannten Server aus aufgebaut wird, der bis jetzt noch keine gute Reputation in unserem System hat, kann es sein, dass die Nachricht vorrübergehend mit einem 4xx-Code abgewiesen wird. In diesem Fall wird der absendende Server die Nachricht in die Warteschlange setzen und versuchen diese erneut zuzustellen. Nach 10 Minuten wird die Verbindung zu unserem Netzwerk akzeptiert und die interne Whitelist angepasst, damit Verzögerungen zukünftig vermieden werden können. Dieses Konzept ist allgemein bekannt als "greylisting". Allerdings ist unser Konzept im Gegensatz zum traditionellen "Greylisting" um ein vielfaches ausgereifter. Alle Serverknoten werden miteinander synchronisiert und es werden nur Verbindungen geblockt, die dem EuropeanMX-Netzwerk unbekannt sind. Deshalb sind Verzögerungen aufgrund von "Greylisting" innerhalb eines Filter-Clusters sehr ungewöhnlich und führt in der Regel bei Empfängern zu keinen Problemen.

Wenn die Verbindung von einer Spam-Quelle aufgebaut wird, kann es öfters vorkommen, dass die Nachricht temporär mit einem 4xx-Code abgelehnt wird. Auf diese Weise geht, selbst wenn der Server fälschlicherweise als Spam-Quelle gelistet wurde (z.B. auf einer externen Blacklist) oder das Spamproblem auf dem absendenen Server gelöst wurde, die Nachricht nicht verloren und wird an den finalen Empfänger weitergeleitet. Hiervon ausgenommen sind Verbindungen, die von einer bekannten Quelle stammen, die ausschließlich für den Versand von Spam verwendet wird oder bei der das Verhalten nicht dem RFC-Standard entspricht. Hier kann es sein, dass die Verbindung dauerhaft mit einem 5xx-Fehler abgewiesen wird. Wenn dies jemals mit einem legitimen Absender geschehen sollte, erhält der Absender immer eine Bounce-Benachrichtigung von seinem Mailserver. Dieses Problem geschieht nur, wenn es ernsthafte Probleme mit dem absendenden Server gibt. Dieses Problem muss dann auf Absender-Seite untersucht werden.

DATA-Ebene:
Nachdem die DATA-Ebene erreicht wurde, wird der Inhalt der Nachricht basierend auf einer Kombination aus erweiterten statistischen Filtertechnologien, Spam-Fingerabdrucksdatenbanken, Viren-, Phishing- und Spyware-Datenbanken, untersucht. Wenn eine Nachricht als Spam erkannt wird, dann wird diese, abhängig vom erreichten Score, entweder temporär abgewiesen (4xx-Fehler) oder dauerhaft abgewiesen (5xx-Fehler). Eine Nachricht die permanent abgelehnt wird wird vom Filter in die Quarantäne verschoben und kann von dort freigegeben werden (außer bei Viren). Im Falle das eine legitime Nachricht dauerhaft geblockt wird, wird der Absender immer vom absendenden Mailserver informiert, dass die Nachricht nicht zugestellt werden konnte.

Grafische Veranschaulichung:
Hier haben wir Ihnen unser Filtersystem nochmal grafisch aufbereitet: https://europeanmx.eu/assets/img/europeanmx_filtering_technologies_diagram.png

Normalerweise werden Nachrichten direkt an den Zielserver geliefert und werden nicht auf dem filternden Server gespeichert. Wenn der Zielserver allerdings nicht erreichbar ist werden alle Nachrichten, die an bekannte Empfänger gesendet wurden, in einer Warteschlange auf dem filterenden Server gespeichert. Nachrichten, die dauerhaft vom Zielserver mit einem 5xx-Fehler abgewiesen werden, werden nicht in der Warteschlange gespeichert und werden vom System abgewiesen. Hier finden Sie eine Liste mit den SMTP-Fehlern:

500 - The server could not recognize the command due to a syntax error.
501 - A syntax error was encountered in command parameters or arguments.
502 - This command is not implemented.
503 - The server has encountered a bad sequence of commands.
504 - A command parameter is not implemented.
550 - No mailbox by that name is currently available (ex. because it was not found, or because the command was rejected due to policy reasons, such as a full mailbox. Please clear the callout cache after the mailbox has been emptied).
551 - The recipient is not local to the server. The server then gives a forward address to try.
552 - The action was aborted due to exceeded storage allocation.
553 - The command was aborted because the mailbox name is invalid.
554 - The transaction failed. Blame it on the weather.

Wenn der Zielmailserver die "Catch-All"-Funktion nutzt, werden keine Empfänger gespeichert, weswegen die Nachrichten nur in der Wartschlange gespeichert werden, wenn der gültige Empfänger als lokaler Empfänger im EuropeanMX Control-Panel angelegt wurde.


Zugang Warteschlange:
Sie können über das Webinterface auf die Warteschlange zugreifen und von dort aus gespeicherte Nachrichten erneut versuchen zu versenden.


Plan für die automatischen Zustellungsversuche:
Nachrichten für unserem System bekannte Adressen werden, im Falle einer Nichterreichbarkeit des empfangenden Mailservers, anhand der nachfolgenden Intervalle nochmals weitergeleitet:

- In den ersten 2 Stunden nach Erhalt der Nachricht versucht das System alle 15 Minuten die Nachricht zuzustellen.
- Während der darauffolgenden 14 Stunden erfolgt der Zustellversuch zu einem variablen Intervall mit dem Faktor 1,5. Der erste Versuch erfolgt nach 15 Minuten, der zweite Versuch dann nach 22,5 Minuten, der dritte Versuch dann nach weiteren 34 Minuten usw.
- 16 Stunden nach dem ursprünglichen Erhalt der Nachricht im EuropeanMX Filter wird dann, bis 4 Tage nach Eingang der Nachricht, alle 6 Stunden versucht die Nachricht zuzustellen.
- Ist die Zustellung nach 4 Tagen weiterhin nicht möglich, generiert das System eine Fehlermeldung (bounce message) an den absendenden Mailserver.

Wenn eine Nachricht eingefroren wird (Nachricht kann weder an den Empfänger zugestellt noch dem Absender zurück gesendet werden), dann werden keine automatischen Zustellungsversuche mehr unternommen. Ein Super-Administrator hat dann die Möglichkeit die Zustellung der Nachricht, sofern das Problem gelöst wurde, erneut anzustoßen.

EuropeanMX speichert gültige Empfänger bis zu 4 Tage. Wenn die Einträge abgelaufen sind, speichert EuropeanMX Nachrichten für diesen Empfänger nicht mehr, sondern weist die Nachrichten vorübergehen ab, so dass die Nachrichten auf dem absendenden Mailserver gespeichert werden. In solchen Fällen wird der erneute Zustellungsversuch vom absendenden Mailserver durchgeführt. Wenn Sie das "lokale Empfänger"-Feature (bei Catch-All-Funktion) nutzen, dann wird die Speicherung der Empfänger umgangen und EuropeanMX akzeptiert und speichert alle Nachrichten für angelegte lokale Empfänger in der Warteschlange.


Nachrichten in der Warteschlange:
Gemäß der SMTP RFC 5321-Richtlinien ist der absendende Server verpflichtet, Nachrichten, die aufgrund eines temporären Fehlers auf Empfängerseite nicht direkt an den Empfänger zugestellt werden können, in einer Warteschlange zu speichern. Deswegen werden Nachrichten, im Falle eines temporären Problems der E-Mail-Infrastruktur, nicht sofort abgewiesen (gebounced), sondern auf Absenderseite gespeichert und automatisch versucht erneut zuzustellen. Falls der empfangende Mailserver nicht erreichbar ist, werden nur Nachrichten akzeptiert, die in unserem System als gültig bekannt sind. Gültige Empfänger werden immer für 96 Stunden gespeichert.

Wenn ein Zielserver nach 4 Tagen nicht mehr erreicht werden kann, werden alle Nachrichten nach 4 Tagen abgewiesen (gebounced) und weitere E-Mails nicht mehr akzeptiert/in der Warteschlange gespeichert, bis dieser wieder erreichbar ist. Diese 4 tägige Frist ist konform mit den Richtlinien nach SMTP RFC. Der Grund, warum Nachrichten nicht länger gespeichert werden, liegt darin, dass es für den Absender wichtig ist zu erfahren, dass die Nachricht nicht zugestellt werden konnte und er sich ggf. mit dem Empfänger in Verbindung setzen kann.


Ihre eigenen Fallback-Server:
Bitte beachten Sie, für den Fall dass Sie mehrere Zielrouzten spezifizieren, kann das EuropeanMX-System annehmen, dass Sie Ihre eigenees Fallback-System verwenden. Wenn der spezifizierte Fallback-Server für Empfänger-Callouts nicht erreichbar ist, dann wird intern keine Datenbank mit den gültigen Empfängern angelegt. Wir würden Ihnen nicht empfehlen, einen oder mehrere Fallback-Server einzutragen, es sei denn, Sie haben eine spezielle Infrastruktur, um Ausfälle des Zielservers zu verarbeiten.


Fehlerbehebung bei Nachrichten in der Warteschlange:
Wenn Nachrichten in der Warteschlange gespeichert werden, dann passiert das grundsätzlich weil die Einlieferung der Nachricht auf dem Zielserver fehlgeschlagen ist. Um das Problem zu untersuchen gehen Sie wie folgt vor:

- Vergewissern Sie sich, dass die Route zum Zielserver korrekt eingerichtet ist. (Bitte stellen Sie auch sicher, dass Sie nicht mehrere Routen verwenden. Normalerweise sollte nur eine Route angelegt sein)
- Prüfen Sie die Logdateien auf Ihrem Zielserver, um mehr über den Grund zu erfahren, warum die Zustellungsversuche abgewiesen wurden.
- Führen Sie einen Telnet-Test durch, um die Antwort Ihres Mailserver zu prüfen.
- Wenn das Problem nach den durchgeführten Schritten immernoch besteht, kontaktieren Sie bitte unseren EuropeanMX-Support und lassen Sie uns alle nötigen Informationen und Beispiele zukommen.

Wir verwenden eine erweiterte Form des "Greylistings", um eine signifikante Menge an Spam mit minimalen Ressourcenverbrauch zu verhindern. Obwohl "Greylisting" eine umstrittene Technologie ist, ist es immer noch sehr wirksam, wenn sie richtig angewendet wird.

Zunächst ist es wichtig zu erwähnen, dass alle Knoten im Servercluster synchronisiert werden und Kenntnis über die Verbindungen zueinander haben. Deswegen ist es für die "Greylisting"-Technologie egal, zu welchem Knoten die Verbindung aufgebaut wird. Des Weiteren merken wir uns seriöse Hosts, um eine Verzögerung aufgrund von "Greylisting" bei zulässigen Servern zu vermeiden.

"Greylisting" basiert auf den "Triplet"-Informationen bestehend aus "Sending Server IP/24 subnet", "Sender Email Adress" and "Recipient Email Adress". Immer wenn wir eine Nachricht von einem unbekannten "Triplet" erhalten, wird diese temporär für 10 Minuten nach dem ersten Zustellungsversuch abgewiesen (SMTP 4xx-Fehler). Eine temporär abgewiesene E-Mail bedeutet, dass der absendende Mailserver aufgefordert wird die Nachricht in einer Warteschlange zu speichern und die Zustellung zu einem späteren Zeitpunkt erneut zu versuchen. Jeder ordnungsgemäße Mailserver ist gemäß RFC verpflichtet diese Methode zu unterstützen. Das ist ein völlig automatisierter Prozess bei dem der Absender keine Benachrichtigung erhält. Es ist egal, ob die Nachricht innerhalb dieses 10-minütigen Intervalls die Nachricht nochmal versendet oder an einen anderen Knoten gesendet wird, da die erneute Zustellung erst nach 10 Minuten von unseren Server akzeptiert wird. Resultierend daraus ergibt sich ein kleine Verzögerung, weswegen wir ein erweitertes System nutzen, um solche Verzögerungen zu vermeiden. Nachdem die Nachricht vom zunächst unbekannten "Triplet" akzeptiert wurde, wird das Triplet "weiß", damit zukünftige "Triplets" nicht mehr temporär abgewiesen werden. Des Weiteren immer wenn wir mindestens 5 verschiedene, erfolgreiche, "weiße" "Triplets" sehen, die von der selben IP / 24 Subnet stammen oder mindestens 2 verschiedene, erfolgreiche, "weiße" "Triplets", die vom selben Subnetz und gleicher Absenderadresse stammen, wird das Subnetz oder das Subnetz+Adresse zu einer internen "Greylisting Whitelist" hinzugefügt, um "Greylisting"-Verbindungen von der gleichen IP zu vermeiden. Alle aktiven Mailserver, die eine Nachricht bei unseren Server einliefern, sind deshalb nicht von der "Greylisting"-Technologie betroffen, da diese Mailserver auf einer internen "Greylisting Whitelist" eingetragen sind. Das "Greylisting"-Verfahren kommt nur bei unbekannten Servern zu tragen. Ein Server, der vorrübergehend auf einer Blacklist gelandet ist, verliert den Whitelist-Eintrag wieder, weswegen dieser bei neuen Verbindungen "greylisted" wird.

- "Greylisted Triplets" werden nach 10 Minuten als "weiß" eingestuft
- IP-Subnetze werden nach 5 "weißen Triplets" auf die "Greylisting Whitelist" gesetzt.
- IP-Subnetze+Absenderadresse werden nach 2 "weißen" Subnetz+Adress-Paaren auf die "Greylisting Whitelist" gesetzt.
- "graue" Einträge in der "Greylist" laufen nach 8 Stunden ab
- "weiße" Einträge in der "Greylist" laufen nach 60 Tagen ab (sofern keine Verbindung mehr aufgebaut wurde)
- "Greylist Triplets" werden nur für bestimmte Empfängerdomains verwendet; "Greylisting Whitelist" wird für alle Domains im Cluster geteilt.

Bitte beachten Sie: Die meisten Supportfragen bezüglich temporär abgewiesener Verbindungen bestehen, da viele Kunden nur den Eintrag im Log sehen, dass die Nachricht temporär abgewiesen wurde und sich nicht bewusst sind, dass dies nicht bedeutet, dass die Nachricht geblockt bzw. als Spam identifiziert wurde. Die Nachricht wurde nur kurz verzögert, um zu verifizieren, dass der absendende Server sich korrekt verhält (in Übereinstimmung mit den Anforderungen für SMTP-Server).

Bitte beachten Sie: die sendende Server-IP / 24 Subnet ist im Grunde der erste Teil der IP-Adresse des sendenden Servers. Z. B. wenn ein Server die IP 222.153.243.117 besitzt, dann ist die Zeichenkette, die im "Triplet" genutzt wird, 222.153.243. Dies beinhaltet bis zu 256 (.0 - .255) Server, meistens innerhalb der gleichen Organisation. Das bedeutet, dass falls eine Organisation mehrere absendende Mailserver verwendet (typischerweise im gleichen Subnet), ist es egal, von welchem Server der zweite Zustellungsversuch unternommen wird.

Mehr Informationen über RFC und "Greylisting" kann in Sektion 5.3.1.1 im RFC1123 gefunden werden.

Prüfschritte vor dem Virenscan

Da Viren in der Regel versuchen, sich als Spam-E-Mails zu verbreiten, werden die meisten E-Mail-Viren aufgrund unserer Anti-Spam-Technologien bereits vor dem Scannen mit unserer Antiviren-Engine blockiert. Dank dieser ressourcenschonenden und intuitiven Einrichtung werden selbst Viren, die Virenscanner noch nicht kennen, in der Regel sicher unter Quarantäne gestellt oder gänzlich abgewiesen.

Antivirus-Engine

Als zusätzliche Maßnahme betreiben wir das Open-Source-Antivirus-Framework ClamAV, dessen Virendefinitionen alle 30 Minuten aktualisiert werden. Neben den ClamAV-Datenbanken haben wir weitere auf E-Mail-Viren-Probleme spezialisierte Datensätze von mehreren externen Partnern hinzugefügt, um einen optimalen Echtzeitschutz vor den neuesten Virenausbrüchen zu gewährleisten. Unsere internen Reputationssysteme tragen auch zur Virenprüfung bei und gewährleisten einen optimalen Schutz vor Spam, aber auch vor Malware, Phishing und Viren.

Wir evaluieren regelmäßig verschiedene kommerzielle Antiviren-Engines und analysieren falsche Negative, um festzustellen, ob andere Engines diese blockieren konnten. Leider fangen die meisten kommerziellen Antiviren-Engines E-Mail-Viren erst nach ihrer Zustellung ab und bieten daher keine zusätzliche Sicherheit auf SMTP-Gateway-Ebene. Es bleibt immer wichtig, Antivirenprogramme auch auf dem Endpunkt auszuführen, da dadurch später auf die Nachricht zugegriffen wird und Antivirenanbieter mehr Zeit haben, ihre Signaturen zu aktualisieren.

Sandboxen

Wir analysieren aktiv Viren-E-Mails, um unsere Erkennung kontinuierlich zu verbessern und Zero-Day-Viren zu fangen. Sandboxing wird in unseren Umgebungen dafür eingesetzt, wir integrieren jedoch kein Echtzeit-Sandboxing in unsere Scanprozesse. Oftmals werben die Anbieter mit solchen Technologien, aber es gibt praktisch kein gutes Sandboxing-System, das zur Effektivität beim Scannen von SMTP-Gateways in Echtzeit beiträgt. Beim Umschreiben von URLs, die auf eine Sandbox-Umgebung verweisen, führen Sie eine "Scan-Verzögerung" ein, da die URL erneut gescannt werden kann, wenn der Benutzer versucht, darauf zuzugreifen, und daher besteht die Möglichkeit, dass die kommerzielle Antiviren-Engine bis dahin eine Signatur dafür hat. Unsere Engine wird jedoch niemals den Inhalt der E-Mail verändern, da dies DKIM beschädigen würde und zu Korruption von Nachrichten führen kann. URL-Rewriting/Filtering sollte direkt am Endpunkt durchgeführt werden, um die URL vor solchen Bedrohungen zu schützen.

Was ist Spam?
Als Spam oder Junk (englisch für ‚Abfall‘ oder ‚Plunder‘) werden unerwünschte, in der Regel auf elektronischem Weg übertragene Nachrichten bezeichnet, die dem Empfänger unverlangt zugestellt werden und häufig werbenden Inhalt enthalten. Dieser Vorgang wird Spamming oder Spammen genannt, der Verursacher Spammer. Die häufigste Form von Spam sind E-Mails, allerdings ist das Problem nicht nur auf diese beschränkt. Spam kommt mittlerweile auch häufig in Form von Nachrichten in Instant-Messengern (z. B. MSN, ICQ, GTALK oder auch im Skype-Chat), SMS, Einträgen in Online-Foren, Einträgen in Blogs, Einträgen in sozialen Netzwerken (z. B. Facebook, MySpace & Twitter) und auf die alt bekannte Weise per Post oder Fax, vor. Genau genommen, können Sie auf jedem Weg Spam erhalten auf dem Sie auch kontaktiert werden können.


Warum senden Spammer Spam?
In einem Wort?...Geld! Fast ohne Kosten bzw. nur geringe, können Spammer Nachrichten an mehrere hunderte Millionen Menschen senden. Alles was sie benötigen, um glücklich zu sein, sind ein oder zwei Personen von geschätzten 1000 versendeten Nachrichten, die entweder auf deren Link klicken und ein Produkt kaufen oder noch schlechter persönliche Daten herausgeben.

Mit verbesserter Technologie und einer steigenden Anzahl an Menschen, die über einen Internetzugang verfügen, werden Spamnachrichten oder unerwünschte Massennachrichten meistens als Medium für die Begehung von Straftaten (unter anderem Wirtschaftskriminalität, Bankenbetrug, Kreditkartenbetrug oder Identitätsdiebstahl) verwendet.

Spam kann auch als Sprungbrett dienen, um unauthorisiert Zugriff auf Ihren Computer oder Ihren Server zu erhalten. Dann kann der Angreifer z.B. Nachrichten mit einem bösartigen Link versenden, der auf eine Webseite weiterleitet, die in der Regel vom Spammer, mit dem alleinigen Zweck des Herunterladens von bösartigen Material auf den Computer des Benutzers, gehostet wird. Normalerweise werden Malware und Viren dazu verwendet, um ein Botnetz zu schaffen und mit der Kontrolle über eine große Anzahl von Computern weitere Spamnachrichten und bösartiges Material zu verschicken.


Wer steckt hinter dem Spam?
Es gibt verschiedene Arten von Spammern. Beginnend mit einer einzigen Person, die eine E-Mail-Liste von einem Dritten erwirbt bis hin zu einer Gruppe von gesetzwidrigen Vollzeit-Spammern, die auf verschiedene Länder verteilt sind, um so 24 Stunden am Tag unerwünschte Nachrichten an hunderte Millionen von Menschen zu senden.


ROKSO:
Das ROSKO ("Register of Known Spam Operations") ist eine Übersicht, die Anbieter von Spamdiensten und Absendern auflistet, bei denen mehrere eindeutige Spamverbindungen festgestellt wurden.

Spamhaus (eine gemeinnützige Organisation, die Internet-Spam-Operationen aufzeichnet) ist der Ansicht, dass die auf der Liste genannten Personen für etwa 80% des Spams im Internet verantwortlich sind.

Mehr Informationen können Sie unter http://www.spamhaus.org/rokso/index.lasso finden.

Es werden keine Ihrer erwünschten E-Mails auf einem unserer Server gespeichert, außer der Zielmailserver ist nicht erreichbar. Sämtliche Daten aus Archivierung, Protokollierung und der Quarantäne werden explizit auf Servern innerhalb der EU gespeichert.

Einzelne Keywords können leider nicht geblockt werden. Aber das Trainieren ungeblockter Spamnachrichten löst in der Regel das Problem. Durch das Trainieren wird die Klassifikation, die der Filter für eine Nachricht vorgenommen hat, korrigiert. Dies hilft uns ähnliche Nachrichten in Zukunft als Spam zu erkennen und zu blockieren.

Im Control Panel von EuropeanMX verwenden wir verschiedene Klassifizierungen, um zu beschreiben, warum eine Nachricht abgelehnt oder vorübergehend abgelehnt wurde.

Temporarily rejected (4xx SMTP Antwort)

- Temporarily rejected

Zeitweilig abgelehnte Nachrichten bleiben auf dem absendenden Mailserver gespeichert. Legitime Mailserver versuchen in diesem Fall immer automatisch, die Zustellung einer Nachricht erneut durchzuführen. Abhängig vom Grund der zeitweiligen Ablehnung kann die Nachricht bei einem späteren Zustellversuch akzeptiert werden. Um alle Prüfungen zu deaktivieren und sicherzustellen, dass die Nachricht akzeptiert wird, haben Sie die Möglichkeit den Absender in eine Whitelist einzutragen.

- Greylisted

Das Greylisting-Verfahren wird lediglich auf neue IP-Adressen angewendet, die unserem globalen System noch nicht (gut) bekannt sind. Wir verwenden kein "klassisches" Greylisting, so dass es zu keinerlei Verzögerungen bei Ihrem legitimen Verkehr kommt. Mehr können Sie in unserem FAQ-Artikel "Was bedeutet "Greylisting" und wie wird das bei EuropeanMX gehandhabt?" erfahren.

- You have been denied authentication

Dieser Fehler bedeutet, dass Sie in kurzer Zeit zu oft falsche Authentifizierungsdetails für Ihre ausgehende Nachrichten verwendet haben. Bitte verwenden Sie die korrekten Authentifizierungsdaten, warten Sie einige Augenblicke ab und versuchen Sie es dann erneut. Diese Funktion dient zum Schutz Ihrer SMTP-Anmeldeinformationen vor Brute-Force-Angriffen.

- Unable to verify destination address

Dieser Fehler bedeutet, dass der Zielserver nicht erreichbar ist oder den E-Mail-Verkehr vorübergehend ablehnt. Bitte überprüfen Sie die Zielroute, um sicherzustellen, dass die Zustellung an den richtigen Zielserver versucht wird. Die Protokolle auf dem Zielserver sollten zeigen, warum er die Zustellversuche nicht erfolgreich sind.

- Unable to verify sender address

Das System konnte den Absender anhand eines Sender-Callouts nicht verifizieren. Sie müssen den absendenden Mailserver überprüfen, um herauszufinden, warum diese Callouts nicht durchgeführt werden. Wird die Option "Absenderverifizierung" in den ausgehenden Benutzereinstellungen verwendet, muss jede Absenderadresse auf diese Weise verifiziert werden können.

- Internal error

Es ist ein interner Fehler aufgetreten, der automatisch behoben werden sollte. Falls nicht, wenden Sie sich bitte an unseren Support.

- Per-minute connection limit exceeded

Der Absender hat das Limit der Anzahl der Verbindungen pro Minute überschritten.

- Too Many Connections

Es wurden vom absendenen Mailserver zuviele Verbindungen aufgebaucht.

- Too Many Concurrent SMTP Connections

Zum Schutz der Systeme vor Angriffen gibt es eine fest programmierte Grenze von 10 gleichzeitigen SMTP-Verbindungen pro IP. Bitte stellen Sie sicher, dass der sendende Mailserver nur maximal 10 gleichzeitige Verbindungen öffnet, um dieses Limit nicht zu überschreiten.

- Too many messages. Please wait for a while and try again.

Diese Fehlermeldung bedeutet, dass der ausgehende Benutzer die maximale Anzahl an Nachrichten, die für diesen Benutzer festgelegt wurde, überschritten hat. Über das EuropeanMX Admin Panel haben Sie die Möglichkeit, dieses Limit zu erhöhen oder zu verringern. Auch können Sie die Beschränkung komplett deaktivieren.

- Mail for this domain cannot be accepted right now; please retry (Unable to handle in active connection.)

Eine Nachricht kann innerhalb einer einzigen SMTP-Verbindung an verschiedene Empfänger gesendet werden. Eine Unterscheidung zwischen den verschiedenen Empfängern ist nach dem SMTP-Protokoll nicht erlaubt. Die Nachricht darf nur akzeptiert oder abgelehnt werden. Wenn die Empfänger unterschiedliche Filtereinstellungen verwenden, dann können wir die Nachricht weder akzeptieren noch ablehnen, da die Klassifizierung je nach Empfänger unterschiedlich ausfallen kann. In diesem Fall senden wir eine vorübergehende Ablehnung der Nachricht an den absenden Mailserver, so dass dieser die Zustellung für den Empfänger erneut versucht und jede Nachricht separat klassifiziert werden kann.

Die meisten Mailserver versuchen sofort eine erneute Zustellung, weshalb es keine Lieferverzögerung gibt. Sofern alle Empfänger die gleichen Filtereinstellungen verwenden, wird die Nachricht sofort akzeptiert/abgelehnt, ohne dass das genannte Verfahren Anwendung findet. Falls es dennoch zu einer Verzögerung kommen sollte, dann kann der Absender seinen Server so konfigurieren, dass dieser entweder sofort einen erneuten Zustellungsversuch unternimmt oder gleich eine seperate Verbindung für jeden Empfänger öffnet.



Rejected (5xx SMTP Antwort)

- Rejected

Nachrichten, die abgelehnt wurden, werden vom System geblockt und in die Quarantäne verschoben. Falls es sich nicht um Spam handeln sollte, können Sie die Nachricht aus der Quarantäne freigeben und trainieren lassen. Sie haben jederzeit die Möglichkeit den Absender in die Whitelist einzutragen und sämtliche Prüfungen dadurch zu deaktivieren. Damit können Sie sicherzustellen, dass Nachrichten von diesem Absender vom Filter zukünftig akzeptiert werden.

- Lines in message were longer than user maximum

Diese Fehlermeldung bedeutet, dass eine Zeile innerhalb der Nachricht länger als das eingestellte Maximum ist. Gemäß RFC 5322 (SMTP 5321) darf eine Zeile maximal 998 Zeichen lang sein. Normalerweise wird die Begrenzung einer Zeile automatisch von den E-Mai-Clients (wie Thunderbird oder Outlook) vorgenommen, um spätere Zustellungsprobleme zu vermeiden. Dieses Problem muss von Seiten des Absenders behoben werden. Alternativ können Sie die Prüfung auch deaktivieren.

- Message had more parts than the user maximum (Too many MIME parts)

Diese Fehlermeldung bezieht sich auf die Anzahl der MIME-Teile innerhalb einer Nachricht. Standardmäßig ist eine Grenze von 100 Teilen eingestellt. Diese kann durch eine hohe Anzahl an Anhängen oder anderer MIME-Teile überschritten und ausgelöst werden.

- Sending server used an invalid greeting

Wenn Sie diese Meldung erhalten, dann hat der Absender hat eine ungültige HELO/EHLO verwendet. Dies kann zum einen daran liegen, dass eine IP-Adresse für das HELO verwendet wird, oder daran, dass das HELO ein ungültiges Zeichen enthält, z. B. einen Unterstrich (_). RFC besagt, dass zwangsläufig ein FDQN (Full Qualified Domain Name) verwendet werden MUSS.

- Considered spam

Unsere Systeme haben die Nachricht als SPAM eingestuft und diese in der Quarantäne abgelegt. Das Freigeben der Nachricht aus der Quarantäne behebt den Fehler bei der automatischen Klassifizierung.

- SPF failure

Diese Fehlermeldung bedeutet, dass die Vorgaben gemäß SPF (Sender Policy Framework) verletzt wurden. Wenn es sich um eine legitime Nachricht handelt, dann könnte dies mit der Weiterleitungsfunktion zusammenhängen. Bitte beachten Sie, dass das Freigeben und Trainieren großer Mengen an fehlgeschlagener SPF-Nachrichten dazu führen kann, dass der absendende Hostname von weiteren SPF-Prüfungen ausgeschlossen wird.

- Pyzor

Pyzor ist ein Filter, der den Inhalt einer Nachricht aufgrund gesammelter/berichteter Daten aus unser Datenbank klassifiziert. Sobald Sie eine Nachricht aus der Quarantäne freigeben, wird die Klassifizierung in unserem System korrigiert.

- Sending server is missing DNS records

Dem absendenden Server fehlen MX-Records oder A-Records für die Zustellung. Bitte beachten Sie, dass DNS-Änderungen erst nach Ablauf der ursprünglich eingestellten TTL wirksam werden.

- Destination address does not exist

Die Verbindung wird vom Zielserver mit einem 5xx Fehler (permanent) abgelehnt. Um sicherzustellen, dass die Nachricht angenommen wird, muss das Problem auf dem Zielserver untersucht und behoben werden. In den Logdateien des Zielservers sollte der Grund für das Problem aufgeführt sein.

- Recipient address rejected by destination

Der Empfänger-Callout wird vom Zielserver mit einem 5xx Fehler (permanent) abgelehnt. Um sicherzustellen, dass die Nachricht angenommen wird, muss das Problem auf dem Zielserver untersucht und behoben werden. In den Logdateien des Zielservers sollte der Grund für das Problem aufgeführt sein. Mehr Informationen können Sie in unserem FAQ-Artikel "Was ist ein Recipient Callout?" finden.

- Phishing attempt detected

Unsere Systeme haben einen Phishing-Versuch erkannt. Sobald Sie die Nachricht aus der Quarantäne freigeben, wird die Klassifizierung in unserem System korrigiert.

- Date header far in the past or future.

Sie erhalten diese Klassifizierung, wenn ein Datum innerhalb des Headers einer Nachricht mehr als die standardmäßigen 7 Tage in der Zukunft oder in der Vergangenheit liegt. Durch das Freigeben der Nachricht, wird diese lediglich an den Empfänger weitergeleitet. Dieses Problem muss vom Absender überprüft und gelöst werden.

- Bad header count (Message incorrectly formed)

Nachrichten, die doppelte Header-Informationen wie "Betreff" oder "An" beinhalten, werden solange abgewiesen, bis der zugrunde liegende Fehler in der Software des Absenders behoben wurde. E-Mails sollten niemals doppelte Header-Informationen vorweisen können!

- Blacklisted sending server

Die IP des absendenden Mailservers wurde auf einer Blacklist gefunden.

- Sending server listed on multiple DNSBL

Der absendende Mailserver wurde auf mehreren Blacklisten gefunden. Durch Freigeben der Nachricht wird die Klassifizierung in unserem System korrigiert.

- Sending server attempted too many invalid addresses

Der absendende Mailserver hat versucht Nachrichten innerhalb eines bestimmten Zeitraums an zu viele ungültige Empfängeradressen zu senden. Bitte versuchen Sie es später noch einmal.

- Blacklisted sender

Der Absender wurde der benutzerdefinierten Absender-Blacklist hinzugefügt.

- URLBL

Eine URL innerhalb der Nachricht wurde auf mehreren Blacklisten gefunden. Durch Freigeben der Nachricht wird die Klassifizierung in unserem System korrigiert. Die Fehlermeldung enthält weitere Informationen zur verantwortlichen Liste, in der die URL geführt wird.

- UCEPP

Es wurde ein Token (z.B. URL, IP, Telefonnummer oder andere spezifische Details) in der Nachricht erkannt, der in vergangenen Spamnachrichten gefunden wurde. Durch Freigeben der Nachricht wird die Klassifizierung in unserem System korrigiert.

- External Pattern Match

Das Layout und das Format der Nachricht entspricht dem Muster aus bekannten Spamnachrichten. Durch Freigeben der Nachricht können Sie die Klassifizierung in unserem System korrigieren. Die Fehlermeldung beinhaltet weitere Informationen zur verantwortlichen Blacklist, die den Eintrag führt.

- User-specified blackhole address

Eine benutzerdefinierte /dev/null Adresse. Diese E-Mail wird nicht zugestellt.

- Combined Score

Das "kombinierte" Ergebnis gibt eine gewichtete Klassifizierungsnote der verschiedenen Klassifikatoren an. Abhängig von dem Schwellwert der Quarantäne wird die Nachricht entweder als Spam abgewiesen oder als legitime Nachricht akzeptiert. Der empfohlene Schwellwert liegt bei 0.9. Um weniger restriktiv gegenüber Nachrichten von einem Absender mit falscher HELO/PTR/IP-Konfiguration zu sein, kann ein Schwellwert von 0.91 verwendet werden.

Je niedriger der Schwellwert für die Quarantäne eingestellt ist, um so mehr Nachrichten werden als Spam erkannt und in der Quarantäne abgelegt. Der Absender erhält eine Fehlermeldung mit dem Hinweis "Hohe Wahrscheinlichkeit von Spam". Bitte stellen Sie sicher, dass die legitime Nachrichte aus der Quarantäne freigegeben werden!

- CRM114

Mit CRM114 ist eine statistische Inhaltsprüfung gemeint. Wenn eine Nachricht von unserem System aufgrund dieses Klassifikators geblockt wird, dann bedeutet das, dass es eine enge Übereinstimmung innerhalb der Nachricht mit bereits bekannten Spamnachrichten gegeben hat. Durch Freigeben der Nachricht wird die Klassifizierung in unserem System korrigiert.

- Subject contains invalid characters.

Nachrichten, die mit der Fehlermeldung "550 Subject contains invalid characters" abgelehnt werden, verwenden Zeichen im Betreff, die laut RFC nicht erlaubt sind. Um in einer Betreffzeile Nicht-ASCII-Zeichen einbinden zu können, muss der Betreff korrekt kodiert sein, z.B. mit UTF-8. Standardmäßig handhabt jeder gängige E-Mail-Client dies automatisch, weswegen der Fehler vermutlich an einem benutzerdefinierten Skript liegt, dass den ungültigen Betreff erzeugt hat. Der Header zeigt in diesem Fall unter "Evidence" die Klassifizierung "badly formed subject line".

- Tokens

Mit "Tokens" sind statistische Inhaltskontrollen gemeint, die auf den gesammelten Daten aller Cluster und Kunden weltweit basieren. Durch das Freigeben der Nachricht aus der Quarantäne wird die Klassifizierung in unserem System korrigiert.

- Sanesecurity

Wir verwenden bestimmte Datensätze von Sanesecurity, um Nachrichten besser überprüfen zu können. Die Signatur in der Fehlermeldung können Sie unter dem Link http://sane.mxuptime.com/ entschlüsseln.

- Safebrowsing

Wenn die Nachricht mit der Fehlermeldung "Safebrowsing" abgewiesen wurde, bedeutet dies, dass Google Sie als Verbreiter von bösartigen Dateien gelistet hat.

- Header is too long

Da dies ein übliches Indiez für nicht-legitime Nachrichten ist, werden E-Mails mit zu exessiv hohen Headerwerten abgewiesen.

- Restricted characters in address

Falls eine Nachricht mit der Fehlermeldung "550 restricted charactes in adress" abgewiesen wird, enthält die Empfängeradresse ein Zeichen, dass von unserem System nicht akzeptiert wird (z.B. "&"). In den Domaineinstellungen können festlegen, welche Zeichen für Ihre Domain erlaubt sind.

- Relay not permitted

Falls eine Nachricht mit der Fehlermeldung "550 Relay not permittet!" abgelehnt wird, dann wurde die Einlieferung der E-Mail über den Port 25 für eine Domain versucht, die nicht in unserem System angelegt ist. Um das Problem zu lösen, legen Sie die Domain bitte im eingehenden Filter an.

Falls Sie die Fehlermeldung bei der Verwendung des ausgehenden Filters erhalten, stellen Sie bitte sicher, dass Sie Ihre Nachrichten über den Port 587 an unser System übergeben.

- Message submission is for authorised users only!

Dies bedeutet, dass Sie versuchen die Zustellung Ihrer ausgehenden Nachricht über unseren Filter auf Port 465/587 (standard) zu starten. Bitte stellen Sie sicher, dass Sie gültige Benutzerdaten für die Authentifizierung am ausgehenden Filter verwenden.

Wenn Sie die Fehlermeldung bei eingehenden Zustellungsversuchen erhalten, dann ist Ihr Mailserver falsch konfiguriert (wahrscheinlich eine falsch konfigurierte Version von Lotus Domino).

- Legitimate bounces are never sent to more than one recipient.

Wenn Ihre Nachricht mit der Meldung "Legitimate bounces are never sent to more than one recipient." abgelehnt wird, dann bedeutet das, dass der Mailserver die Nachricht an mehrere Empfänger mit einem leeren "Mail From:" verschickt wurde. Der SMTP RFC 5.3.2.1 gibt vor, dass E-Mails mit leerem "Mail From:" (Bounces) niemals an mehrere Empfänger versendet werden können.

- Destination address is not configured.

Diese Fehlermeldung bedeutet, dass Sie für die Domain die Einstellung "Lokale Empfänger" verwenden und die Empfängeradresse nicht in der Liste enthalten ist.

- The content of this message looked like spam.

Diese Fehlermeldung zeigt an, dass der Inhalt der Nachricht Ähnlichkeit mit bereits gemeldeten Spamnachrichten aufweist und deshalb blockiert wurde. Sofern die Nachricht legitim ist, haben Sie die Möglichkeit diese aus der Quarantäne freizugeben und so die Klassifizierung in unserem System zu korrigieren. Auch wird dadurch der statistische Filter aktualisiert, um ähnliche Nachrichten in Zukunft nicht mehr zu blockieren.

- Unrouteable address

Dieser Fehler tritt auf, wenn ein permanenter Netzwerkfehler bei der Einlieferung der Nachricht auf dem Zielserver vorliegt. Dieses Problem hängt nicht mit dem EuropeanMX Filter zusammen, sondern deutet auf ein Netzwerkproblem hin. Möglicherweise sind die DNS-Server der Domain nicht erreichbar oder defekt. Alternativ kann es auch sein, dass der Hostname oder die IP nicht mehr existieren oder aufgrund eines permanenten Problems nicht erreichbar sind. Über die Webseite http://dnscheck.sidn.nl/ können Sie das Problem auf Fehler im DNS untersuchen. Bitte wenden Sie sich gegebenenfalls an Ihren Netzwerkadministrator.

- We do not accept mail from this address

Diese Fehlermeldung tritt auf, wenn der Absender manuell zur "Blacklist Absender" für die empfangende Domain hinzugefügt wurde.

- We do not accept message/partial messages here

Bevor jeder eine permanente Internetverbindung hatte, war das Versenden von größeren E-Mails zeitaufwendig und schlug oft fehl. Aus diesem Grund zerstückelten ältere E-Mail-Clients größere Nachrichten für die Zustellung in mehrere Teile. Diese alte Funktion wird heutzutage nicht mehr verwendet. Sie birgt ein hohes Risiko, da sie die Erkennung von Viren fast unmöglich macht (Viren werden wie die E-Mail ebenfalls in mehrere Teile zerlegt und erst vom Client des Empfängers wieder zusammengesetzt). Bitte stellen Sie sicher, dass diese Einstellung in Ihrem Mailclient nicht verwendet wird.

- DMARC - REJECT

Dieser Fehler tritt auf, wenn die Domäne des Absenders eine strikte DMARC-Richtlinie verwendet. Wenn der DMARC-Record des Senders auf "REJECT" gesetzt ist und die Nachrichten von IP-Adressen stammen, die sich nicht im SPF des Absenders befinden, werden diese abgewiesen und nicht in Quarantäne gestellt.

- DMARC - Quarantine

Dieser Fehler tritt auf, wenn die Domain des Absenders eine strikte DMARC-Richtlinie verwendet. Wenn der DMARC-Eintrag des Absenders auf "QUARANTINE" gesetzt ist und die Nachrichten von IP-Adressen stammen, die sich nicht im SPF des Absenders befinden oder die einen DKIM-Fehler aufweisen, werden diese Nachrichten in Quarantäne gestellt. Mit der Whitelist kann dies nicht umgangen werden.

Accepted (2xx SMTP response)

- Accepted

Nachrichten, die mit "Accepted" klassifiziert wurden, sind nicht notwendigerweise zugestellt wird. Es bedeutet lediglich, dass die Nachricht vom Filter akzeptiert wurde. Sofern die sofortige Zustellung fehlschlägt, versucht der Filter diese zu einem späteren Zeitpunkt erneut. Falls die Nachricht vom Zielserver abgelehnt wird, erhält der Absender eine entsprechende Fehlermeldung.

- Message looked like non-spam

Diese Nachricht wurde aufgrund unserer inhaltlichen Prüfung zur Einlieferung auf Ihrem Mailserver angenommen. Wenn Sie die Nachricht als Spam melden, wird die Klassifikation in unserem System korrigiert.

- Accepted, DNSWL

Der absendende Server ist auf mehreren DNS-Whitelisten gelistet. Das bedeutet, dass kein Spam von diesem Server in letzter Zeit gesehen wurde. Wenn Sie die Nachricht als Spam melden, wird die Klassifizierung in unserem System korrigiert.

- Accepted, whitelist

Die Absenderadresse wurde in die benutzerdefinierte "Whitelist Absender" eingetragen. Es findet keine Filterung für diese Adresse statt. Wenn Sie die Filterung wieder aktivieren möchten, entfernen Sie die Adresse wieder von der Whitelist.