IT Solutions
> Zum Inhalt

Begriffserläuterungen

0-9

3rd-Party-Relaying

Benennt die Situtation, wenn ein Absender über einen weder dem Absender noch Empfänger zugehörigen Mailserver versucht, eine Mail an einen Empfänger zu senden. Der dazwischen geschaltete Mailserver wird dazu missbraucht, als Relais-Station zu agieren (auch als "Mail-Proxy" genannt), was wiederum anderen ganz nützlich ist, um den Ursprung von Mails (Spam, ...) zu verschleiern.
Heutige Mailserverumgebungen verhindern dies allerdings üblicherweise.

Nach oben

A-F

Anti-Spam

Umfassender Begriff, der all die Methoden und Verfahren umfasst, die der Vermeidung, Bekämpfung von und der Aufklärung zur Werbe (Spam)-Mail Problematik dienen.

Address-Faking

Bezeichnet jede Art der Fälschung und Abwandlung von E-Mailadressen (sei es Envelope oder Header), um i.d.R. den Ursprung von Spam-Mails zu verschleiern. Hierzu sind folgende Adressen-Informationen anfällig:

  • Envelope-From: Solange hier eine DNS-auflösbare E-Maildomain enthalten ist, kann eine beliebige Adresse angegeben werden. Per RFC2821 ist sogar eine leere Angabe ("<>") legal, was an sich nur von einem Mailerdaemon verwendet werden sollte, gerne aber auch in Spam-Kreisen seine Anwendung findet.
  • Header-From: Hier können beliebige Fantasieadressen stehen, die syntaktisch nicht unbedingt korrekt sein können. Diese Information wird nur im Falle eine Antwort auf die Mail vom Mailclient herangezogen, nicht aber beim Mailtransport zwischen den Mailservern.
  • Header-To: Auch hier können zur oftmaligen Verwirrung beliebige Fantasieadressen stehen. Es ist nicht notwendig, dass diese mit der tatsächlichen Empfängeradresse übereinstimmt (die ausschließlich über das Envelope-To bestimmt wird!).

 

Bounce-Mails

Bounce-Mails sind von Mailserver erzeugte Nachrichten, die ein Problem bei der Zustellung bzw. Weiterleitung an den Absender melden (auch Postmaster-Mails genannt).
Es handelt dabei um mehr oder weniger gut lesbar automatisch generierte Mitteilungen, dass eine E-Mail den Empfänger permanent oder auch nur vorübergehend nicht erreicht.

Diese Art der Benachrichtigung entspricht dem regulären Betrieb, kann aber in heute üblichen Spam- u. Viren-Szenarien zum Problem für von Spammern und Viren missbrauchte Maildomains werden: Die verteilten Mailserver der Spam-/Viren-Empfänger können mitunter zusammen einen Sturm von Bounce-Mails verursachen, weil die Spam- oder Virenmails abgewiesen werden. Solch ein konzentrierter Schwall von Bounce-Mails (wenn auch an nichtexistierende Empfänger) geht oftmals nicht spurlos am zuständigen Server der missbrauchten Maildomain vorbei.
Auch hier zeigen sich indirekt verursachte DDoS-Anzeichen.

Directory-based address scans

Diverse Firmen, die Spam-Lösungen vertreiben bzw. anbieten, versuchen neue Adressen dadurrch ausfindig zu machen, indem aus einem Katalog (Directory) von Benutzernamen (Username) als User-Teil einer E-Mailadresse auf bestimmten Empfangsdomains durchprobiert werden. Da dies für die Mailserver sehr ressourcenintensiv werden kann (einzelne Subdomains der TU werden bereits mit 15000 nichtzustellbarer Mails/pro Tag bombardiert - Stand 2003-06-26), wird versucht diese Form das Abuse zu unterbinden bzw. abzufangen, was leider dadurch erschwert wird, dass diese Vielzahl von Zugriffen nahezu gleichzeitig von mehreren 100 Mailservern kommen können (was man bereits in die Kategorie einer DDoS - Distribute Denial of Service - Attacke einordnen könnte).

DNS-auflösbar

