There are some examples of possible application configurations on [stackoverflow](http://stackoverflow.com/questions/8428556/django-default-settings-convention-for-pluggable-app) and [djangopatterns](http://djangopatterns.com/patterns/configuration/configure_app/), but nothing about how those solutions affect overriding settings for tests.

I see three possibilities:

1. Don't define `settings.CONFIRM_EMAIL` at all.
   Change `settings.get_confirm_email` to function that takes argument `action` and returns

   ```python
   getattr(
       django_settings,
       'NEWSLETTER_CONFIRM_EMAIL_%s' % action.upper(),
       getattr(
           django_settings, 'NEWSLETTER_CONFIRM_EMAIL', True
       )
   )
   ```
   In views.py use `get_confirm_email(self.action)` instead of `CONFIRM_EMAIL[self.action]`.
   This way we can get rid off `tests.signals` completely.
2. Instead of `from .settings import CONFIRM_EMAIL` and `CONFIRM_EMAIL`
   use `from . import settings as newsletter_settings` and `newsletter_settings.CONFIRM_EMAIL`.
   This way only `settings.CONFIRM_EMAIL` will have to be updated on `setting_changed` signal.
3. Use [django-appconf](https://github.com/jezdez/django-appconf).