`email.policy`: Policy-Objekte¶

Hinzugefügt in Version 3.3.

Der Hauptfokus des email-Pakets ist die Handhabung von E-Mail-Nachrichten, wie sie in den verschiedenen E-Mail- und MIME-RFCs beschrieben werden. Das allgemeine Format von E-Mail-Nachrichten (ein Block von Header-Feldern, die jeweils aus einem Namen gefolgt von einem Doppelpunkt, gefolgt von einem Wert bestehen, wobei der gesamte Block von einer Leerzeile und einem beliebigen 'Body' gefolgt wird) ist jedoch ein Format, das außerhalb des E-Mail-Bereichs nützlich geworden ist. Einige dieser Verwendungen entsprechen ziemlich genau den Haupt-E-Mail-RFCs, andere nicht. Selbst bei der Arbeit mit E-Mails gibt es Zeiten, in denen es wünschenswert ist, von der strikten Einhaltung der RFCs abzuweichen, z. B. beim Erzeugen von E-Mails, die mit E-Mail-Servern interagieren, die selbst die Standards nicht einhalten, oder die Erweiterungen implementieren, die Sie auf eine Weise verwenden möchten, die gegen die Standards verstößt.

Policy-Objekte verleihen dem E-Mail-Paket die Flexibilität, all diese unterschiedlichen Anwendungsfälle zu behandeln.

Ein Policy-Objekt kapselt eine Reihe von Attributen und Methoden, die das Verhalten verschiedener Komponenten des E-Mail-Pakets während der Nutzung steuern. Policy-Instanzen können an verschiedene Klassen und Methoden im E-Mail-Paket übergeben werden, um das Standardverhalten zu ändern. Die einstellbaren Werte und ihre Standardwerte werden unten beschrieben.

Es gibt eine Standardrichtlinie, die von allen Klassen im E-Mail-Paket verwendet wird. Für alle parser-Klassen und die zugehörigen Komfortfunktionen sowie für die Message-Klasse ist dies die Compat32-Richtlinie über ihre entsprechende vordefinierte Instanz compat32. Diese Richtlinie bietet vollständige Abwärtskompatibilität (in einigen Fällen einschließlich Fehlerkompatibilität) mit der E-Mail-Paketversion vor Python 3.3.

Der Standardwert für das Schlüsselwort policy für EmailMessage ist die EmailPolicy-Richtlinie über ihre vordefinierte Instanz default.

Wenn ein Message- oder EmailMessage-Objekt erstellt wird, erwirbt es eine Richtlinie. Wenn die Nachricht von einem parser erstellt wird, ist eine an den Parser übergebene Richtlinie die Richtlinie, die von der von ihm erstellten Nachricht verwendet wird. Wenn die Nachricht vom Programm erstellt wird, kann die Richtlinie bei ihrer Erstellung angegeben werden. Wenn eine Nachricht an einen generator übergeben wird, verwendet der Generator standardmäßig die Richtlinie der Nachricht, aber Sie können dem Generator auch eine spezifische Richtlinie übergeben, die die im Nachrichtenobjekt gespeicherte überschreibt.

Der Standardwert für das policy-Schlüsselwort für die email.parser-Klassen und die Parser-Komfortfunktionen **wird sich** in einer zukünftigen Version von Python **ändern**. Daher sollten Sie **immer explizit angeben, welche Richtlinie Sie verwenden möchten**, wenn Sie eine der im parser-Modul beschriebenen Klassen und Funktionen aufrufen.

Der erste Teil dieser Dokumentation behandelt die Funktionen von Policy, einer abstrakten Basisklasse, die die gemeinsamen Merkmale aller Policy-Objekte definiert, einschließlich compat32. Dazu gehören bestimmte Hook-Methoden, die intern vom E-Mail-Paket aufgerufen werden und die eine benutzerdefinierte Richtlinie überschreiben könnte, um ein anderes Verhalten zu erzielen. Der zweite Teil beschreibt die konkreten Klassen EmailPolicy und Compat32, die die Hooks implementieren, die das Standardverhalten bzw. das abwärtskompatible Verhalten und die Funktionen bereitstellen.

Policy-Instanzen sind unveränderlich, aber sie können geklont werden, wobei dieselben Schlüsselwortargumente wie der Klassenkonstruktor akzeptiert werden und eine neue Policy-Instanz zurückgegeben wird, die eine Kopie des Originals ist, aber mit geänderten Attributwerten.

