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 EuropeanMXs Control Panel verwenden wir verschiedene Klassifizierungen, um zu beschreiben, warum eine Nachricht abgelehnt oder vorübergehend abgelehnt wurde.


Temporarily rejected (4xx SMTP Antwort)

- Temporarily rejected

Abgelehnte Nachrichten bleiben auf dem sendenden Mailserver gespeichert. Legitime Mailserver versuchen immer automatisch, die Zustellung solcher Nachrichten erneut zu versuchen. Abhängig vom Grund der zeitweiligen Ablehnung kann die Nachricht bei einem späteren Zustellversuch akzeptiert werden. Es ist immer möglich, den Absender in eine Whitelist zu setzen, um alle Prüfungen zu deaktivieren und sicherzustellen, dass die Nachricht akzeptiert wird, sobald sie vom sendenden Server erneut versucht wird.

- Greylisted

Temporäre Ablehnung durch Greylisting. Diese Technologie wird nur auf neue IP-Adressen angewendet, die in unseren globalen Systemen noch nicht (gut) bekannt sind. Wir wenden kein "klassisches Greylisting" an, so dass es zu keinen Verzögerungen bei Ihrem legitimen Verkehr kommt.

- You have been denied authentication

Das bedeutet, dass Sie in kurzer Zeit zu oft falsche Authentifizierungsdetails für ausgehende Nachrichten verwendet haben. Verwenden Sie die korrekten Authentifizierungsdetails, warten Sie einige Augenblicke und versuchen Sie es erneut. Damit schützen Sie sich vor Brute-Force-Angriffen auf Ihre SMTP-Anmeldeinformationen.

- Unable to verify destination address

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

- Unable to verify sender address

Das System konnte den Sender nicht anhand eines Sender-Callouts verifizieren. Sie müssen den Absender-Mail-Server überprüfen, um zu überprüfen, warum solche Callouts nicht durchgeführt werden. Wird in den ausgehenden Benutzereinstellungen die Option der Absenderverifizierung verwendet, muss jede Absenderadresse auf diese Weise verifizierbar sein.

- Internal error

Ein interner Fehler ist aufgetreten, dieser sollte automatisch behoben werden. Falls nicht, wenden Sie sich bitte an den Support.

- Per-minute connection limit exceeded

Der Absender hat sein Minutenlimit überschritten.

- Too Many Connections

Zu viele Verbindungen vom sendenden Server. Ratelimitiert.

- 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.

Dies bedeutet, dass der ausgehende Benutzer die maximale Anzahl an Nachrichten, die für den ausgehenden Benutzer konfiguriert wurde, überschritten hat. Sollen die Limits geändert werden, dann können sie über das EuropeanMXs Control Panel das Limit für den ausgehenden Benutzer erhöhen/verringern. Auch können dort diese Grenzwerte vollständig deaktiviert werden.

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

Innerhalb einer einzigen SMTP-Verbindung ist es möglich, eine Nachricht an verschiedene Empfänger zu versenden. Das SMTP-Protokoll erlaubt es Ihnen nur, die E-Mail zu akzeptieren "oder abzulehnen", ohne zwischen den verschiedenen Empfängern zu unterscheiden. Wenn einer der Empfänger unterschiedliche Filtereinstellungen hat, können wir die Nachricht nicht "akzeptieren" oder "ablehnen", da die Klassifizierung je nach Empfänger unterschiedlich sein kann. In diesem Fall senden wir eine vorübergehende Ablehnung zurück, so dass der sendende Server die Zustellung für die Empfänger erneut versuchen wird, so dass jede Nachricht separat klassifiziert werden kann.

Die meisten SMTP-Server versuchen es sofort wieder, weshalb es keine Lieferverzögerung gibt. Wenn alle Empfänger die gleichen Filtereinstellungen verwenden, wird die Nachricht sofort für alle Empfänger akzeptiert (oder abgelehnt), ohne dass diese zeitweilige Ablehnung erfolgt. Im Falle einer Verzögerung kann der Absender stattdessen seinen Server so konfigurieren, dass er entweder sofort erneut versucht (um eine solche Verzögerung zu verhindern) oder für jeden Empfänger eine separate Zustellverbindung öffnet.



Rejected (5xx SMTP Antwort)

- Rejected

Abgelehnte Nachrichten werden vom System geblockt. Generell können diese Nachrichten in der "Spam-Quarantäne"eingesehen werden, von wo aus sie freigegeben werden können. Es ist immer möglich, den Absender in eine Whitelist zu setzen, um alle Prüfungen zu deaktivieren und sicherzustellen, dass die Nachricht akzeptiert wird, sobald sie vom Absender erneut versucht wird.