Als gängige und simple Anti-Spam Methode gilt die Auflösbarkeit des Absenderadresse im Domain Name Service zu überprüfen bzw. vorauszusetzen. Dabei wird aber lediglich der Domain- bzw. Hostteil einer Adresse überprüft. Der Userteil einer Adresse kann im Allgemeinen nicht überprüft werden. Dies ist eine der Möglichkeiten wie sie in RFC 2505 - Anti-Spam Recommendations for SMTP MTAs Erwähnung findet. Vorübergehende Probleme oder Fehlkonfigurationen im Nameservice (außerhalb des TU-Wien Einflussbereichs) können zu entsprechenden Verzögerungen oder sogar zur Abweisung einer ankommen Mail führen.

Empfänger-Abuse-Blockaden

Ein Seiteneffekt der Spam-Problematik ist die missbräuchliche Verwendung von E-Mailadressen der tuwien.ac.at-Domain durch Spam-Versender. Nicht zustellbare Spam-Mails werden dann versucht an die vermeintliche TU-Adresse zu retournieren.

DoS/DDoS Angriffe

(Distributed) Denial of Service Attacks: Ein (Mail-)Ziel wird in einem zeitlich engen Zusammenhang sehr oft (eventuell von unterschiedlichen Orten aus - distributed) beschickt.

Empfänger-subdomainabhängig

Siehe subdomainabhängig.

Envelope-Adresse

Diese dient zwischen den mailübertragenden MTAs als jene Information anhand der Empfänger und Absender ermittelt werden. Dies ist Bestandteil der SMTP-Kommunikation und ist völlig losgelöst von Angaben im sogenannten Mailheader (From:-, To:-Feld)i, siehe Header-Adresse.

Fremddomains

Die Verarbeitung von Mails zu Fremddomains, die über den Mailbastionsrechner geleitet sind, erfordert eine spezielle Behandlung und muss neben den dazu notwendigen korrekt MX-Einstellungen am ZID entsprechend registriert werden.

Nach oben

G-L

Greylisting

Eingehende E-Mails werden, sofern das Tripel Absender, Empfänger und sendender Mailserver nicht schon vermerkt ist, beim 1. Versuch temporär abgewiesen und erst nach einer gewissen Zeitspanne akzeptiert. Variabel ist die Zeitspanne und ob das Greylisting überhaupt wirksam wird. Dies allerdings nur bei gewissen Voraussetzung (z.B. wenn der Senderhost im DNS inkonsistent eingetragen ist, einen Rückschluss auf dynamisch zugewiesene IP-Adressen aufweist, auf einer DNS-Blacklist ...).
Ist ein Tripel akzeptiert, wird dieses vermerkt und für einen gewissen Zeitraum (mind. 1 Tag oder mehr) ohne Verzögerung

Header-Adresse

Informationen, die sich im sogenannten Mail-Header einer E-Mail befinden. Sie dienen als Information für den mailempfangende Person bzw. für den Mailclient (MUA) gedacht und wird NICHT für die eigentlich Zustellung herangezogen. Deswegen ist diese Information im Missbrauchsfall (Spam-Mails) in der Regel nicht vertrauenswürdig, weil beliebig fälschbar (sofern überhaupt angegeben)!
Aus der Sicht der Mail-Envelope ist der Mail-Header lediglich ein Bestandteil des Message-Body (wenn auch der erste, initiale Absatz).

Nach oben

M-R

Mailbastion

Im konkreten Fall der TU Wien handelt es sich um 2 Server, die in Last- und Redundanzkonfiguration eingehende E-Mails aus dem Internet unmittelbar entgegennehmen und an die tatsächlichen Mailserver im TUNET weiterverteilt. Dabei werden TU-weite Mechanismen wie etwa Virusfilterung (Virus-Checking-Service), Antispam-Maßnahmen, Antirelay-Maßnahmen an einer Stelle gebündelt, die dann somit entsprechend sicher gestaltet und gewartet werden können.

Mailbody

Dies ist der dem Mailheader folgende Bestandteil einer E-Mail, der gemeinhin als "Inhalt" oder Mailtext bezeichnet wird.
Aber Achtung: Aus der Sicht des SMTP-Protokolls, besteht der dort benannte "Body" aus dem hier beschriebenen Mailbody zusammen mit dem Mailheader!

Mailbombing