Als Beispiel könnte der folgende Code verwendet werden, um eine E-Mail-Nachricht aus einer Datei auf der Festplatte zu lesen und sie an das Systemprogramm sendmail auf einem Unix-System zu übergeben

>>> from email import message_from_binary_file
>>> from email.generator import BytesGenerator
>>> from email import policy
>>> from subprocess import Popen, PIPE
>>> with open('mymsg.txt', 'rb') as f:
...     msg = message_from_binary_file(f, policy=policy.default)
...
>>> p = Popen(['sendmail', msg['To'].addresses[0]], stdin=PIPE)
>>> g = BytesGenerator(p.stdin, policy=msg.policy.clone(linesep='\r\n'))
>>> g.flatten(msg)
>>> p.stdin.close()
>>> rc = p.wait()

Hier weisen wir BytesGenerator an, die RFC-korrekten Zeilen-Trennzeichen bei der Erstellung der Binärzeichenkette zu verwenden, die in die stdin von sendmail eingespeist wird, während die Standardrichtlinie \n als Zeilentrenner verwenden würde.

Einige Methoden des E-Mail-Pakets akzeptieren ein policy-Schlüsselwortargument, das es ermöglicht, die Richtlinie für diese Methode zu überschreiben. Der folgende Code verwendet beispielsweise die Methode as_bytes() des msg-Objekts aus dem vorherigen Beispiel und schreibt die Nachricht unter Verwendung der nativen Zeilentrenner der Plattform, auf der sie ausgeführt wird, in eine Datei

>>> import os
>>> with open('converted.txt', 'wb') as f:
...     f.write(msg.as_bytes(policy=msg.policy.clone(linesep=os.linesep)))
17

Policy-Objekte können auch mit dem Additionsoperator kombiniert werden, was ein Policy-Objekt erzeugt, dessen Einstellungen eine Kombination der Nicht-Standardwerte der summierten Objekte sind

>>> compat_SMTP = policy.compat32.clone(linesep='\r\n')
>>> compat_strict = policy.compat32.clone(raise_on_defect=True)
>>> compat_strict_SMTP = compat_SMTP + compat_strict

Diese Operation ist nicht kommutativ; das heißt, die Reihenfolge, in der die Objekte addiert werden, spielt eine Rolle. Zur Veranschaulichung

>>> policy100 = policy.compat32.clone(max_line_length=100)
>>> policy80 = policy.compat32.clone(max_line_length=80)
>>> apolicy = policy100 + policy80
>>> apolicy.max_line_length
80
>>> apolicy = policy80 + policy100
>>> apolicy.max_line_length
100

class email.policy.Policy(**kw)¶

Dies ist die abstrakte Basisklasse für alle Policy-Klassen. Sie bietet Standardimplementierungen für einige triviale Methoden sowie die Implementierung der Unveränderlichkeitseigenschaft, der Methode clone() und der Konstruktorsemantik.

Dem Konstruktor einer Policy-Klasse können verschiedene Schlüsselwortargumente übergeben werden. Die Argumente, die angegeben werden können, sind alle Nicht-Methoden-Eigenschaften dieser Klasse sowie alle zusätzlichen Nicht-Methoden-Eigenschaften der konkreten Klasse. Ein im Konstruktor angegebener Wert überschreibt den Standardwert für das entsprechende Attribut.

Diese Klasse definiert die folgenden Eigenschaften, und daher können Werte für die folgenden Eigenschaften im Konstruktor jeder Policy-Klasse übergeben werden

max_line_length¶: Die maximale Länge jeder Zeile in der serialisierten Ausgabe, ohne Berücksichtigung der Zeilenabschlusszeichen. Standard ist 78 gemäß RFC 5322. Ein Wert von 0 oder None zeigt an, dass keine Zeilenumbrüche erfolgen sollen.

linesep¶: Die Zeichenkette, die zur Beendigung von Zeilen in der serialisierten Ausgabe verwendet werden soll. Der Standard ist \n, da dies die interne Zeilenende-Disziplin von Python ist, obwohl \r\n von den RFCs gefordert wird.

cte_type¶

Steuert die Art der Content Transfer Encodings, die verwendet werden dürfen oder müssen. Die möglichen Werte sind

