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.

Hierbei wird unterschieden zwischen Hard- und Softquota:

Wenn die Soft-Quota erreicht ist, bekommt der angegebene Kontakt der Domain eine E-Mail mit der Warnung das die Speicherkapazität bald aufgebraucht ist.

Wenn die Hard-Quota erreicht ist, werden ältere Nachrichten, um Platz für neue E-Mails zu machen, permanent und unwiderruflich aus dem Archiv gelöscht.

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.

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.