summaryrefslogtreecommitdiff
path: root/devdocs/python~3.12/library%2Femail.generator.html
blob: a2bcf2e4dbfd8e251f7ef2942286f001c156f1be (plain)
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
 <span id="email-generator-generating-mime-documents"></span><h1>email.generator: Generating MIME documents</h1> <p><strong>Source code:</strong> <a class="reference external" href="https://github.com/python/cpython/tree/3.12/Lib/email/generator.py">Lib/email/generator.py</a></p>  <p>One of the most common tasks is to generate the flat (serialized) version of the email message represented by a message object structure. You will need to do this if you want to send your message via <a class="reference internal" href="smtplib#smtplib.SMTP.sendmail" title="smtplib.SMTP.sendmail"><code>smtplib.SMTP.sendmail()</code></a> or the <a class="reference internal" href="nntplib#module-nntplib" title="nntplib: NNTP protocol client (requires sockets). (deprecated)"><code>nntplib</code></a> module, or print the message on the console. Taking a message object structure and producing a serialized representation is the job of the generator classes.</p> <p>As with 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> module, you aren’t limited to the functionality of the bundled generator; you could write one from scratch yourself. However the bundled generator knows how to generate most email in a standards-compliant way, should handle MIME and non-MIME email messages just fine, and is designed so that the bytes-oriented parsing and generation operations are inverses, assuming the same non-transforming <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>policy</code></a> is used for both. That is, parsing the serialized byte stream via the <a class="reference internal" href="email.parser#email.parser.BytesParser" title="email.parser.BytesParser"><code>BytesParser</code></a> class and then regenerating the serialized byte stream using <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a> should produce output identical to the input <a class="footnote-reference brackets" href="#id3" id="id1">1</a>. (On the other hand, using the generator on an <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> constructed by program may result in changes to the <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> object as defaults are filled in.)</p> <p>The <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> class can be used to flatten a message into a text (as opposed to binary) serialized representation, but since Unicode cannot represent binary data directly, the message is of necessity transformed into something that contains only ASCII characters, using the standard email RFC Content Transfer Encoding techniques for encoding email messages for transport over channels that are not “8 bit clean”.</p> <p>To accommodate reproducible processing of SMIME-signed messages <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> disables header folding for message parts of type <code>multipart/signed</code> and all subparts.</p> <dl class="py class"> <dt class="sig sig-object py" id="email.generator.BytesGenerator">