`7bit`	Alle Daten müssen "7-Bit-sauber" (nur ASCII) sein. Das bedeutet, dass Daten, wo nötig, entweder mit Quoted-Printable oder Base64 kodiert werden.
`8bit`	Daten sind nicht auf 7-Bit-Reinheit beschränkt. Daten in Headern müssen weiterhin nur ASCII sein und werden daher kodiert (siehe `fold_binary()` und `utf8` unten für Ausnahmen), aber Body-Teile dürfen den `8bit` CTE verwenden.

Ein cte_type-Wert von 8bit funktioniert nur mit BytesGenerator, nicht mit Generator, da Zeichenketten keine Binärdaten enthalten können. Wenn ein Generator unter einer Richtlinie arbeitet, die cte_type=8bit angibt, verhält er sich so, als ob cte_type 7bit wäre.

raise_on_defect¶: Wenn True, werden alle gefundenen Mängel als Fehler ausgelöst. Wenn False (Standard), werden Mängel an die Methode register_defect() übergeben.

mangle_from_¶: Wenn True, werden Zeilen, die mit “From “ im Body beginnen, maskiert, indem ihnen ein > vorangestellt wird. Dieser Parameter wird verwendet, wenn die Nachricht von einem Generator serialisiert wird. Standard: False.

Hinzugefügt in Version 3.5.

message_factory¶: Eine Factory-Funktion zum Erstellen eines neuen leeren Nachrichtenobjekts. Wird vom Parser beim Erstellen von Nachrichten verwendet. Standard ist None, in diesem Fall wird Message verwendet.

Hinzugefügt in Version 3.6.

verify_generated_headers¶

Wenn True (Standard), löst der Generator HeaderWriteError aus, anstatt einen Header zu schreiben, der falsch gefaltet oder getrennt ist, so dass er als mehrere Header geparst oder mit benachbarten Daten verbunden würde. Solche Header können durch benutzerdefinierte Header-Klassen oder Fehler im email-Modul generiert werden.

Da dies ein Sicherheitsmerkmal ist, ist dieser Wert standardmäßig True, auch in der Compat32-Richtlinie. Für abwärtskompatibles, aber unsicheres Verhalten muss er explizit auf False gesetzt werden.

Hinzugefügt in Version 3.13.

Die folgende Policy-Methode ist dazu bestimmt, von Code, der die E-Mail-Bibliothek verwendet, aufgerufen zu werden, um Policy-Instanzen mit benutzerdefinierten Einstellungen zu erstellen

clone(**kw)¶: Gibt eine neue Policy-Instanz zurück, deren Attribute dieselben Werte wie die aktuelle Instanz haben, außer dort, wo diese Attribute durch die Schlüsselwortargumente neue Werte erhalten.

Die verbleibenden Policy-Methoden werden vom E-Mail-Paketcode aufgerufen und sind nicht dazu bestimmt, von einer Anwendung, die das E-Mail-Paket verwendet, aufgerufen zu werden. Eine benutzerdefinierte Richtlinie muss all diese Methoden implementieren.

handle_defect(obj, defect)¶

Behandelt einen defect, der bei obj gefunden wurde. Wenn das E-Mail-Paket diese Methode aufruft, ist defect immer eine Unterklasse von MessageDefect.

Die Standardimplementierung prüft das Flag raise_on_defect. Wenn es True ist, wird defect als Ausnahme ausgelöst. Wenn es False (Standard) ist, werden obj und defect an register_defect() übergeben.

register_defect(obj, defect)¶

Registriert einen defect bei obj. Im E-Mail-Paket ist defect immer eine Unterklasse von MessageDefect.

Die Standardimplementierung ruft die Methode append des Attributs defects von obj auf. Wenn das E-Mail-Paket handle_defect aufruft, hat obj normalerweise ein Attribut defects, das eine Methode append hat. Benutzerdefinierte Objekt-Typen, die mit dem E-Mail-Paket verwendet werden (z. B. benutzerdefinierte Message-Objekte), sollten ebenfalls ein solches Attribut bereitstellen, andernfalls führen Mängel in geparsten Nachrichten zu unerwarteten Fehlern.

header_max_count(name)¶

Gibt die maximal zulässige Anzahl von Headern mit dem Namen name zurück.

