ttlogo.jpg Freie TextTransformer Projekte
Start
Text2HTML
Wikipedia
Yacc2TT
Delphi-Parser
Java-Parser
C-Präprozessor
C-Parser
HTML4
Nützliches
MIME-Parser
Spamfilter
Weitere Beispiele
Freie Komponenten
  Minimal Website   Impressum

MIME (Multipurpose Internet Mail Extensions)


Mit dem Projekt Mime.ttp wird versucht einen möglichst vollständigen Parser für E-Mails bereitzustellen. Dieser Parser kann z.B. als Basis für eigene Erweiterungen zur Spamerkennung dienen, die sich mittels dem IMP-Filter Plugin direkt in der Antispam-Software Spamihilator einsetzen lassen. Es hat sich gezeigt, dass der detaillierte MIME Parser sogar bereits ohne solche Erweiterung einige Spam abwehren kann, da Spam-Mails oft nicht wirklich MIME-konform sind. Programme, die die Mails für den Leser aufbereiten, beachten diesen Standard ebenfalls nicht im Detail, sondern versuchen vielmehr möglichst alle empfangenen E-Mails möglichst optimal darzustellen. Gerade diese Toleranz erleichtert den Spammern ihre Arbeit.



MIME ist der heutige Standard für den Aufbau von E-Mails. Im Unterschied zum älteren RFC822 Standard, der nur für die Übertragung von Texten gedacht ist, erlaubt MIME auch die Versendung von Bildern, Videos und anderen binären Daten. Während E-Mails nach RFC822 schlicht aus einigen Kopfzeilen und dem eigentlichen Nachrichtentext besteht, können in MIME-Multipart-Nachrichten auf die Kopfzeilen mehrere textuelle Unterstrukturen folgen.

Der MIME-Standard ist als Resultat einer mehrjährigen Entwicklung nicht in einem einzelnen Dokument vollständig spezifiziert. Verschiedene Teile der Spezifizierung sind vielmehr auf eine Menge von historisch gewachsenen Dokumenten verteilt, die sich z.T. gegenseitig korrigieren. Dies dürfte einer der Gründe sein, warum es noch für keinen anderen Parsergenerator eine MIME-Grammatik gibt. Soweit dem Autor bekannt begnügen sich auch die öffentlich zugänglichen handgeschrieben Parser mit einer vereinfachten Behandlung der Kopfdaten. Ein weiterer Grund für das Fehlen einer vollständigen MIME-Grammatik ist vermutlich, dass nur der TextTransformer technisch in der Lage ist, die komplexen Ansprüche eines vollständigen MIME-Parsers zu bewältigen.


Behandlung von Kommentaren:


Kommentare sind bereits in RFC822 definiert als Texte, die in Klammern - '(' und ')' - eingeschlossen sind. Nach dem alten Standard können sie in den Headern nach allen Token vorkommen, z.B. auch zwischen dem Label eines Feldes und dem darauffolgenden Doppelpunkt. Gemäß RFC2822 ist dies nicht mehr zugelassen, aber E-Mail Parser müssen dennoch in der Lage sein auch die alte Form zu lesen. In MIME.ttp werden Kommentare mit dem "Einschluss-"-Feature des TextTransformers behandelt. Eine Produktion, die in den Projektoptionen als Einschluss gesetzt ist, wird nach jedem Token geprüft.


Mehrzeilige Felder:

Zur besseren Lesbarkeit können Felder in mehrere Zeilen "gefaltet" werden, wobei zur Unterscheidung vom Anfang eines neuen Feldes jeweils am Beginn der neuen Zeilen ein oder mehrere Leerzeichen ' ' oder '\t' stehen müssen. Die einzelne Zeile:

To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN

kann so dargestell werden als:

To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN

