Django-anymail

Latest version: v10.3

Safety actively analyzes 629564 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 6 of 10

1.4

----

*2018-02-08*

Security
~~~~~~~~

* Fix a low severity security issue affecting Anymail v0.2–v1.3: rename setting
WEBHOOK_AUTHORIZATION to WEBHOOK_SECRET to prevent inclusion in Django error
reporting.
(`CVE-2018-1000089 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000089>`__)

*More information*

Django error reporting includes the value of your Anymail WEBHOOK_AUTHORIZATION
setting. In a properly-configured deployment, this should not be cause for concern.
But if you have somehow exposed your Django error reports (e.g., by mis-deploying
with DEBUG=True or by sending error reports through insecure channels), anyone who
gains access to those reports could discover your webhook shared secret. An
attacker could use this to post fabricated or malicious Anymail tracking/inbound events
to your app, if you are using those Anymail features.

The fix renames Anymail's webhook shared secret setting so that Django's error
reporting mechanism will
`sanitize <https://docs.djangoproject.com/en/stable/ref/settings/#debug>`__ it.

If you are using Anymail's event tracking and/or inbound webhooks, you should upgrade
to this release and change "WEBHOOK_AUTHORIZATION" to "WEBHOOK_SECRET" in the ANYMAIL
section of your settings.py. You may also want to
`rotate the shared secret <https://anymail.dev/en/stable/tips/securing_webhooks/#use-a-shared-authorization-secret>`__
value, particularly if you have ever exposed your Django error reports to untrusted
individuals.

If you are only using Anymail's EmailBackends for sending email and have not set up
Anymail's webhooks, this issue does not affect you.

The old WEBHOOK_AUTHORIZATION setting is still allowed in this release, but will issue
a system-check warning when running most Django management commands. It will be removed
completely in a near-future release, as a breaking change.

Thanks to Charlie DeTar (`yourcelf`_) for responsibly reporting this security issue
through private channels.

1.3

Not secure
`v1.2.1`_ release notes, below, if you are using Anymail's tracking webhooks.

Features
~~~~~~~~

* **Inbound handling:** Add normalized inbound message event, signal, and webhooks
for all supported ESPs. (See new
`Receiving mail <https://anymail.dev/en/stable/inbound/>`__ docs.)
This hasn't been through much real-world testing yet; bug reports and feedback
are very welcome.
* **API network timeouts:** For Requests-based backends (all but SparkPost), use a
default timeout of 30 seconds for all ESP API calls, to avoid stalling forever on
a bad connection. Add a REQUESTS_TIMEOUT Anymail setting to override. (See `80`_.)
* **Test backend improvements:** Generate unique tracking `message_id` when using the
`test backend <https://anymail.dev/en/stable/tips/test_backend/>`__;
add console backend for use in development. (See `85`_.)


.. _release_1_2_1:

1.2.1

Not secure
------

*2018-02-02*

Security
~~~~~~~~

* Fix a **moderate severity** security issue affecting Anymail v0.2–v1.2:
prevent timing attack on WEBHOOK_AUTHORIZATION secret.
(`CVE-2018-6596 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6596>`__)

*More information*

If you are using Anymail's tracking webhooks, you should upgrade to this release,
and you may want to rotate to a new WEBHOOK_AUTHORIZATION shared secret (see
`docs <https://anymail.dev/en/stable/tips/securing_webhooks/#use-a-shared-authorization-secret>`__).
You should definitely change your webhook auth if your logs indicate attempted exploit.

(If you are only sending email using an Anymail EmailBackend, and have not set up
Anymail's event tracking webhooks, this issue does not affect you.)

Anymail's webhook validation was vulnerable to a timing attack. A remote attacker
could use this to obtain your WEBHOOK_AUTHORIZATION shared secret, potentially allowing
them to post fabricated or malicious email tracking events to your app.

There have not been any reports of attempted exploit. (The vulnerability was discovered
through code review.) Attempts would be visible in HTTP logs as a very large number of
400 responses on Anymail's webhook urls (by default "/anymail/*esp_name*/tracking/"),
and in Python error monitoring as a very large number of
AnymailWebhookValidationFailure exceptions.

1.2

Not secure
----

*2017-11-02*

Features
~~~~~~~~

* **Postmark:** Support new click webhook in normalized tracking events

1.1

Not secure
----

*2017-10-28*

Fixes
~~~~~

* **Mailgun:** Support metadata in opened/clicked/unsubscribed tracking webhooks,
and fix potential problems if metadata keys collided with Mailgun event parameter
names. (See `76`_, `77`_)

Other
~~~~~

* Rework Anymail's ParsedEmail class and rename to EmailAddress to align it with
similar functionality in the Python 3.6 email package, in preparation for future
inbound support. ParsedEmail was not documented for use outside Anymail's internals
(so this change does not bump the semver major version), but if you were using
it in an undocumented way you will need to update your code.

1.0

Not secure
----

*2017-09-18*

It's official: Anymail is no longer "pre-1.0." The API has been stable
for many months, and there's no reason not to use Anymail in production.

Breaking changes
~~~~~~~~~~~~~~~~

* There are no *new* breaking changes in the 1.0 release, but a breaking change
introduced several months ago in v0.8 is now strictly enforced. If you still have
an EMAIL_BACKEND setting that looks like
"anymail.backends.*espname*.\ *EspName*\ Backend", you'll need to change it to just
"anymail.backends.*espname*.EmailBackend". (Earlier versions had issued a
DeprecationWarning. See the `v0.8`_ release notes.)

Features
~~~~~~~~

* Clean up and document Anymail's
`Test EmailBackend <https://anymail.dev/en/stable/tips/test_backend/>`__
* Add notes on
`handling transient ESP errors <https://anymail.dev/en/stable/tips/transient_errors/>`__
and improving
`batch send performance <https://anymail.dev/en/stable/tips/performance/>`__
* **SendGrid:** handle Python 2 `long` integers in metadata and extra headers

Page 6 of 10

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.