Wird aufgerufen, wenn ein Header zu einem EmailMessage- oder Message-Objekt hinzugefügt wird. Wenn der zurückgegebene Wert nicht 0 oder None ist und bereits eine Anzahl von Headern mit dem Namen name vorhanden ist, die größer oder gleich dem zurückgegebenen Wert ist, wird ein ValueError ausgelöst.

Da das Standardverhalten von Message.__setitem__ darin besteht, den Wert an die Liste der Header anzuhängen, ist es einfach, doppelte Header zu erstellen, ohne es zu merken. Diese Methode ermöglicht es, bestimmte Header in der Anzahl der Instanzen dieses Headers zu begrenzen, die programmatisch zu einer Message hinzugefügt werden dürfen. (Das Limit wird vom Parser nicht beachtet, der getreu so viele Header erzeugt, wie im zu parsierenden Nachrichten vorhanden sind.)

Die Standardimplementierung gibt für alle Header-Namen None zurück.

header_source_parse(sourcelines)¶

Das E-Mail-Paket ruft diese Methode mit einer Liste von Zeichenketten auf, wobei jede Zeichenkette mit den Zeilenabschlusszeichen endet, die im zu parsierenden Quelltext gefunden wurden. Die erste Zeile enthält den Namen und den Trenner des Header-Feldes. Alle Leerzeichen im Quelltext bleiben erhalten. Die Methode sollte das Tupel (name, value) zurückgeben, das in der Message gespeichert werden soll, um den geparsten Header darzustellen.

Wenn eine Implementierung die Kompatibilität mit den bestehenden E-Mail-Paket-Richtlinien beibehalten möchte, sollte name der beibehaltene Groß-/Kleinschreibung-Name sein (alle Zeichen bis zum ‘:’-Trenner), während value der entfaltete Wert sein sollte (alle Zeilentrennzeichen entfernt, aber Leerzeichen beibehalten), von führenden Leerzeichen bereinigt.

sourcelines kann Surrogate-escaped Binärdaten enthalten.

Es gibt keine Standardimplementierung

header_store_parse(name, value)¶

Das E-Mail-Paket ruft diese Methode mit dem Namen und Wert auf, die vom Anwendungsprogramm bereitgestellt werden, wenn das Anwendungsprogramm eine Message programmatisch ändert (im Gegensatz zu einer von einem Parser erstellten Message). Die Methode sollte das Tupel (name, value) zurückgeben, das in der Message gespeichert werden soll, um den Header darzustellen.

Wenn eine Implementierung die Kompatibilität mit den bestehenden E-Mail-Paket-Richtlinien beibehalten möchte, sollten name und value Zeichenketten oder Zeichenketten-Unterklassen sein, die den Inhalt der übergebenen Argumente nicht ändern.

Es gibt keine Standardimplementierung

header_fetch_parse(name, value)¶

Das E-Mail-Paket ruft diese Methode mit dem name und value auf, die derzeit in der Message gespeichert sind, wenn dieser Header vom Anwendungsprogramm angefordert wird, und was auch immer die Methode zurückgibt, wird an die Anwendung als Wert des abgerufenen Headers zurückgegeben. Beachten Sie, dass möglicherweise mehr als ein Header mit demselben Namen in der Message gespeichert ist; die Methode wird mit dem spezifischen Namen und Wert des Headers, der an die Anwendung zurückgegeben werden soll, aufgerufen.

value kann Surrogate-escaped Binärdaten enthalten. Es sollten keine Surrogate-escaped Binärdaten im von der Methode zurückgegebenen Wert vorhanden sein.

Es gibt keine Standardimplementierung

fold(name, value)¶

Das E-Mail-Paket ruft diese Methode mit dem name und value auf, die derzeit in der Message für einen bestimmten Header gespeichert sind. Die Methode sollte eine Zeichenkette zurückgeben, die diesen Header korrekt "gefaltet" (gemäß den Richtlinieneinstellungen) darstellt, indem sie den name mit dem value kombiniert und linesep-Zeichen an den entsprechenden Stellen einfügt. Siehe RFC 5322 für eine Diskussion der Regeln für das Falten von E-Mail-Headern.

value kann Surrogate-escaped Binärdaten enthalten. Es sollten keine Surrogate-escaped Binärdaten in der von der Methode zurückgegebenen Zeichenkette vorhanden sein.