- Lines in message were longer than user maximum

Dies bedeutet, dass die Zeile innerhalb der E-Mail länger als das eingestellte Maximum ist. Der RFC 5322 (SMTP 5321) spezifiziert eine maximale Zeilenlänge von 998. Normale E-Mail-Clients setzen diese Begrenzung immer durch, um Zustellprobleme zu vermeiden. Das Problem sollte auf der Senderseite behoben werden, oder die Prüfung kann deaktiviert werden.

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

Dies bezieht sich auf die Anzahl der MIME-Teile, die eine Message enthält. Die voreingestellte Grenze ist 100. Dies kann durch übermäßige Anhänge oder andere MIME-Teile entpasst und ausgelöst werden.

- Sending server used an invalid greeting

Der Sender hat eine ungültige HELO/EHLO verwendet. Dies kann entweder 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. Unterstrich (_). Der RFC besagt, dass ein FDQN (Full Qualified Domain Name) verwendet werden MUSS.

- Considered spam

Unsere Systeme betrachteten diese Nachricht als SPAM und unter Quarantäne. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

- SPF failure

Dies bedeutet, dass der SPF (Sender Policy Framework) verletzt wurde. Wenn es sich um legitime Post handelt, dann könnte dies an einer Weiterleitungskonstruktion liegen. Bitte beachten Sie, dass das Freigeben und Trainieren großer Mengen fehlgeschlagener SPF-Nachrichten dazu führen kann, dass die sendende Domäne von weiteren SPF-Prüfungen übersprungen wird.

- Pyzor

Pyzor ist ein inhaltlicher Klassifikator, der auf gesammelten/berichteten Daten aus unseren Datensätzen basiert. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler angezeigt, um unsere Systeme direkt zu korrigieren.

- Sending server is missing DNS records

Der sendende Server fehlt MX-Records oder A-Records. Bitte beachten Sie, dass DNS-Änderungen erst nach Ablauf der ursprünglich eingestellten TTL wirksam werden.

- Destination address does not exist

Der Zielserver lehnt die Verbindung mit einem 5xx permanenten Fehler ab. Die Protokolle auf dem Zielserver zeigen an, warum die Nachricht abgelehnt wurde. Sie müssen das Problem auf dem Zielserver beheben, um sicherzustellen, dass die E-Mail akzeptiert wird.

- Recipient address rejected by destination

Der Zielserver lehnt den Empfängeraufruf mit einem 5xx permanenten Ausfall ab. Die Protokolle auf dem Zielserver zeigen an, warum die Nachricht abgelehnt wurde. Sie müssen das Problem auf dem Zielserver beheben, um sicherzustellen, dass die Callouts der Empfänger verwendet werden können.

- Phishing attempt detected

Unsere Systeme haben einen Phishing-Versuch erkannt. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

- Date header far in the past or future.

Diese Klassifizierung bedeutet, dass der Datumskopf der E-Mail mehr als die Standard 7 Tage in der Vergangenheit oder Zukunft ist. Wenn Sie diese freigeben, wird die Nachricht nur an den Empfänger weitergeleitet. Dies ist etwas, das der Absender auflösen muss.

- Bad header count (Message incorrectly formed)

E-Mails sollten niemals doppelte Header wie "Betreff" oder "An"enthalten. Wenn solche doppelten Header gefunden werden, wird die Nachricht solange abgewiesen, bis der zugrunde liegende Fehler in der E-Mail-Software behoben ist.

- Blacklisted sending server

Der sendende Server wurde auf der IP-Blacklist auf die schwarze Liste gesetzt.

- Sending server listed on multiple DNSBL

Der sendende Server wurde auf mehreren Blacklists gefunden. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren. Eine temporäre Übersteuerung finden Sie unter http://www.spamrl.com

- Sending server attempted too many invalid addresses

Der E-Mail-Sendeserver hat versucht, E-Mails an zu viele ungültige E-Mail-Adressen innerhalb eines bestimmten Zeitraums zu senden. Bitte versuchen Sie es später noch einmal.

- Blacklisted sender

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

- URLBL

Eine URL in der E-Mail wurde auf mehreren Blacklists aufgeführt. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren. Die Ablehnungsmeldung enthält weitere Informationen zur verantwortlichen Liste.

- UCEPP

Ein Token wurde in der Nachricht, die in der letzten Spam-Meldung gefunden wurde (z. B. URL, IP, Telefonnummer oder andere spezifische Details), erkannt. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

- External Pattern Match

Das Layout und das Format der E-Mail entspricht bekannten Spam-E-Mails, die bereits aufgelistet sind. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren. Die Ablehnungsmeldung enthält weitere Informationen zur verantwortlichen Liste.