In MIMI.ttp werden diese Faltungen durch das Token "FWS" (folding white space" erkannt:

FWS ::= (\r\n[ \t]+)+

Nach den Präferenzregeln wird dieser längere Ausdruck mit Vorzug gegenüber einem einfachen Zeilenumbruch erkannt. Das ist eine einfache Art der Vorausschau auf Tokenebene.



Begrenzungen:

Anfang und Ende der Teile einer Multipart-Nachricht werden durch spezielle Begrenzungen markiert. Die speziellen Ausprägungen dieser Begrenzungen werden dabei jeweils innerhalb der Kopfdaten der gesamten Mail bzw. ihrer Teile definiert. In MIME.ttp werden für diese Definitionen dynamische Token erzeugt:

BOUNDARY_BEGIN ::= {DYNAMIC}
BOUNDARY_END ::= {DYNAMIC}

Wenn die Begrenzer nun an späterer Stelle im Text der Mail vorkommen, werden sie durch die dynamischen Token erkannt.


Konfliktvermeidungen:

Soweit es formale Spezifizierungen der MIME-Grammatik in den RFC-Dokumenten gibt, sind diese weitgehend ohne Rücksicht auf die praktische Verwendbarkeit formuliert. Z.B. sieht man im folgenden Ausschnitt aus RFC2822 schnell, dass beide Alternativen von "address" mit "display-name" bzw. mit "phrase" beginnen:

address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
group = display-name ":" [mailbox-list / CFWS] ";"
[CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list


Um unnötige Vorausschauen zu vermeiden wurde die MIME-Grammatik für den TextTransformer weitmöglichst LL(1) konform gemacht. Obige "address"-Produktion wird damit zu:

  phrase 
  (
      angle_addr                        //mailbox
    | "@" FWS? domain                   //mailbox  
    | ":" FWS? mailbox_list? ";" FWS?   // group
  )  
| angle_addr                            //mailbox

(Dabei wird der hier nicht wiedergegeben Anfang von "addr-spec", "local_part", als Spezialfall der verallgemeinerten "phrase" aufgefasst.)


Simple_MIME

Einen toleranten MIME-Parser gibt es hier:

http://www.text-konverter.homepage.t-online.de/Spamfilter_ge.html

Achtung: Während in MIME.ttp die comment-Produktion in den Projektoptionen als Einschluss gesetzt ist, ist sie in Simple_MIME.ttp jeweils in den lokalen Optionen gesetzt.


Letztes Update 28.06.2009

BOUNDARY_END wurde verschoben.


----




http://www.faqs.org/rfcs/rfc822.html

Standard für ARPA Internet Text Nachrichten



http://www.faqs.org/rfcs/rfc2822.html

Dieser Standard spezifiziert eine Syntax für Textnachrichten, die zwischen Computerbenutzern als elektronische Post gesendet werden. Dieser Standard ersetzt den in RFC 822 spezifizierten Standard. RFC 2822 ist eine Aktualisierung, die die gängige Praxis reflektiert und beinhaltet die kleinen Änderungen, die in anderen RFC's spezifiziertt sind.


http://www.faqs.org/rfcs/rfc2045.html

spezifiziert die verschiedenen Kopfdaten, die benutzt werden, um die Struktur von MIME-Nachrichten zu beschreiben.


http://www.faqs.org/rfcs/rfc2046.html

definiert die allgemeine Struktur des MIME-Systems zur Typisierung von Medien und definiert eine anfängliche Menge von medientypen.


http://www.faqs.org/rfcs/rfc2047.html

beschreibt RFC 822 Erweiterungen, die Nicht-US-ASCII Textdaten in Feldern des E-Mail Kopfes erlauben

http://www.faqs.org/rfcs/rfc2048.html

spezifiziert verschiedene IANA Registrierungsprozeduren für MIME bezogen Möglichkeiten.


http://www.faqs.org/rfcs/rfc2049.html

beschreibt Kriterien der MIME-Übereinstimmung und liefert sowohl einige illustrative Beispiele von MIME Nachrichtenformaten, als auch Bekanntmachungen und die Bibliographie.



letzter Stand: 05.08.2009



 to the top