fold_binary(name, value)¶

Dasselbe wie fold(), außer dass der zurückgegebene Wert ein Bytes-Objekt und keine Zeichenkette sein sollte.

value kann Surrogate-escaped Binärdaten enthalten. Diese könnten im zurückgegebenen Bytes-Objekt wieder in Binärdaten umgewandelt werden.

class email.policy.EmailPolicy(**kw)¶

Diese konkrete Policy bietet ein Verhalten, das vollständig konform mit den aktuellen E-Mail-RFCs ist. Dazu gehören (aber nicht ausschließlich) RFC 5322, RFC 2047 und die aktuellen MIME-RFCs.

Diese Richtlinie fügt neue Algorithmen zum Parsen und Falten von Headern hinzu. Anstelle einfacher Zeichenketten sind Header str-Unterklassen mit Attributen, die vom Typ des Feldes abhängen. Die Parsing- und Faltungsalgorithmen implementieren RFC 2047 und RFC 5322 vollständig.

Der Standardwert für das Attribut message_factory ist EmailMessage.

Zusätzlich zu den oben aufgeführten einstellbaren Attributen, die für alle Richtlinien gelten, fügt diese Richtlinie die folgenden zusätzlichen Attribute hinzu

Hinzugefügt in Version 3.6: [1]

utf8¶: Wenn False, folgt RFC 5322 und unterstützt Nicht-ASCII-Zeichen in Headern, indem diese als "encoded words" kodiert werden. Wenn True, folgt RFC 6532 und verwendet utf-8-Kodierung für Header. Nachrichten, die auf diese Weise formatiert sind, können an SMTP-Server übergeben werden, die die SMTPUTF8-Erweiterung unterstützen (RFC 6531).

refold_source¶

Wenn der Wert eines Headers im Message-Objekt aus einem parser stammt (im Gegensatz zu einem vom Programm gesetzten Wert), gibt dieses Attribut an, ob ein Generator diesen Wert beim Umwandeln der Nachricht zurück in die serialisierte Form neu falten soll oder nicht. Die möglichen Werte sind

`none`	Alle Quellwerte verwenden die ursprüngliche Faltung
`long`	Quellwerte, bei denen eine Zeile länger als `max_line_length` ist, werden neu gefaltet
`all`	Alle Werte werden neu gefaltet.

Der Standardwert ist long.

header_factory¶: Ein aufrufbares Objekt, das zwei Argumente entgegennimmt: name und value, wobei name ein Headerfeldname und value ein entfalteter Headerfeldwert ist, und eine Zeichenketten-Unterklasse zurückgibt, die diesen Header darstellt. Eine Standard-header_factory (siehe headerregistry) wird bereitgestellt, die benutzerdefinierte Analysen für die verschiedenen Adress- und Datums-Headerfelder nach RFC 5322 und die wichtigsten MIME-Headerfeldtypen unterstützt. Die Unterstützung für zusätzliche benutzerdefinierte Analysen wird in Zukunft hinzugefügt.

content_manager¶: Ein Objekt mit mindestens zwei Methoden: get_content und set_content. Wenn die Methode get_content() oder set_content() eines EmailMessage-Objekts aufgerufen wird, ruft es die entsprechende Methode dieses Objekts auf und übergibt ihm das Nachrichtenobjekt als erstes Argument sowie alle Argumente oder Schlüsselwörter, die ihm als zusätzliche Argumente übergeben wurden. Standardmäßig ist content_manager auf raw_data_manager gesetzt.

Hinzugefügt in Version 3.4.

Die Klasse bietet die folgenden konkreten Implementierungen der abstrakten Methoden von Policy

header_max_count(name)¶: Gibt den Wert des Attributs max_count der spezialisierten Klasse zurück, die zur Darstellung des Headers mit dem gegebenen Namen verwendet wird.

header_source_parse(sourcelines)¶: Der Name wird als alles bis zum ‘:’ geparst und unverändert zurückgegeben. Der Wert wird ermittelt, indem führende Leerzeichen vom Rest der ersten Zeile entfernt, alle nachfolgenden Zeilen zusammengefügt und alle abschließenden Wagenrücklauf- oder Zeilenumbruchzeichen entfernt werden.