Eine besondere Variante der Mailserver-Plagen, sind sogenannte Mailbombs, die in solchen Umgebungen wirksam werden, wo Mails hinsichtlich Viren- und Spam-Erkennung analysiert werden und ihre Wirkung am Empfänger-Serversystem entfalten. Typischerweise werden Serverressourcen wie Speicher und CPU-Leistung angegriffen, wobei der Auslöser beispielsweise eine kleine Mail ist, die jedoch aufgrund des internen Aufbaus z.B. als Archiv mit tausenden Anhängen oder einer stark komprimierten Datei im Anhang, den empfangenden Mailserver stark belasten oder sogar überlasten kann, sobald dieser den Inhalt zwecks Virenanalyse zu entpacken versucht.

Mailgröße

In der Mailgröße (1 MByte entspr. 1024*1024 Byte) eingerechnet sind alle Komponenten einer Mail, wie der Mailheader, der Mailbody, samt aller dort enthaltenen Attachments in jener Kodierung entsprechend dem Content-Encoding, wie etwa "base64" oder seltener "uuencoded" für Binärinhalte. Die beiden genannten Verfahren können codierungsbedingt lediglich Nutzdaten von 3/4 abzüglich 1,5% der Mailgröße aufnehmen (uuencode ist dabei geringfügig ineffizienter, abzüglich weiterer 1,5%, also insgesamt 3%), d.h. es stehen im Base64-Fall grob 47 MByte und bei Uuencode 46,5 MByte bei einem Limit von 64 MByte zur Verfügung.

Mailheader

Einleitender Bestandteil einer E-Mail, der Absender (From:), Empfänger (To:), Betreff (Subject:), Datum (Date:), diverse Steuer- sowie Zusatzinformationen enthält und dem Mailbody, der den eigentlichen Inhalt der E-Mail aufweist, vorgelagert ist.
Aber Achtung: Aus der Sicht des SMTP-Protokolls, besteht der dort benannte "Body" aus dem hier beschriebenen Mailbody zusammen mit dem Mailheader!

Message Submission

Bezeichnet den Vorgang des Absendens, was mit Hilfe eines MUAs erfolgt und über einen MSA geführt wird, welcher entsprechende Mechanismen implementiert, um den Absender zu identifizieren, um den legitimen Zugriff zu gewährleisten (und einen Missbrauch z.B. als Spam-Relay-Server zu verhindern).
Das auf SMTP basierende Protokoll ist als RFC 2476 festgelegt.

MDA

Mail Delivery Agent - Ein Programm, dessen sich eine MTA bedient, um eine Nachricht zuzustellen (sprich einem Benutzer in seine Mailbox zu stellen).

MSA

Mail Submission Agent - Ein Rechner, der via SMTP E-Mails ausschließlich bzw. primär für das Absenden von Mails entgegennimmt. Dieser fordert daher üblicherweise auch entsprechende Verfahren zur Verschlüsselung des Mailtransfers und eine Authentifizierung des Absenders. Dient also als Vermittler für einen MUA, um die Mails an MTAs weiterzutransportieren.

MTA

Mail Transfer Agent - Ein Rechner, der via SMTP E-Mails entgegennimmt und weiterleitet (und ev. mit Hilfe eines MDA zustellt). Nimmt in der Regel Mails von anderen MTAs bzw. MSAs entgegen und leitet sie an MTAs oder MDAs weiter.
In vielen Mailumgebungen agieren MTAs auch gleichzeitig als MSAs.

MUA

Mail User Agent - Jene Instanz (Programm), dass ein Benutzer verwendet, um E-Mails zu lesen bzw. zu erstellen und abzusenden.

MX

Die Kurzbezeichnung für einen Mail-Exchanger, also einen Mailserver, der mittels eines MX-Records im DNS, für den Empfang von Mails bestimmter Empfängerdomains (was nach dem "@" steht) zuständig ist.

MX-Record

