email.policy.Policy.header_source_parse()

header_source_parse(sourcelines) 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 (name, value) tuple that is to be stored in the Message to represent the parsed header. If an implementation wishes to retain compatibility with the existing email package policies,

email.policy.Policy.header_max_count()

header_max_count(name) Return the maximum allowed number of headers named name. Called when a header is added to a Message object. If the returned value is not 0 or None, and there are already a number of headers with the name name equal to the value returned, a ValueError is raised. Because the default behavior of Message.__setitem__ 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

email.policy.Policy.header_fetch_parse()

header_fetch_parse(name, value) The email package calls this method with the name and value currently stored in the Message 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 Message; the method is passed the specific name and value of the header destined to be returned to the application. val

email.policy.Policy.handle_defect()

handle_defect(obj, defect) Handle a defect found on obj. When the email package calls this method, defect will always be a subclass of Defect. The default implementation checks the raise_on_defect flag. If it is True, defect is raised as an exception. If it is False (the default), obj and defect are passed to register_defect().

email.policy.Policy.fold_binary()

fold_binary(name, value) The same as fold(), except that the returned value should be a bytes object rather than a string. value may contain surrogateescaped binary data. These could be converted back into binary data in the returned bytes object.

email.policy.Policy.fold()

fold(name, value) The email package calls this method with the name and value currently stored in the Message for a given header. The method should return a string that represents that header “folded” correctly (according to the policy settings) by composing the name with the value and inserting linesep characters at the appropriate places. See RFC 5322 for a discussion of the rules for folding email headers. value may contain surrogateescaped binary data. There should be no surrogateescaped

email.policy.Policy.cte_type

cte_type Controls the type of Content Transfer Encodings that may be or are required to be used. The possible values are: 7bit 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. 8bit 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 ‘binary_fold’ below for an exception), but body parts may use the 8bit CTE. A cte_type value

email.policy.Policy.clone()

clone(**kw) Return a new Policy instance whose attributes have the same values as the current instance, except where those attributes are given new values by the keyword arguments.

email.policy.Policy

class email.policy.Policy(**kw) This is the abstract base class for all policy classes. It provides default implementations for a couple of trivial methods, as well as the implementation of the immutability property, the clone() method, and the constructor semantics. 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

email.policy.EmailPolicy.utf8

utf8 If False, follow RFC 5322, supporting non-ASCII characters in headers by encoding them as “encoded words”. If True, follow RFC 6532 and use utf-8 encoding for headers. Messages formatted in this way may be passed to SMTP servers that support the SMTPUTF8 extension (RFC 6531).