header_store_parse(name, value)¶: Der Name wird unverändert zurückgegeben. Wenn der Eingabewert ein Attribut name hat und dieses name unter Berücksichtigung der Groß- und Kleinschreibung übereinstimmt, wird der Wert unverändert zurückgegeben. Andernfalls werden name und value an header_factory übergeben, und das daraus resultierende Header-Objekt wird als Wert zurückgegeben. In diesem Fall wird ein ValueError ausgelöst, wenn der Eingabewert CR- oder LF-Zeichen enthält.

header_fetch_parse(name, value)¶: Wenn der Wert ein Attribut name hat, wird er unverändert zurückgegeben. Andernfalls werden name und der value mit allen entfernten CR- oder LF-Zeichen an die header_factory übergeben, und das daraus resultierende Header-Objekt wird zurückgegeben. Alle surrogat-escaped Bytes werden in das Unicode-Symbol für unbekannte Zeichen umgewandelt.

fold(name, value)¶

Die Header-Faltung wird durch die Richtlinieneinstellung refold_source gesteuert. Ein Wert gilt genau dann als „Source Value“ (Quellwert), wenn er kein Attribut name hat (ein Attribut name zu haben bedeutet, dass es sich um ein Header-Objekt irgendeiner Art handelt). Wenn ein Quellwert gemäß der Richtlinie neu gefaltet werden muss, wird er in ein Header-Objekt umgewandelt, indem name und der value mit allen entfernten CR- und LF-Zeichen an die header_factory übergeben werden. Die Faltung eines Header-Objekts erfolgt durch Aufrufen seiner fold-Methode mit der aktuellen Richtlinie.

Quellwerte werden mithilfe von splitlines() in Zeilen aufgeteilt. Wenn der Wert nicht neu gefaltet werden soll, werden die Zeilen mit dem linesep aus der Richtlinie wieder verbunden und zurückgegeben. Eine Ausnahme bilden Zeilen, die nicht-ASCII-Binärdaten enthalten. In diesem Fall wird der Wert unabhängig von der Einstellung refold_source neu gefaltet, was dazu führt, dass die Binärdaten mit der unknown-8bit-Zeichensatzkodierung CTE-codiert werden.

fold_binary(name, value)¶

Dasselbe wie fold(), wenn cte_type 7bit ist, mit der Ausnahme, dass der zurückgegebene Wert Bytes ist.

Wenn cte_type 8bit ist, werden Nicht-ASCII-Binärdaten zurück in Bytes konvertiert. Header mit Binärdaten werden nicht neu gefaltet, unabhängig von der Einstellung refold_header, da nicht bekannt ist, ob die Binärdaten aus Einzelbyte-Zeichen oder Mehrbyte-Zeichen bestehen.

Die folgenden Instanzen von EmailPolicy bieten Standardwerte, die für spezifische Anwendungsdomänen geeignet sind. Beachten Sie, dass das Verhalten dieser Instanzen (insbesondere der HTTP-Instanz) in Zukunft möglicherweise angepasst wird, um den für ihre Domänen relevanten RFCs noch genauer zu entsprechen.

email.policy.default¶: Eine Instanz von EmailPolicy mit unveränderten Standardwerten. Diese Richtlinie verwendet die Standard-Python-Zeilenumbrüche \n anstelle der RFC-konformen \r\n.

email.policy.SMTP¶: Geeignet für die Serialisierung von Nachrichten in Übereinstimmung mit den E-Mail-RFCs. Wie default, aber mit linesep auf \r\n gesetzt, was RFC-konform ist.

email.policy.SMTPUTF8¶: Dasselbe wie SMTP, außer dass utf8 True ist. Nützlich für die Serialisierung von Nachrichten in einem Nachrichtenspeicher, ohne kodierte Wörter in den Headern zu verwenden. Sollte nur für die SMTP-Übertragung verwendet werden, wenn die Absender- oder Empfängeradressen Nicht-ASCII-Zeichen enthalten (die Methode smtplib.SMTP.send_message() erledigt dies automatisch).

email.policy.HTTP¶: Geeignet für die Serialisierung von Headern für die Verwendung im HTTP-Verkehr. Wie SMTP, außer dass max_line_length auf None (unbegrenzt) gesetzt ist.

email.policy.strict¶

