Simplify install to just `pip install django-anymail`.
(Rather than `... django-anymail[mailgun]`
All of the ESPs so far require requests, so just move
that into the base requirements. (Chances are your
Django app already needs requests for some other
reason, anyway.)
Truly unique ESP dependencies (e.g., boto for
AWS-SES) could still use the setup extra features
mechanism.
* Add filename param to attach_inline_image
* Add attach_inline_image_file function
(parallels EmailMessage.attach and attach_file)
* Use `Content-Disposition: inline` to decide
whether an attachment should be handled inline
(whether or not it's an image, and whether or not
it has a Content-ID)
* Stop conflating filename and Content-ID, for
ESPs that allow both. (Solves problem where
Google Inbox was displaying inline images
as attachments when sent through SendGrid.)
Webhook tests define a local signal receiver function,
so connect it using the `weak=False` option to set
a good example.
(This isn't technically needed in the tests: the test receivers
are only connected while their definitions are still in scope,
so they couldn't possibly be garbage collected. But it doesn't
hurt, and it's good practice in case the test code gets copied.)
Also update the webhook docs to have a direct link to
Django's "listening to signals" info.
* Break apart massive _send call
* Try to facilitate subclassing
* Centralize fail_silently handling during _send
* Include original EmailMessage as exception attr
* Add common base DjrillException
* Simplify backend by moving logic
to describe errors into base DjrillException
* Add NotSerializableForMandrillError
for JSON serialization errors
Raise new MandrillRecipientsRefused exception
when Mandrill returns 'reject' or 'invalid' status
for *all* recipients of a message.
(Similar to Django's SMTP email backend raising
SMTPRecipientsRefused.)
Add setting MANDRILL_IGNORE_RECIPIENT_STATUS
to override the new exception.
Trap JSON parsing errors in Mandrill API response,
and raise MandrillAPIError for them. (Helps with #93.)
Closes#80.
Closes#81.
Master is now 1.5.0-dev (to avoid accidents),
but the 1.4 branch is expected to be the end
of the 1.x line.
2.0 development will begin on a separate branch soon.
