| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
The value is already a string.
|
|
|
|
| |
It is already decoded.
|
|
|
|
|
|
| |
Python3 only supports "new-style" classes (those extending object),
and we don't need to explicitly inherit from this root class any more.
See http://pylint-messages.wikidot.com/messages:c1001
|
|
|
|
| |
This is more elegant and efficient way to handle this.
|
|
|
|
|
|
|
|
|
|
|
| |
In python 3 with the use of Policy objects (other than the Compat32
object which maintains the previous (python 2.x and <=3.2) API) change
the way headers work, and the old Header object is no longer used. This
is rather convenient in that python now implements many of the rules
required for sepcial header types, but it changes the API. This fixes
that by encoding the Header objects to strings.
Fixes #1289
|
|
|
|
| |
They are not needed for python >= 3.0.
|
|
|
|
|
|
| |
Attachments are encoded into bytes, but the file we open to write them
into was being opened in text mode. That doesn't work. Open the file in
bytes mode instead.
|
| |
|
|
|
|
|
| |
This dict key is deleted, and then promptly replaced. The deletion is
useless, the replacement does the same thing.
|
|
|
|
|
| |
Using file_ instead of FILE still avoids shadowing the builtin, but also
doesn't stand out so much.
|
|
|
|
|
|
| |
- use relative imports if possible
- group imports into standard library, third party, and alot modules
- sort imports alphabetically
|
| |
|
|
|
|
|
|
|
|
| |
Some versions of AppleMail apparently send out attachements
with incorrect mimetypes "application/octetstream"
(instead of "application/octet-stream").
This patch makes alot use libmagic on the attachments content
to determine the actual content type.
|
|
|
|
| |
mostly automatically fixed
|
|
|
|
|
|
| |
this uses a email.header.Header obj for
attachments-parts Content-Disposition header
to ensure their filename-parameters obey RFC2184
|
|
|
|
| |
cf issue #472
|
|
|
|
| |
this fixes a few broken links and duplicate module defs in the sphinx docs
|
|
|
|
| |
when calling decode_header
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
previously, If the wrapped email-part did not contain
a filename parm in its Content-Disposition, decode_header was
called with a None value, which rightfully breaks.
This makes Attachment.get_filename return None in this case
as mentioned in its docstring
|
|/
|
|
|
| |
that writes out its content to a given filehandle.
this is also used internally for save.
|
|
|