Information aus dem Domain Name Service (DNS), die einem Hostnamen oder einer Domainbezeichnung einen entsprechenden Host als Mailempfänger zuordnet. Es sind prinzipiell mehrere Host-Einträge möglich, wobei eine Reihung gemäß dem vergebenen "Preference"-Wert gegeben ist (niedrige Werte sollen bevorzugt werdeno.

opt-in

Bezeichnet eine Feature, das wahlweise aktiviert werden kann und in der Ausgangseinstellung/-konfiguration nicht vorhanden bzw. gegeben ist.
Die Aktivierung dieses Features sollte via E-Mail an den NOC Hostmaster durch die EDV-verantwortliche Person des Instituts für die entsprechende TU-Subdomain bzw. Host erfolgen (bei genauer Angabe der Bezeichnung des Features).

opt-out

Bezeichnet eine Feature, das wahlweise deaktiviert werden kann und in der Ausgangseinstellung/-konfiguration vorgegeben bzw. voreingestellt ist.
Die Deaktivierung dieses Features sollte via E-Mail an den NOC Hostmaster durch die EDV-verantwortliche Person des Instituts für die entsprechende TU-Subdomain bzw. Host erfolgen (bei genauer Angabe der Bezeichnung des Features).

Realtime Blackholelists

Mit Hilfe des Domain Name Service werden Mailserver Adressen (bzw. allgemein Internetadressen) auf bestimmte Namenszonen abgebildet, sodass durch Abfrage der Zone sofort überprüfbar wird, ob der Server als "Spam"-Versender registriert ist und gegebenenfalls blockiert werden kann. Prominente Beispiele sind die Listen bzw. Zonen von Mail-Abuse.org, wie RBL, RSS, DUL, sowie von ORBZ oder ORDB.

Relaying

Ist der Begriff, des die Weiterleitung einer E-Mail durch einen MTA bezeichnet.

Nach oben

S-Z

Spam-Blockaden-Datenbank

Eine lokal gewartete Datenbank mit Envelope-Absender-Adressen, Mailserver-Adressen/-Namen, die blockiert werden (zumeist zeitlich beschränkt im Zusammenhang mit massiven Spam-Vorkommnissen bzw. auf Benutzeranfrage/-hinweis Betroffener).

SMTP

Simple Mail Transfer Protokoll - Ein Protokoll, das von Mailservern und auch Mailclients dazu verwendet wird (siehe RFC 2821, E-Mails im Internet zu transportieren.

SPF

"Sender Policy Framework"
Im DNS zu einer Absenderdomain eingetragene Informationen, die erlaubte Absendersysteme zur Absenderdomain spezifizieren. Anhand dessen könnte ein Empfänger beurteilen, ob eine Absenderadresse etwa missbraucht wurde. Die in diesem Zusammenhang auftretenden Probleme mit Weiterleitungen können mit SRS umgangen werden.

SRS

"Sender Rewriting Scheme"
Methode, die die Envelope-Absenderadresse entsprechend umschreibt, sodass der ursprüngliche Absender einkodiert ist, aber die Absenderdomain nun zur lokalen Maildomain passt und etwaige SPF-Überprüfungen auf diese Maildomain beziehen (und nicht auf die ursprüngliche).,

Subdomainabhängig

Features lassen sich auf Granularität von Subdomains einstellen. Das kann bezogen auf eine Empfänger-E-Mailadresse (i.d.R.: Envelope-Adresse) sein.

User-Muster

Stellt ein Schema für den User-Teil einer E-Mail-Adresse dar, das als Muster in Form eines regulären Ausdrucks für gewisse Ausprägungen eines Usernamens zutreffend ist. Anhand solcher Muster ist eine Selektion von Absendern oder Empfängern zusammen mit eventuellen Domainangaben der E-Mailadresse möglich. Beispiel wär etwa ein alphanummerisches Muster, das an irgendeiner Stelle mindest 3 Ziffern enthält (trifft auf viele Fantasie-Spam-Absendernamen zu).

Unqualifizierte Header-Adresse

Jene Adressangaben im Mail-Header (vergl. Header-Adresse/Envelope Adresse), die keinen Domaintail (beginnend mit "@") führen, werden als unqualifiziert bezeichnet.
Da ein Mailserver derartige Adressen laut den RFCs verpflichtend qualifizieren muss, wenn die Nachricht weitertransportiert wird, entsteht bei Spam-Mails das Problem, dass solche unqualifizierten Adressen von einem Mailserver mit seinem jeweiligen eigenen Hostnamen zu einer qualifizierten Adresse geformt werden. Beim Empfänger hat es dann den Anschein, der Absender oder Empfänger wäre ein Account auf dem jeweiligen Mailserver, was nicht wirklich stimmt.
Um das zu vermeiden wird auf den Mailservern die Mailrouting betreiben, solch unvollständige Header-Zeilen (From:) durch die Pseudodomain @FAKED-SENDER ergänzt. Dieses Verhalten kann etwa für Spam-Filter-Maßnahmen herangezogen werden.

Nach oben