Bequeme Instanz. Dasselbe wie default, außer dass raise_on_defect auf True gesetzt ist. Dies ermöglicht es, jede Richtlinie streng zu machen, indem man schreibt

somepolicy + policy.strict

Mit all diesen EmailPolicies ändert sich die effektive API des E-Mail-Pakets gegenüber der API von Python 3.2 in den folgenden Punkten:

Das Setzen eines Headers in einer Message führt dazu, dass dieser Header geparst und ein Header-Objekt erstellt wird.
Das Abrufen eines Header-Werts aus einer Message führt dazu, dass dieser Header geparst und ein Header-Objekt erstellt und zurückgegeben wird.
Jedes Header-Objekt oder jeder Header, der aufgrund der Richtlinieneinstellungen neu gefaltet wird, wird mit einem Algorithmus gefaltet, der die RFC-Faltungsalgorithmen vollständig implementiert, einschließlich des Wissens, wo kodierte Wörter erforderlich und erlaubt sind.

Aus Sicht der Anwendung bedeutet dies, dass jeder Header, der über die EmailMessage abgerufen wird, ein Header-Objekt mit zusätzlichen Attributen ist, dessen Zeichenkettenwert der vollständig dekodierte Unicode-Wert des Headers ist. Ebenso kann ein Header einen neuen Wert zugewiesen bekommen oder ein neuer Header erstellt werden, indem eine Unicode-Zeichenkette verwendet wird, und die Richtlinie kümmert sich um die Umwandlung der Unicode-Zeichenkette in die korrekte RFC-kodierte Form.

Die Header-Objekte und ihre Attribute werden in headerregistry beschrieben.

class email.policy.Compat32(**kw)¶

Diese konkrete Policy ist die Abwärtskompatibilitätsrichtlinie. Sie repliziert das Verhalten des E-Mail-Pakets in Python 3.2. Das Modul policy definiert auch eine Instanz dieser Klasse, compat32, die als Standardrichtlinie verwendet wird. Somit ist das Standardverhalten des E-Mail-Pakets die Aufrechterhaltung der Kompatibilität mit Python 3.2.

Die folgenden Attribute haben Werte, die sich von den Standardwerten der Policy unterscheiden

mangle_from_¶: Der Standardwert ist True.

Die Klasse bietet die folgenden konkreten Implementierungen der abstrakten Methoden von Policy

header_source_parse(sourcelines)¶: Der Name wird als alles bis zum ‘:’ geparst und unverändert zurückgegeben. Der Wert wird ermittelt, indem führende Leerzeichen vom Rest der ersten Zeile entfernt, alle nachfolgenden Zeilen zusammengefügt und alle abschließenden Wagenrücklauf- oder Zeilenumbruchzeichen entfernt werden.

header_store_parse(name, value)¶: Der Name und der Wert werden unverändert zurückgegeben.

header_fetch_parse(name, value)¶: Wenn der Wert Binärdaten enthält, wird er unter Verwendung des unknown-8bit-Zeichensatzes in ein Header-Objekt umgewandelt. Andernfalls wird er unverändert zurückgegeben.

fold(name, value)¶: Header werden mit dem Header-Faltungsalgorithmus gefaltet, der vorhandene Zeilenumbrüche im Wert beibehält und jede resultierende Zeile auf die max_line_length umbricht. Nicht-ASCII-Binärdaten werden mit dem unknown-8bit-Zeichensatz CTE-codiert.

fold_binary(name, value)¶: Header werden mit dem Header-Faltungsalgorithmus gefaltet, der vorhandene Zeilenumbrüche im Wert beibehält und jede resultierende Zeile auf die max_line_length umbricht. Wenn cte_type 7bit ist, werden Nicht-ASCII-Binärdaten mit dem unknown-8bit-Zeichensatz CTE-codiert. Andernfalls wird der ursprüngliche Quellheader mit seinen vorhandenen Zeilenumbrüchen und allen (RFC-ungültigen) Binärdaten, die er enthalten kann, verwendet.

email.policy.compat32¶: Eine Instanz von Compat32, die die Abwärtskompatibilität mit dem Verhalten des E-Mail-Pakets in Python 3.2 bietet.

Fußnoten

`email.policy`: Policy-Objekte¶

Vorheriges Thema

Nächstes Thema

Diese Seite

email.policy: Policy-Objekte¶

`email.policy`: Policy-Objekte¶