Wrong "To" in emails generated by django.utils.log.AdminEmailHandler

[wyattjoh]

After having my Django app running for a few months, I have generated a couple 404 reports. The issue is that they are not getting to me! I checked my MandrillApp logs, and it seems that this is what they are sending the emails to:

   "to": [
            {
                "email": "y",
                "name": ""
            },
            {
                "email": "y",
                "name": ""
            }
        ],

Which doesnt make sense as it does have the ADMINS, MANAGERS, and SERVER_EMAIL defined correctly according to the Django documentation. Maybe I'm doing something wrong, but according to the config for my logging prefs:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
        }
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
    }
}

It seems like it should be sending it properly. Any suggestions?

[medmunds]

Since it's trying to send, but just flubbing the address, I'd guess that the problem is not in your loggers config. It's probably in the addresses you're trying to send to (or a bug in Djrill).

Two things you might look at:

1. Does it work if you don't use Djrill? (Try sending your admin emails through Django's default SMTP backend rather than Djrill, and see if that makes a difference.)
2. What exactly is your ADMINS (or MANAGERS) set to?

Djrill uses python's email.utils.parseaddr and Django's django.core.mail.message.sanitize_address to extract and clean up recipient addresses (in the backend code here). It's possible the specific email address you're trying to send to is running afoul of one or both of those.

[edited: stable link into code]

[medmunds]

@Wyattjoh I haven't been able to reproduce this behavior. If you're still seeing the problem, could you reopen with some additional information to help us track it down? (See my earlier comment for some questions.)

[samkuehn]

@Wyattjoh I had the same problem. Make sure that you have SERVER_EMAIL https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SERVER_EMAIL set to something other than root@localhost (which is the default) - it must be a valid domain.

[bryandunbar]

I'm having this same problem now. Everything appears setup correctly but I'm getting the following (to email = "r"), any suggestions?

"from_email": "noreply@belscoring.com", "subject": "[Django] ERROR (EXTERNAL IP): Internal Server Error: /a-test-comp/main", "to": [ { "type": "to", "email": "r", "name": "" }, { "type": "to", "email": "r", "name": "" } ] },

[medmunds]

@bryandunbar can you show us the lines from your settings.py where you set up ADMINS and SERVER_EMAIL (and MANAGERS if you're setting that)?

(If you don't want to include the actual emails, you can substitute @example.com for the domain portion(s), but please include everything else exactly as it appears in your settings.)

There're some additional troubleshooting suggestions in my earlier comment. If your settings work with Django's default SMTP backend, but not with Djrill, it's definitely something I'd want to fix.

[bryandunbar]

@medmunds - something weird was happening. Seems when I copied the ADMINS setting from the django docs it somehow copied an invisible character. I simply re-keyed the setting by hand and all was good. Sorry for the false alarm! All is good.

[medmunds]

@bryandunbar glad to hear it.

Since you're not the first person to get bit by this, it might be worth making Djrill throw an error if we can detect this case. Do you still have the original ADMINS setting that breaks it?

[medmunds]

Looks like the sanitize_address function we borrow from django.core.mail assumes non-ascii characters are an IDNA and runs them through IDNAToAscii. I wouldn't be surprised if that behaves oddly for something that isn't actually an international domain name.

[bryandunbar]

Actually, looking into it more, I don't think that was the problem after all. I went back through my commit logs and noticed that when I copied it I accidentally deleted the trailing comma in the ADMINS tuple. So, i had this:

ADMINS=(('Bryan Dunbar', 'bryandunbar@test.com'))

and thats what causes it to blow up, need the trailing comma in the tuple, i.e.:

ADMINS=(('Bryan Dunbar', 'bryandunbar@test.com'),)

[medmunds]

Ah, that makes total sense -- thanks for showing the problem.

Django's usually really good about throwing errors when they expect a list but get only a single item, so I'm mildly surprised they don't check for this case. I guess it's tricky because the "single item" can itself be a tuple.

BTW, the latest Django docs are now recommending you set ADMINS to a list of tuples, rather than a tuple of tuples -- probably to make this (extremely common) mistake less likely. [Edit: yep -- that's exactly why they're changing it.]