#28922 closed Bug (worksforme)
django.core.mail.send_mail() is not using settings values
Reported by: | Zach Bresser | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | 2.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hello, I have found a bug in django.core.mail.send_mail()
I previously had the following SETTINGS:
# Email settings EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' EMAIL_HOST = 'smtp-relay.gmail.com' EMAIL_HOST_USER = 'my_user' EMAIL_HOST_PASS = 'my_pass EMAIL_PORT = 587 EMAIL_USE_TLS = True
and the following view:
def index(request): """ Return landing page with contact form """ if request.method == 'GET': # Init a blank form form = ContactForm() else: # Grab data from POST, validate, and attempt to send mail. form = ContactForm(request.POST) if form.is_valid(): subject = form.cleaned_data['subject'] from_email = form.cleaned_data['from_email'] message = form.cleaned_data['message'] try: send_mail(subject, message, from_email, [my_to_email]) except BadHeaderError: # Fail on invalid header. return HttpResponse('Invalid Header found.') # After sending, redirect to /success return redirect('success/') # return blank form return render(request, 'index.html', {'form': form})
Which are all correct (I'm using gsuite so I use smtp-relay.gmail.com instead of smtp.gmail.com).
I spent hours working on it, even tried sendgrid, was getting Unauthenticated Senders Not Allowed, and contacted their support and none of us were able to get it to work.
Finally I tried explicitly setting auth_user and auth_pass in send_mail(), and it finally worked.
After importing setting variables:
send_mail(subject, message, from_email, ['my_to_address'], auth_user=EMAIL_HOST_USER, auth_password=EMAIL_HOST_PASS)
This makes it seem like it is not falling back to the settings variables. I attempted to diagnose the issue, but was unable to. I hope someone else can solve where it needs to be set.
Change History (4)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 by , 7 years ago
Can we reopen this? At least in my case it was not falling back to the settings variables.
I am working on getting a test case together for Simon. I work full time so I have been unable to do it today.
comment:4 by , 7 years ago
Zach, feel free to re-open the ticket if you can provide a simplified reproduction test case.
Hello there, I unfortunately cannot reproduce your issue against Django 2.0 and we've got unit tests asserting settings fallbacks work correctly.
Unless you're able to provide a reduced test case to help us reproduce your issue I'm afraid we'll have to close this ticket as worksforme.