Eamil6 Working Notes
====================

:rfc:`3454` may be relevant at some point.  It describes how to 'prepare'
unicode strings so you can compare them for equality and have some chance
that they will be equal (modulo spelling) even if entered by different
methods and/or different people.  Python has the :mod:`stringprep`
module for working with this protocol.

It might be interesting to have the parser generate a "spam score"
based on how many RFC rules the message breaks or bends.  I'd give
the items scores and base the score magnitude on the occurence of the
defects/bends in spam/ham data samples.  :issue:`1155362` made me think of
this, I'll try to add other relevant issues and notes to this paragraph:
:issue:`1162477`, :issue:`1672568`.

`Notice`__ of the partial funding of the grant proposal.

__ http://www.python.org/psf/records/board/minutes/2009-12-14/#funding-for-python-3-email-module

Exarkun has suggested an API involving attributes for headers (msg.subject)
and keyword arguments to set them (Message(subject='hello')).  Extended:

    Message(from=AddressHeader, to=AddressHeader, body=text, attachments=(list-of-Messages))

Gregg Lind wants a helper that takes a fn and turns it into an attachable Message
that uses mimetypes to figure out the type.

    Message(..., attachments=[MIMEPart.from_filename(name) for name in attachment_filenames])

:rfc:`1428` may make interesting background reading.

May need to fish out the most recent RFCs for ISO-2022.  Found a note that DICOM uses
"the full ISO-2022 standard", which is apparently harder to parse than the subsets.
That's presumably the codec module's responsibility and not ours, though.
:rfc:`2237` covers ISO-2022-JP-1.
:rfc:`1554` covers ISO-2022-JP-2.

http.client's parser_headers method goes out of its way to cater to some
idiosyncracies of the email parser (and one of the problems is the inability
to handle bytes).  This should be fixed.

It also has a special subclass that defines a method getallmatchingheaders,
which is used in exactly one place, and I'm thinking is probably redundant with
get_all (which is used elsewhere in the module) even now, much less with
email6.