- User-specified blackhole address

Ein vom Benutzer angegebenes /dev/null Adresse. Diese E-Mail wird nirgendwo zugestellt.

- Combined Score

Das Ergebnis "kombinierte" ergibt eine gewichtete Klassifizierungsnote der verschiedenen Klassifikatoren. Abhängig von der konfigurierten "Quarantäneschwelle"wird die Nachricht als Spam abgewiesen oder akzeptiert. Es wird ein Quarantäneschwellenwert von 0,9 empfohlen. Um für Sender mit einer falschen HELO/PTR/IP-Konfiguration tolerierbarer zu sein, kann ein Score von 0.91 gesetzt werden. Je niedriger die Quarantäneschwelle, desto mehr Nachrichten werden als Spam in Quarantäne gestellt. Die SMTP-Nachricht, die für diese Klassifizierung zurückgegeben wird, ist "Hohe Wahrscheinlichkeit von Spam" an den Absender. Bitte stellen Sie sicher, dass die Nachricht aus der Quarantäne befreit wird, wenn sie legitim ist.

- CRM114

CRM114 ist eine statistische Inhaltsprüfung. Wenn eine Nachricht von diesem Klassifikator auf unseren Systemen blockiert wird, bedeutet das, dass es eine enge Übereinstimmung innerhalb der E-Mail gegeben hat, die einer bereits gesehenen Spam-Nachricht entspricht. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

- Subject contains invalid characters.

Wenn eine Nachricht mit "550 Subject contains invalid characters" abgelehnt wird, hat der Betreff der E-Mail nicht-ASCII-Zeichen, was vom RFC nicht erlaubt ist. Um Nicht-ASCII-Zeichen in Betreffzeilen einzufügen, muss der Betreff entsprechend kodiert sein, z. B. mit UTF-8. Jeder normale E-Mail-Client wird das automatisch für Sie handhaben, also ist es wahrscheinlich ein Fehler in einem benutzerdefinierten Skript, das den ungültigen Betreff erzeugt hat. Der Evidenz-Header für diese Klassifizierung zeigt "Schlecht geformte Betreffzeile".

- Tokens
Globale Tokens (Hosted Cloud / Lokale Wolke)

Dies sind statistische Inhaltskontrollen, die auf der Grundlage von Daten erstellt werden, die von allen unseren Clustern und Kunden weltweit gesammelt wurden. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

Cluster-Token (nur lokale Cloud)

Dies ist ähnlich wie bei den globalen Token, basiert aber speziell auf dem lokalen Cloud-Verkehr und den Berichten. Wenn Sie die Nachricht aus der Quarantäne freigeben, wird sie als Klassifizierungsfehler gemeldet, um unsere Systeme zu korrigieren.

- Sanesecurity

Wir verwenden bestimmte Datensätze von Sanesecurity. Um die Sanesecurity-Signaturen zu entschlüsseln, klicken Sie bitte hier.

- Safebrowsing

Wenn Ihre Nachricht mit "Safebrowsing" in der Ablehnungsnachricht abgelehnt wurde, bedeutet dies, dass sie (vor kurzem) von Google als Hosting bösartiger Dateien gelistet wurde.

- Header is too long

EuropeanMX lehnt E-Mails mit zu hohen Header-Werten standardmäßig ab, da dies ein üblicher Indikator für nicht-legitime E-Mails ist.

- Restricted characters in address

Wurde Ihre Nachricht in der Absage mit "550 Zeichen in Adresse" abgelehnt, bedeutet dies, dass die Empfängeradresse ein Zeichen enthält, das vom System nicht akzeptiert wird, z. B."&". Auf der Seite "Domäneneinstellungen" können Sie steuern, welche Zeichen für eine Domäne erlaubt sind.

- Relay not permitted

Falls Ihre Nachricht mit "550 Relay not permitted!" abgewiesen wurde! In der Ablehnungsnachricht bedeutet dies, dass versucht wurde, den ankommenden Filterdienst auf Port 25 an eine Domäne zu übergeben, die (noch) nicht zur Filterlösung hinzugefügt wurde. Um dies zu beheben, fügen Sie bitte die Domäne dem eingehenden Filterdienst hinzu. Wenn Sie versuchen, den ausgehenden Filterdienst zu verwenden, stellen Sie bitte sicher, dass Sie stattdessen den ausgehenden Filterdienst-Port 587 verwenden.

- Message submission is for authorised users only!