<code>class email.generator.BytesGenerator(outfp, mangle_from_=None, maxheaderlen=None, *, policy=None)</code> </dt> <dd>
<p>Return a <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a> object that will write any message provided to the <a class="reference internal" href="#email.generator.BytesGenerator.flatten" title="email.generator.BytesGenerator.flatten"><code>flatten()</code></a> method, or any surrogateescape encoded text provided to the <a class="reference internal" href="#email.generator.BytesGenerator.write" title="email.generator.BytesGenerator.write"><code>write()</code></a> method, to the <a class="reference internal" href="../glossary#term-file-like-object"><span class="xref std std-term">file-like object</span></a> <em>outfp</em>. <em>outfp</em> must support a <code>write</code> method that accepts binary data.</p> <p>If optional <em>mangle_from_</em> is <code>True</code>, put a <code>&gt;</code> character in front of any line in the body that starts with the exact string <code>"From "</code>, that is <code>From</code> followed by a space at the beginning of a line. <em>mangle_from_</em> defaults to the value of the <a class="reference internal" href="email.policy#email.policy.Policy.mangle_from_" title="email.policy.Policy.mangle_from_"><code>mangle_from_</code></a> setting of the <em>policy</em> (which is <code>True</code> for the <a class="reference internal" href="email.policy#email.policy.compat32" title="email.policy.compat32"><code>compat32</code></a> policy and <code>False</code> for all others). <em>mangle_from_</em> is intended for use when messages are stored in Unix mbox format (see <a class="reference internal" href="mailbox#module-mailbox" title="mailbox: Manipulate mailboxes in various formats"><code>mailbox</code></a> and <a class="reference external" href="https://www.jwz.org/doc/content-length.html">WHY THE CONTENT-LENGTH FORMAT IS BAD</a>).</p> <p>If <em>maxheaderlen</em> is not <code>None</code>, refold any header lines that are longer than <em>maxheaderlen</em>, or if <code>0</code>, do not rewrap any headers. If <em>manheaderlen</em> is <code>None</code> (the default), wrap headers and other message lines according to the <em>policy</em> settings.</p> <p>If <em>policy</em> is specified, use that policy to control message generation. If <em>policy</em> is <code>None</code> (the default), use the policy associated with the <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 passed to <code>flatten</code> to control the message generation. See <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>email.policy</code></a> for details on what <em>policy</em> controls.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.2.</span></p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.3: </span>Added the <em>policy</em> keyword.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>The default behavior of the <em>mangle_from_</em> and <em>maxheaderlen</em> parameters is to follow the policy.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.BytesGenerator.flatten">
<code>flatten(msg, unixfrom=False, linesep=None)</code> </dt> <dd>
<p>Print the textual representation of the message object structure rooted at <em>msg</em> to the output file specified when the <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a> instance was created.</p> <p>If the <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>policy</code></a> option <a class="reference internal" href="email.policy#email.policy.Policy.cte_type" title="email.policy.Policy.cte_type"><code>cte_type</code></a> is <code>8bit</code> (the default), copy any headers in the original parsed message that have not been modified to the output with any bytes with the high bit set reproduced as in the original, and preserve the non-ASCII <em class="mailheader">Content-Transfer-Encoding</em> of any body parts that have them. If <code>cte_type</code> is <code>7bit</code>, convert the bytes with the high bit set as needed using an ASCII-compatible <em class="mailheader">Content-Transfer-Encoding</em>. That is, transform parts with non-ASCII <em class="mailheader">Content-Transfer-Encoding</em> (<em class="mailheader">Content-Transfer-Encoding: 8bit</em>) to an ASCII compatible <em class="mailheader">Content-Transfer-Encoding</em>, and encode RFC-invalid non-ASCII bytes in headers using the MIME <code>unknown-8bit</code> character set, thus rendering them RFC-compliant.</p> <p>If <em>unixfrom</em> is <code>True</code>, print the envelope header delimiter used by the Unix mailbox format (see <a class="reference internal" href="mailbox#module-mailbox" title="mailbox: Manipulate mailboxes in various formats"><code>mailbox</code></a>) before the first of the <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> headers of the root message object. If the root object has no envelope header, craft a standard one. The default is <code>False</code>. Note that for subparts, no envelope header is ever printed.</p> <p>If <em>linesep</em> is not <code>None</code>, use it as the separator character between all the lines of the flattened message. If <em>linesep</em> is <code>None</code> (the default), use the value specified in the <em>policy</em>.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.BytesGenerator.clone">
<code>clone(fp)</code> </dt> <dd>
<p>Return an independent clone of this <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a> instance with the exact same option settings, and <em>fp</em> as the new <em>outfp</em>.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.BytesGenerator.write">
<code>write(s)</code> </dt> <dd>
<p>Encode <em>s</em> using the <code>ASCII</code> codec and the <code>surrogateescape</code> error handler, and pass it to the <em>write</em> method of the <em>outfp</em> passed to the <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a>’s constructor.</p> </dd>
</dl> </dd>
</dl> <p>As a convenience, <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> provides the methods <a class="reference internal" href="email.message#email.message.EmailMessage.as_bytes" title="email.message.EmailMessage.as_bytes"><code>as_bytes()</code></a> and <code>bytes(aMessage)</code> (a.k.a. <a class="reference internal" href="email.message#email.message.EmailMessage.__bytes__" title="email.message.EmailMessage.__bytes__"><code>__bytes__()</code></a>), which simplify the generation of a serialized binary representation of a message object. For more detail, see <a class="reference internal" href="email.message#module-email.message" title="email.message: The base class representing email messages."><code>email.message</code></a>.</p> <p>Because strings cannot represent binary data, the <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> class must convert any binary data in any message it flattens to an ASCII compatible format, by converting them to an ASCII compatible <em class="mailheader">Content-Transfer_Encoding</em>. Using the terminology of the email RFCs, you can think of this as <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> serializing to an I/O stream that is not “8 bit clean”. In other words, most applications will want to be using <a class="reference internal" href="#email.generator.BytesGenerator" title="email.generator.BytesGenerator"><code>BytesGenerator</code></a>, and not <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a>.</p> <dl class="py class"> <dt class="sig sig-object py" id="email.generator.Generator">
<code>class email.generator.Generator(outfp, mangle_from_=None, maxheaderlen=None, *, policy=None)</code> </dt> <dd>
<p>Return a <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> object that will write any message provided to the <a class="reference internal" href="#email.generator.Generator.flatten" title="email.generator.Generator.flatten"><code>flatten()</code></a> method, or any text provided to the <a class="reference internal" href="#email.generator.Generator.write" title="email.generator.Generator.write"><code>write()</code></a> method, to the <a class="reference internal" href="../glossary#term-file-like-object"><span class="xref std std-term">file-like object</span></a> <em>outfp</em>. <em>outfp</em> must support a <code>write</code> method that accepts string data.</p> <p>If optional <em>mangle_from_</em> is <code>True</code>, put a <code>&gt;</code> character in front of any line in the body that starts with the exact string <code>"From "</code>, that is <code>From</code> followed by a space at the beginning of a line. <em>mangle_from_</em> defaults to the value of the <a class="reference internal" href="email.policy#email.policy.Policy.mangle_from_" title="email.policy.Policy.mangle_from_"><code>mangle_from_</code></a> setting of the <em>policy</em> (which is <code>True</code> for the <a class="reference internal" href="email.policy#email.policy.compat32" title="email.policy.compat32"><code>compat32</code></a> policy and <code>False</code> for all others). <em>mangle_from_</em> is intended for use when messages are stored in Unix mbox format (see <a class="reference internal" href="mailbox#module-mailbox" title="mailbox: Manipulate mailboxes in various formats"><code>mailbox</code></a> and <a class="reference external" href="https://www.jwz.org/doc/content-length.html">WHY THE CONTENT-LENGTH FORMAT IS BAD</a>).</p> <p>If <em>maxheaderlen</em> is not <code>None</code>, refold any header lines that are longer than <em>maxheaderlen</em>, or if <code>0</code>, do not rewrap any headers. If <em>manheaderlen</em> is <code>None</code> (the default), wrap headers and other message lines according to the <em>policy</em> settings.</p> <p>If <em>policy</em> is specified, use that policy to control message generation. If <em>policy</em> is <code>None</code> (the default), use the policy associated with the <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 passed to <code>flatten</code> to control the message generation. See <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>email.policy</code></a> for details on what <em>policy</em> controls.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.3: </span>Added the <em>policy</em> keyword.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>The default behavior of the <em>mangle_from_</em> and <em>maxheaderlen</em> parameters is to follow the policy.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.Generator.flatten">
<code>flatten(msg, unixfrom=False, linesep=None)</code> </dt> <dd>
<p>Print the textual representation of the message object structure rooted at <em>msg</em> to the output file specified when the <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> instance was created.</p> <p>If the <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>policy</code></a> option <a class="reference internal" href="email.policy#email.policy.Policy.cte_type" title="email.policy.Policy.cte_type"><code>cte_type</code></a> is <code>8bit</code>, generate the message as if the option were set to <code>7bit</code>. (This is required because strings cannot represent non-ASCII bytes.) Convert any bytes with the high bit set as needed using an ASCII-compatible <em class="mailheader">Content-Transfer-Encoding</em>. That is, transform parts with non-ASCII <em class="mailheader">Content-Transfer-Encoding</em> (<em class="mailheader">Content-Transfer-Encoding: 8bit</em>) to an ASCII compatible <em class="mailheader">Content-Transfer-Encoding</em>, and encode RFC-invalid non-ASCII bytes in headers using the MIME <code>unknown-8bit</code> character set, thus rendering them RFC-compliant.</p> <p>If <em>unixfrom</em> is <code>True</code>, print the envelope header delimiter used by the Unix mailbox format (see <a class="reference internal" href="mailbox#module-mailbox" title="mailbox: Manipulate mailboxes in various formats"><code>mailbox</code></a>) before the first of the <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> headers of the root message object. If the root object has no envelope header, craft a standard one. The default is <code>False</code>. Note that for subparts, no envelope header is ever printed.</p> <p>If <em>linesep</em> is not <code>None</code>, use it as the separator character between all the lines of the flattened message. If <em>linesep</em> is <code>None</code> (the default), use the value specified in the <em>policy</em>.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.2: </span>Added support for re-encoding <code>8bit</code> message bodies, and the <em>linesep</em> argument.</p> </div> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.Generator.clone">
<code>clone(fp)</code> </dt> <dd>
<p>Return an independent clone of this <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> instance with the exact same options, and <em>fp</em> as the new <em>outfp</em>.</p> </dd>
</dl> <dl class="py method"> <dt class="sig sig-object py" id="email.generator.Generator.write">
<code>write(s)</code> </dt> <dd>
<p>Write <em>s</em> to the <em>write</em> method of the <em>outfp</em> passed to the <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a>’s constructor. This provides just enough file-like API for <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> instances to be used in the <a class="reference internal" href="functions#print" title="print"><code>print()</code></a> function.</p> </dd>
</dl> </dd>
</dl> <p>As a convenience, <a class="reference internal" href="email.message#email.message.EmailMessage" title="email.message.EmailMessage"><code>EmailMessage</code></a> provides the methods <a class="reference internal" href="email.message#email.message.EmailMessage.as_string" title="email.message.EmailMessage.as_string"><code>as_string()</code></a> and <code>str(aMessage)</code> (a.k.a. <a class="reference internal" href="email.message#email.message.EmailMessage.__str__" title="email.message.EmailMessage.__str__"><code>__str__()</code></a>), which simplify the generation of a formatted string representation of a message object. For more detail, see <a class="reference internal" href="email.message#module-email.message" title="email.message: The base class representing email messages."><code>email.message</code></a>.</p> <p>The <a class="reference internal" href="#module-email.generator" title="email.generator: Generate flat text email messages from a message structure."><code>email.generator</code></a> module also provides a derived class, <a class="reference internal" href="#email.generator.DecodedGenerator" title="email.generator.DecodedGenerator"><code>DecodedGenerator</code></a>, which is like the <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> base class, except that non-<em class="mimetype">text</em> parts are not serialized, but are instead represented in the output stream by a string derived from a template filled in with information about the part.</p> <dl class="py class"> <dt class="sig sig-object py" id="email.generator.DecodedGenerator">
<code>class email.generator.DecodedGenerator(outfp, mangle_from_=None, maxheaderlen=None, fmt=None, *, policy=None)</code> </dt> <dd>
<p>Act like <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a>, except that for any subpart of the message passed to <a class="reference internal" href="#email.generator.Generator.flatten" title="email.generator.Generator.flatten"><code>Generator.flatten()</code></a>, if the subpart is of main type <em class="mimetype">text</em>, print the decoded payload of the subpart, and if the main type is not <em class="mimetype">text</em>, instead of printing it fill in the string <em>fmt</em> using information from the part and print the resulting filled-in string.</p> <p>To fill in <em>fmt</em>, execute <code>fmt % part_info</code>, where <code>part_info</code> is a dictionary composed of the following keys and values:</p> <ul class="simple"> <li>
<code>type</code> – Full MIME type of the non-<em class="mimetype">text</em> part</li> <li>
<code>maintype</code> – Main MIME type of the non-<em class="mimetype">text</em> part</li> <li>
<code>subtype</code> – Sub-MIME type of the non-<em class="mimetype">text</em> part</li> <li>
<code>filename</code> – Filename of the non-<em class="mimetype">text</em> part</li> <li>
<code>description</code> – Description associated with the non-<em class="mimetype">text</em> part</li> <li>
<code>encoding</code> – Content transfer encoding of the non-<em class="mimetype">text</em> part</li> </ul> <p>If <em>fmt</em> is <code>None</code>, use the following default <em>fmt</em>:</p>  <p>“[Non-text (%(type)s) part of message omitted, filename %(filename)s]”</p>  <p>Optional <em>_mangle_from_</em> and <em>maxheaderlen</em> are as with the <a class="reference internal" href="#email.generator.Generator" title="email.generator.Generator"><code>Generator</code></a> base class.</p> </dd>
</dl> <h4 class="rubric">Footnotes</h4> <dl class="footnote brackets"> <dt class="label" id="id3">
<code>1</code> </dt> <dd>
<p>This statement assumes that you use the appropriate setting for <code>unixfrom</code>, and that there are no <a class="reference internal" href="email.policy#module-email.policy" title="email.policy: Controlling the parsing and generating of messages"><code>email.policy</code></a> settings calling for automatic adjustments (for example, <a class="reference internal" href="email.policy#email.policy.EmailPolicy.refold_source" title="email.policy.EmailPolicy.refold_source"><code>refold_source</code></a> must be <code>none</code>, which is <em>not</em> the default). It is also not 100% true, since if the message does not conform to the RFC standards occasionally information about the exact original text is lost during parsing error recovery. It is a goal to fix these latter edge cases when possible.</p> </dd> </dl> <div class="_attribution">
  <p class="_attribution-p">
    &copy; 2001&ndash;2023 Python Software Foundation<br>Licensed under the PSF License.<br>
    <a href="https://docs.python.org/3.12/library/email.generator.html" class="_attribution-link">https://docs.python.org/3.12/library/email.generator.html</a>
  </p>
</div>