1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
<span id="email-policy-policy-objects"></span><h1>email.policy: Policy Objects</h1> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> <p><strong>Source code:</strong> <a class="reference external" href="https://github.com/python/cpython/tree/3.12/Lib/email/policy.py">Lib/email/policy.py</a></p> <p>The <a class="reference internal" href="email#module-email" title="email: Package supporting the parsing, manipulating, and generating email messages."><code>email</code></a> package’s prime focus is the handling of email messages as described by the various email and MIME RFCs. However, the general format of email messages (a block of header fields each consisting of a name followed by a colon followed by a value, the whole block followed by a blank line and an arbitrary ‘body’), is a format that has found utility outside of the realm of email. Some of these uses conform fairly closely to the main email RFCs, some do not. Even when working with email, there are times when it is desirable to break strict compliance with the RFCs, such as generating emails that interoperate with email servers that do not themselves follow the standards, or that implement extensions you want to use in ways that violate the standards.</p> <p>Policy objects give the email package the flexibility to handle all these disparate use cases.</p> <p>A <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> object encapsulates a set of attributes and methods that control the behavior of various components of the email package during use. <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> instances can be passed to various classes and methods in the email package to alter the default behavior. The settable values and their defaults are described below.</p> <p>There is a default policy used by all classes in the email package. For all of the <a class="reference internal" href="email.parser#module-email.parser" title="email.parser: Parse flat text email messages to produce a message object structure."><code>parser</code></a> classes and the related convenience functions, and for the <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> class, this is the <a class="reference internal" href="#email.policy.Compat32" title="email.policy.Compat32"><code>Compat32</code></a> policy, via its corresponding pre-defined instance <a class="reference internal" href="#email.policy.compat32" title="email.policy.compat32"><code>compat32</code></a>. This policy provides for complete backward compatibility (in some cases, including bug compatibility) with the pre-Python3.3 version of the email package.</p> <p>This default value for the <em>policy</em> keyword to <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> is the <a class="reference internal" href="#email.policy.EmailPolicy" title="email.policy.EmailPolicy"><code>EmailPolicy</code></a> policy, via its pre-defined instance <a class="reference internal" href="#email.policy.default" title="email.policy.default"><code>default</code></a>.</p> <p>When a <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> or <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> object is created, it acquires a policy. If the message is created by a <a class="reference internal" href="email.parser#module-email.parser" title="email.parser: Parse flat text email messages to produce a message object structure."><code>parser</code></a>, a policy passed to the parser will be the policy used by the message it creates. If the message is created by the program, then the policy can be specified when it is created. When a message is passed to a <a class="reference internal" href="email.generator#module-email.generator" title="email.generator: Generate flat text email messages from a message structure."><code>generator</code></a>, the generator uses the policy from the message by default, but you can also pass a specific policy to the generator that will override the one stored on the message object.</p> <p>The default value for the <em>policy</em> keyword for the <a class="reference internal" href="email.parser#module-email.parser" title="email.parser: Parse flat text email messages to produce a message object structure."><code>email.parser</code></a> classes and the parser convenience functions <strong>will be changing</strong> in a future version of Python. Therefore you should <strong>always specify explicitly which policy you want to use</strong> when calling any of the classes and functions described in the <a class="reference internal" href="email.parser#module-email.parser" title="email.parser: Parse flat text email messages to produce a message object structure."><code>parser</code></a> module.</p> <p>The first part of this documentation covers the features of <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a>, an <a class="reference internal" href="../glossary#term-abstract-base-class"><span class="xref std std-term">abstract base class</span></a> that defines the features that are common to all policy objects, including <a class="reference internal" href="#email.policy.compat32" title="email.policy.compat32"><code>compat32</code></a>. This includes certain hook methods that are called internally by the email package, which a custom policy could override to obtain different behavior. The second part describes the concrete classes <a class="reference internal" href="#email.policy.EmailPolicy" title="email.policy.EmailPolicy"><code>EmailPolicy</code></a> and <a class="reference internal" href="#email.policy.Compat32" title="email.policy.Compat32"><code>Compat32</code></a>, which implement the hooks that provide the standard behavior and the backward compatible behavior and features, respectively.</p> <p><a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> instances are immutable, but they can be cloned, accepting the same keyword arguments as the class constructor and returning a new <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> instance that is a copy of the original but with the specified attributes values changed.</p> <p>As an example, the following code could be used to read an email message from a file on disk and pass it to the system <code>sendmail</code> program on a Unix system:</p> <pre data-language="pycon3">>>> 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()
</pre> <p>Here we are telling <a class="reference internal" href="email.generator#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a> to use the RFC correct line separator characters when creating the binary string to feed into <code>sendmail's</code> <code>stdin</code>, where the default policy would use <code>\n</code> line separators.</p> <p>Some email package methods accept a <em>policy</em> keyword argument, allowing the policy to be overridden for that method. For example, the following code uses the <a class="reference internal" href="email.compat32-message#email.message.Message.as_bytes" title="email.message.Message.as_bytes"><code>as_bytes()</code></a> method of the <em>msg</em> object from the previous example and writes the message to a file using the native line separators for the platform on which it is running:</p> <pre data-language="python">>>> import os
>>> with open('converted.txt', 'wb') as f:
... f.write(msg.as_bytes(policy=msg.policy.clone(linesep=os.linesep)))
17
</pre> <p>Policy objects can also be combined using the addition operator, producing a policy object whose settings are a combination of the non-default values of the summed objects:</p> <pre data-language="python">>>> compat_SMTP = policy.compat32.clone(linesep='\r\n')
>>> compat_strict = policy.compat32.clone(raise_on_defect=True)
>>> compat_strict_SMTP = compat_SMTP + compat_strict
</pre> <p>This operation is not commutative; that is, the order in which the objects are added matters. To illustrate:</p> <pre data-language="python">>>> 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
</pre> <dl class="py class"> <dt class="sig sig-object py" id="email.policy.Policy">
<code>class email.policy.Policy(**kw)</code> </dt> <dd>
<p>This is the <a class="reference internal" href="../glossary#term-abstract-base-class"><span class="xref std std-term">abstract base class</span></a> for all policy classes. It provides default implementations for a couple of trivial methods, as well as the implementation of the immutability property, the <a class="reference internal" href="#email.policy.Policy.clone" title="email.policy.Policy.clone"><code>clone()</code></a> method, and the constructor semantics.</p> <p>The constructor of a policy class can be passed various keyword arguments. The arguments that may be specified are any non-method properties on this class, plus any additional non-method properties on the concrete class. A value specified in the constructor will override the default value for the corresponding attribute.</p> <p>This class defines the following properties, and thus values for the following may be passed in the constructor of any policy class:</p> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.max_line_length">
<code>max_line_length</code> </dt> <dd>
<p>The maximum length of any line in the serialized output, not counting the end of line character(s). Default is 78, per <span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a>. A value of <code>0</code> or <a class="reference internal" href="constants#None" title="None"><code>None</code></a> indicates that no line wrapping should be done at all.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.linesep">
<code>linesep</code> </dt> <dd>
<p>The string to be used to terminate lines in serialized output. The default is <code>\n</code> because that’s the internal end-of-line discipline used by Python, though <code>\r\n</code> is required by the RFCs.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.cte_type">
<code>cte_type</code> </dt> <dd>
<p>Controls the type of Content Transfer Encodings that may be or are required to be used. The possible values are:</p> <table class="docutils align-default"> <tr>
<td><p><code>7bit</code></p></td> <td><p>all data must be “7 bit clean” (ASCII-only). This means that where necessary data will be encoded using either quoted-printable or base64 encoding.</p></td> </tr> <tr>
<td><p><code>8bit</code></p></td> <td><p>data is not constrained to be 7 bit clean. Data in headers is still required to be ASCII-only and so will be encoded (see <a class="reference internal" href="#email.policy.Policy.fold_binary" title="email.policy.Policy.fold_binary"><code>fold_binary()</code></a> and <a class="reference internal" href="#email.policy.EmailPolicy.utf8" title="email.policy.EmailPolicy.utf8"><code>utf8</code></a> below for exceptions), but body parts may use the <code>8bit</code> CTE.</p></td> </tr> </table> <p>A <code>cte_type</code> value of <code>8bit</code> only works with <code>BytesGenerator</code>, not <code>Generator</code>, because strings cannot contain binary data. If a <code>Generator</code> is operating under a policy that specifies <code>cte_type=8bit</code>, it will act as if <code>cte_type</code> is <code>7bit</code>.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.raise_on_defect">
<code>raise_on_defect</code> </dt> <dd>
<p>If <a class="reference internal" href="constants#True" title="True"><code>True</code></a>, any defects encountered will be raised as errors. If <a class="reference internal" href="constants#False" title="False"><code>False</code></a> (the default), defects will be passed to the <a class="reference internal" href="#email.policy.Policy.register_defect" title="email.policy.Policy.register_defect"><code>register_defect()</code></a> method.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.mangle_from_">
<code>mangle_from_</code> </dt> <dd>
<p>If <a class="reference internal" href="constants#True" title="True"><code>True</code></a>, lines starting with <em>“From “</em> in the body are escaped by putting a <code>></code> in front of them. This parameter is used when the message is being serialized by a generator. Default: <a class="reference internal" href="constants#False" title="False"><code>False</code></a>.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.5: </span>The <em>mangle_from_</em> parameter.</p> </div> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Policy.message_factory">
<code>message_factory</code> </dt> <dd>
<p>A factory function for constructing a new empty message object. Used by the parser when building messages. Defaults to <code>None</code>, in which case <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> is used.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.6.</span></p> </div> </dd>
</dl> <p>The following <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> method is intended to be called by code using the email library to create policy instances with custom settings:</p> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.clone">
<code>clone(**kw)</code> </dt> <dd>
<p>Return a new <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> instance whose attributes have the same values as the current instance, except where those attributes are given new values by the keyword arguments.</p> </dd>
</dl> <p>The remaining <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> methods are called by the email package code, and are not intended to be called by an application using the email package. A custom policy must implement all of these methods.</p> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.handle_defect">
<code>handle_defect(obj, defect)</code> </dt> <dd>
<p>Handle a <em>defect</em> found on <em>obj</em>. When the email package calls this method, <em>defect</em> will always be a subclass of <code>Defect</code>.</p> <p>The default implementation checks the <a class="reference internal" href="#email.policy.Policy.raise_on_defect" title="email.policy.Policy.raise_on_defect"><code>raise_on_defect</code></a> flag. If it is <code>True</code>, <em>defect</em> is raised as an exception. If it is <code>False</code> (the default), <em>obj</em> and <em>defect</em> are passed to <a class="reference internal" href="#email.policy.Policy.register_defect" title="email.policy.Policy.register_defect"><code>register_defect()</code></a>.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.register_defect">
<code>register_defect(obj, defect)</code> </dt> <dd>
<p>Register a <em>defect</em> on <em>obj</em>. In the email package, <em>defect</em> will always be a subclass of <code>Defect</code>.</p> <p>The default implementation calls the <code>append</code> method of the <code>defects</code> attribute of <em>obj</em>. When the email package calls <a class="reference internal" href="#email.policy.Policy.handle_defect" title="email.policy.Policy.handle_defect"><code>handle_defect</code></a>, <em>obj</em> will normally have a <code>defects</code> attribute that has an <code>append</code> method. Custom object types used with the email package (for example, custom <code>Message</code> objects) should also provide such an attribute, otherwise defects in parsed messages will raise unexpected errors.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.header_max_count">
<code>header_max_count(name)</code> </dt> <dd>
<p>Return the maximum allowed number of headers named <em>name</em>.</p> <p>Called when a header is added to an <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> or <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> object. If the returned value is not <code>0</code> or <code>None</code>, and there are already a number of headers with the name <em>name</em> greater than or equal to the value returned, a <a class="reference internal" href="exceptions#ValueError" title="ValueError"><code>ValueError</code></a> is raised.</p> <p>Because the default behavior of <code>Message.__setitem__</code> is to append the value to the list of headers, it is easy to create duplicate headers without realizing it. This method allows certain headers to be limited in the number of instances of that header that may be added to a <code>Message</code> programmatically. (The limit is not observed by the parser, which will faithfully produce as many headers as exist in the message being parsed.)</p> <p>The default implementation returns <code>None</code> for all header names.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.header_source_parse">
<code>header_source_parse(sourcelines)</code> </dt> <dd>
<p>The email package calls this method with a list of strings, each string ending with the line separation characters found in the source being parsed. The first line includes the field header name and separator. All whitespace in the source is preserved. The method should return the <code>(name, value)</code> tuple that is to be stored in the <code>Message</code> to represent the parsed header.</p> <p>If an implementation wishes to retain compatibility with the existing email package policies, <em>name</em> should be the case preserved name (all characters up to the ‘<code>:</code>’ separator), while <em>value</em> should be the unfolded value (all line separator characters removed, but whitespace kept intact), stripped of leading whitespace.</p> <p><em>sourcelines</em> may contain surrogateescaped binary data.</p> <p>There is no default implementation</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.header_store_parse">
<code>header_store_parse(name, value)</code> </dt> <dd>
<p>The email package calls this method with the name and value provided by the application program when the application program is modifying a <code>Message</code> programmatically (as opposed to a <code>Message</code> created by a parser). The method should return the <code>(name, value)</code> tuple that is to be stored in the <code>Message</code> to represent the header.</p> <p>If an implementation wishes to retain compatibility with the existing email package policies, the <em>name</em> and <em>value</em> should be strings or string subclasses that do not change the content of the passed in arguments.</p> <p>There is no default implementation</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.header_fetch_parse">
<code>header_fetch_parse(name, value)</code> </dt> <dd>
<p>The email package calls this method with the <em>name</em> and <em>value</em> currently stored in the <code>Message</code> when that header is requested by the application program, and whatever the method returns is what is passed back to the application as the value of the header being retrieved. Note that there may be more than one header with the same name stored in the <code>Message</code>; the method is passed the specific name and value of the header destined to be returned to the application.</p> <p><em>value</em> may contain surrogateescaped binary data. There should be no surrogateescaped binary data in the value returned by the method.</p> <p>There is no default implementation</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.fold">
<code>fold(name, value)</code> </dt> <dd>
<p>The email package calls this method with the <em>name</em> and <em>value</em> currently stored in the <code>Message</code> for a given header. The method should return a string that represents that header “folded” correctly (according to the policy settings) by composing the <em>name</em> with the <em>value</em> and inserting <a class="reference internal" href="#email.policy.Policy.linesep" title="email.policy.Policy.linesep"><code>linesep</code></a> characters at the appropriate places. See <span class="target" id="index-1"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a> for a discussion of the rules for folding email headers.</p> <p><em>value</em> may contain surrogateescaped binary data. There should be no surrogateescaped binary data in the string returned by the method.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Policy.fold_binary">
<code>fold_binary(name, value)</code> </dt> <dd>
<p>The same as <a class="reference internal" href="#email.policy.Policy.fold" title="email.policy.Policy.fold"><code>fold()</code></a>, except that the returned value should be a bytes object rather than a string.</p> <p><em>value</em> may contain surrogateescaped binary data. These could be converted back into binary data in the returned bytes object.</p> </dd>
</dl> </dd>
</dl> <dl class="py class"> <dt class="sig sig-object py" id="email.policy.EmailPolicy">
<code>class email.policy.EmailPolicy(**kw)</code> </dt> <dd>
<p>This concrete <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> provides behavior that is intended to be fully compliant with the current email RFCs. These include (but are not limited to) <span class="target" id="index-2"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a>, <span class="target" id="index-3"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc2047.html"><strong>RFC 2047</strong></a>, and the current MIME RFCs.</p> <p>This policy adds new header parsing and folding algorithms. Instead of simple strings, headers are <code>str</code> subclasses with attributes that depend on the type of the field. The parsing and folding algorithm fully implement <span class="target" id="index-4"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc2047.html"><strong>RFC 2047</strong></a> and <span class="target" id="index-5"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a>.</p> <p>The default value for the <a class="reference internal" href="#email.policy.Policy.message_factory" title="email.policy.Policy.message_factory"><code>message_factory</code></a> attribute is <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a>.</p> <p>In addition to the settable attributes listed above that apply to all policies, this policy adds the following additional attributes:</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.6: </span><a class="footnote-reference brackets" href="#id2" id="id1">1</a></p> </div> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.utf8">
<code>utf8</code> </dt> <dd>
<p>If <code>False</code>, follow <span class="target" id="index-6"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a>, supporting non-ASCII characters in headers by encoding them as “encoded words”. If <code>True</code>, follow <span class="target" id="index-7"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc6532.html"><strong>RFC 6532</strong></a> and use <code>utf-8</code> encoding for headers. Messages formatted in this way may be passed to SMTP servers that support the <code>SMTPUTF8</code> extension (<span class="target" id="index-8"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc6531.html"><strong>RFC 6531</strong></a>).</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.refold_source">
<code>refold_source</code> </dt> <dd>
<p>If the value for a header in the <code>Message</code> object originated from a <a class="reference internal" href="email.parser#module-email.parser" title="email.parser: Parse flat text email messages to produce a message object structure."><code>parser</code></a> (as opposed to being set by a program), this attribute indicates whether or not a generator should refold that value when transforming the message back into serialized form. The possible values are:</p> <table class="docutils align-default"> <tr>
<td><p><code>none</code></p></td> <td><p>all source values use original folding</p></td> </tr> <tr>
<td><p><code>long</code></p></td> <td><p>source values that have any line that is longer than <code>max_line_length</code> will be refolded</p></td> </tr> <tr>
<td><p><code>all</code></p></td> <td><p>all values are refolded.</p></td> </tr> </table> <p>The default is <code>long</code>.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.header_factory">
<code>header_factory</code> </dt> <dd>
<p>A callable that takes two arguments, <code>name</code> and <code>value</code>, where <code>name</code> is a header field name and <code>value</code> is an unfolded header field value, and returns a string subclass that represents that header. A default <code>header_factory</code> (see <a class="reference internal" href="email.headerregistry#module-email.headerregistry" title="email.headerregistry: Automatic Parsing of headers based on the field name"><code>headerregistry</code></a>) is provided that supports custom parsing for the various address and date <span class="target" id="index-9"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5322.html"><strong>RFC 5322</strong></a> header field types, and the major MIME header field stypes. Support for additional custom parsing will be added in the future.</p> </dd>
</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.content_manager">
<code>content_manager</code> </dt> <dd>
<p>An object with at least two methods: get_content and set_content. When the <a class="reference internal" href="email.message#email.message.EmailMessage.get_content" title="email.message.EmailMessage.get_content"><code>get_content()</code></a> or <a class="reference internal" href="email.message#email.message.EmailMessage.set_content" title="email.message.EmailMessage.set_content"><code>set_content()</code></a> method of an <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> object is called, it calls the corresponding method of this object, passing it the message object as its first argument, and any arguments or keywords that were passed to it as additional arguments. By default <code>content_manager</code> is set to <a class="reference internal" href="email.contentmanager#email.contentmanager.raw_data_manager" title="email.contentmanager.raw_data_manager"><code>raw_data_manager</code></a>.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.4.</span></p> </div> </dd>
</dl> <p>The class provides the following concrete implementations of the abstract methods of <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a>:</p> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.header_max_count">
<code>header_max_count(name)</code> </dt> <dd>
<p>Returns the value of the <a class="reference internal" href="email.headerregistry#email.headerregistry.BaseHeader.max_count" title="email.headerregistry.BaseHeader.max_count"><code>max_count</code></a> attribute of the specialized class used to represent the header with the given name.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.header_source_parse">
<code>header_source_parse(sourcelines)</code> </dt> <dd>
<p>The name is parsed as everything up to the ‘<code>:</code>’ and returned unmodified. The value is determined by stripping leading whitespace off the remainder of the first line, joining all subsequent lines together, and stripping any trailing carriage return or linefeed characters.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.header_store_parse">
<code>header_store_parse(name, value)</code> </dt> <dd>
<p>The name is returned unchanged. If the input value has a <code>name</code> attribute and it matches <em>name</em> ignoring case, the value is returned unchanged. Otherwise the <em>name</em> and <em>value</em> are passed to <code>header_factory</code>, and the resulting header object is returned as the value. In this case a <code>ValueError</code> is raised if the input value contains CR or LF characters.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.header_fetch_parse">
<code>header_fetch_parse(name, value)</code> </dt> <dd>
<p>If the value has a <code>name</code> attribute, it is returned to unmodified. Otherwise the <em>name</em>, and the <em>value</em> with any CR or LF characters removed, are passed to the <code>header_factory</code>, and the resulting header object is returned. Any surrogateescaped bytes get turned into the unicode unknown-character glyph.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.fold">
<code>fold(name, value)</code> </dt> <dd>
<p>Header folding is controlled by the <a class="reference internal" href="#email.policy.EmailPolicy.refold_source" title="email.policy.EmailPolicy.refold_source"><code>refold_source</code></a> policy setting. A value is considered to be a ‘source value’ if and only if it does not have a <code>name</code> attribute (having a <code>name</code> attribute means it is a header object of some sort). If a source value needs to be refolded according to the policy, it is converted into a header object by passing the <em>name</em> and the <em>value</em> with any CR and LF characters removed to the <code>header_factory</code>. Folding of a header object is done by calling its <code>fold</code> method with the current policy.</p> <p>Source values are split into lines using <a class="reference internal" href="stdtypes#str.splitlines" title="str.splitlines"><code>splitlines()</code></a>. If the value is not to be refolded, the lines are rejoined using the <code>linesep</code> from the policy and returned. The exception is lines containing non-ascii binary data. In that case the value is refolded regardless of the <code>refold_source</code> setting, which causes the binary data to be CTE encoded using the <code>unknown-8bit</code> charset.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.EmailPolicy.fold_binary">
<code>fold_binary(name, value)</code> </dt> <dd>
<p>The same as <a class="reference internal" href="#email.policy.EmailPolicy.fold" title="email.policy.EmailPolicy.fold"><code>fold()</code></a> if <a class="reference internal" href="#email.policy.Policy.cte_type" title="email.policy.Policy.cte_type"><code>cte_type</code></a> is <code>7bit</code>, except that the returned value is bytes.</p> <p>If <a class="reference internal" href="#email.policy.Policy.cte_type" title="email.policy.Policy.cte_type"><code>cte_type</code></a> is <code>8bit</code>, non-ASCII binary data is converted back into bytes. Headers with binary data are not refolded, regardless of the <code>refold_header</code> setting, since there is no way to know whether the binary data consists of single byte characters or multibyte characters.</p> </dd>
</dl> </dd>
</dl> <p>The following instances of <a class="reference internal" href="#email.policy.EmailPolicy" title="email.policy.EmailPolicy"><code>EmailPolicy</code></a> provide defaults suitable for specific application domains. Note that in the future the behavior of these instances (in particular the <code>HTTP</code> instance) may be adjusted to conform even more closely to the RFCs relevant to their domains.</p> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.default">
<code>email.policy.default</code> </dt> <dd>
<p>An instance of <code>EmailPolicy</code> with all defaults unchanged. This policy uses the standard Python <code>\n</code> line endings rather than the RFC-correct <code>\r\n</code>.</p> </dd>
</dl> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.SMTP">
<code>email.policy.SMTP</code> </dt> <dd>
<p>Suitable for serializing messages in conformance with the email RFCs. Like <code>default</code>, but with <code>linesep</code> set to <code>\r\n</code>, which is RFC compliant.</p> </dd>
</dl> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.SMTPUTF8">
<code>email.policy.SMTPUTF8</code> </dt> <dd>
<p>The same as <code>SMTP</code> except that <a class="reference internal" href="#email.policy.EmailPolicy.utf8" title="email.policy.EmailPolicy.utf8"><code>utf8</code></a> is <code>True</code>. Useful for serializing messages to a message store without using encoded words in the headers. Should only be used for SMTP transmission if the sender or recipient addresses have non-ASCII characters (the <a class="reference internal" href="smtplib#smtplib.SMTP.send_message" title="smtplib.SMTP.send_message"><code>smtplib.SMTP.send_message()</code></a> method handles this automatically).</p> </dd>
</dl> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.HTTP">
<code>email.policy.HTTP</code> </dt> <dd>
<p>Suitable for serializing headers with for use in HTTP traffic. Like <code>SMTP</code> except that <code>max_line_length</code> is set to <code>None</code> (unlimited).</p> </dd>
</dl> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.strict">
<code>email.policy.strict</code> </dt> <dd>
<p>Convenience instance. The same as <code>default</code> except that <code>raise_on_defect</code> is set to <code>True</code>. This allows any policy to be made strict by writing:</p> <pre data-language="python">somepolicy + policy.strict
</pre> </dd>
</dl> <p>With all of these <a class="reference internal" href="#email.policy.EmailPolicy" title="email.policy.EmailPolicy"><code>EmailPolicies</code></a>, the effective API of the email package is changed from the Python 3.2 API in the following ways:</p> <ul class="simple"> <li>Setting a header on a <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> results in that header being parsed and a header object created.</li> <li>Fetching a header value from a <a class="reference internal" href="email.compat32-message#email.message.Message" title="email.message.Message"><code>Message</code></a> results in that header being parsed and a header object created and returned.</li> <li>Any header object, or any header that is refolded due to the policy settings, is folded using an algorithm that fully implements the RFC folding algorithms, including knowing where encoded words are required and allowed.</li> </ul> <p>From the application view, this means that any header obtained through the <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> is a header object with extra attributes, whose string value is the fully decoded unicode value of the header. Likewise, a header may be assigned a new value, or a new header created, using a unicode string, and the policy will take care of converting the unicode string into the correct RFC encoded form.</p> <p>The header objects and their attributes are described in <a class="reference internal" href="email.headerregistry#module-email.headerregistry" title="email.headerregistry: Automatic Parsing of headers based on the field name"><code>headerregistry</code></a>.</p> <dl class="py class"> <dt class="sig sig-object py" id="email.policy.Compat32">
<code>class email.policy.Compat32(**kw)</code> </dt> <dd>
<p>This concrete <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> is the backward compatibility policy. It replicates the behavior of the email package in Python 3.2. The <a class="reference internal" href="#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>policy</code></a> module also defines an instance of this class, <a class="reference internal" href="#email.policy.compat32" title="email.policy.compat32"><code>compat32</code></a>, that is used as the default policy. Thus the default behavior of the email package is to maintain compatibility with Python 3.2.</p> <p>The following attributes have values that are different from the <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a> default:</p> <dl class="py attribute"> <dt class="sig sig-object py" id="email.policy.Compat32.mangle_from_">
<code>mangle_from_</code> </dt> <dd>
<p>The default is <code>True</code>.</p> </dd>
</dl> <p>The class provides the following concrete implementations of the abstract methods of <a class="reference internal" href="#email.policy.Policy" title="email.policy.Policy"><code>Policy</code></a>:</p> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Compat32.header_source_parse">
<code>header_source_parse(sourcelines)</code> </dt> <dd>
<p>The name is parsed as everything up to the ‘<code>:</code>’ and returned unmodified. The value is determined by stripping leading whitespace off the remainder of the first line, joining all subsequent lines together, and stripping any trailing carriage return or linefeed characters.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Compat32.header_store_parse">
<code>header_store_parse(name, value)</code> </dt> <dd>
<p>The name and value are returned unmodified.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Compat32.header_fetch_parse">
<code>header_fetch_parse(name, value)</code> </dt> <dd>
<p>If the value contains binary data, it is converted into a <a class="reference internal" href="email.header#email.header.Header" title="email.header.Header"><code>Header</code></a> object using the <code>unknown-8bit</code> charset. Otherwise it is returned unmodified.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Compat32.fold">
<code>fold(name, value)</code> </dt> <dd>
<p>Headers are folded using the <a class="reference internal" href="email.header#email.header.Header" title="email.header.Header"><code>Header</code></a> folding algorithm, which preserves existing line breaks in the value, and wraps each resulting line to the <code>max_line_length</code>. Non-ASCII binary data are CTE encoded using the <code>unknown-8bit</code> charset.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.policy.Compat32.fold_binary">
<code>fold_binary(name, value)</code> </dt> <dd>
<p>Headers are folded using the <a class="reference internal" href="email.header#email.header.Header" title="email.header.Header"><code>Header</code></a> folding algorithm, which preserves existing line breaks in the value, and wraps each resulting line to the <code>max_line_length</code>. If <code>cte_type</code> is <code>7bit</code>, non-ascii binary data is CTE encoded using the <code>unknown-8bit</code> charset. Otherwise the original source header is used, with its existing line breaks and any (RFC invalid) binary data it may contain.</p> </dd>
</dl> </dd>
</dl> <dl class="py data"> <dt class="sig sig-object py" id="email.policy.compat32">
<code>email.policy.compat32</code> </dt> <dd>
<p>An instance of <a class="reference internal" href="#email.policy.Compat32" title="email.policy.Compat32"><code>Compat32</code></a>, providing backward compatibility with the behavior of the email package in Python 3.2.</p> </dd>
</dl> <h4 class="rubric">Footnotes</h4> <dl class="footnote brackets"> <dt class="label" id="id2">
<code>1</code> </dt> <dd>
<p>Originally added in 3.3 as a <a class="reference internal" href="../glossary#term-provisional-package"><span class="xref std std-term">provisional feature</span></a>.</p> </dd> </dl> <div class="_attribution">
<p class="_attribution-p">
© 2001–2023 Python Software Foundation<br>Licensed under the PSF License.<br>
<a href="https://docs.python.org/3.12/library/email.policy.html" class="_attribution-link">https://docs.python.org/3.12/library/email.policy.html</a>
</p>
</div>
|