Dies zeigt an, dass Sie versuchen, die Zustellung über unseren Filter für ausgehende E-Mails auf Port 465/587 (Standard) zu starten. Wenn Sie diese Antwort auf einen eingehenden E-Mail-Zustellversuch erhalten, ist Ihr Mailserver falsch eingerichtet (und wahrscheinlich eine falsch konfigurierte Version von Lotus Domino). Wenn Sie versuchen, eine ausgehende E-Mail zu versenden, stellen Sie bitte sicher, dass Sie einen gültigen Benutzernamen/Passwort zur Authentifizierung angeben.

- 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 zeigt an, dass Nullsender-E-Mails (Bounces) niemals an mehrere Empfänger versendet werden können, so dass es zu einer Fehlkonfiguration auf dem Mailserver kommen kann.

- Destination address is not configured.

Dies bedeutet in der Regel, dass die gefilterte Domäne "Lokale Empfänger" verwendet und dass bestimmte E-Mail-Adressen nicht in der Liste der zugelassenen Empfänger enthalten sind.

- The content of this message looked like spam.

Dies zeigt an, dass die Nachricht aufgrund unserer Inhaltsscanner blockiert wurde, da ähnliche Nachrichten als Spam gemeldet wurden. Falls die Nachricht legitim ist, stellen Sie bitte sicher, dass sie aus der Quarantäne entlassen wird. Dadurch werden die statistischen Filter aktualisiert, um solche Probleme in Zukunft zu vermeiden.

- Unrouteable address

Dieser Fehler tritt auf, wenn ein (permanenter) Netzwerkfehler auftritt, der an den Ziel-Mailserver geliefert wird. Dieses Problem hat nichts mit der EuropeanMXs Software zu tun und deutet auf ein Netzwerkproblem hin. Möglicherweise sind die DNS-Server der Domain defekt oder vom Filterserver aus nicht erreichbar. Alternativ ist es möglich, dass der Ziel-Hostname oder die IP-Adresse nicht existiert oder wegen eines permanenten Problems nicht erreichbar ist. Auf der folgenden Seite können Sie nach DNS-Fehlern suchen: http://dnscheck.sidn.nl/. Bitte wenden Sie sich an Ihren Netzwerkadministrator, um Netzwerkprobleme zu untersuchen.

- We do not accept mail from this address

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

- We do not accept message/partial messages here

Bevor die Leute eine permanente Internetverbindung hatten, war das Versenden größerer E-Mails zeitaufwendig und scheiterte oft. Ältere E-Mail-Clients zerlegen daher große E-Mails manchmal noch in einzelne Teile für die Zustellung. Diese alte E-Mail-Funktion wird heutzutage nicht mehr verwendet und birgt ein hohes Risiko, da sie das Erkennen von Viren unmöglich macht (da Viren über einzelne E-Mails verteilt werden, bevor sie vom E-Mail-Client des Empfängers wieder zusammengesetzt werden). Bitte achten Sie darauf, Ihre E-Mail-Client-Einstellungen aufzulösen, um größere E-Mails aufzuteilen.

- DMARC - REJECT

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

- DMARC - Quarantine

Dieser Fehler tritt auf, wenn die Domäne des Absenders eine strikte DMARC-Policy hat. Wenn der DMARC-Eintrag des Senders auf "QUARANTINE" gesetzt ist und die Nachrichten von IP-Adressen stammen, die sich nicht im SPF des Senders befinden oder die einen DKIM-Fehler aufweisen, werden diese Nachrichten in Quarantäne gestellt. Whitelisting wird dies nicht umgehen.


Accepted (2xx SMTP response)

- Accepted

Nachrichten, die die' Akzeptierte' Antwort anzeigen, sind nicht notwendigerweise zugestellt. Es bedeutet, dass die Nachricht zur Zustellung angenommen wurde. Wenn die sofortige Zustellung fehlschlägt, wird die Nachricht automatisch erneut versucht. Wenn der Zielserver die E-Mail ablehnt, wird ein Bounce an den Absender generiert.

- Message looked like non-spam

Diese Nachricht wurde aufgrund unserer inhaltlichen Prüfung zur Lieferung angenommen. Wenn Sie die Nachricht als Spam melden, werden unsere Systeme korrigiert.

- Accepted, DNSWL

Der sendende Server ist auf mehreren DNS-Whitelisten gelistet. Das bedeutet, dass kein Spam von diesem sendenden Server in letzter Zeit gesehen wurde. Wenn Sie die Nachricht als Spam melden, werden unsere Systeme korrigiert.

- Accepted, whitelist

Der Absender wurde vom Empfänger auf eine manuelle Whitelist gesetzt. Wenn Sie den Absender/Empfänger aus der Whitelist entfernen, wird verhindert, dass Spam durch die Whitelist gelangt.