Django Password Reset Returns 500 for a Registered Email

Decision: compare two registered paths, not registered versus unknown

Unknown address

No matching user means Django can skip token creation, template rendering, and email submission while still returning the generic completion page.

Registered address

An active user with a usable password enters the account-dependent path and can expose a context, template, token, or email-backend failure.

Useful control

A maintainer-controlled registered account tells you whether the failure is shared by every recoverable user or only the affected account.

What the current public source proves

At NeuroVault revision 9a42434e50b33af8b8967dbc792cde202df4d8ba, the root URL configuration includes Django's built-in authentication URLs, and the dependency file pins Django 4.2.4. The public repository does not define a custom password-reset view in that route.

In Django 4.2.4, PasswordResetForm.get_users() yields only active matching users with usable passwords. The form creates the token context, renders the subject and body, and calls EmailMultiAlternatives.send() inside that matching-user loop. An unknown address can therefore skip every email-specific boundary and still reach the same completion view.

The reviewed NeuroVault settings select the SMTP backend when EMAIL_HOST exists, including TLS, username, password, and an admin@neurovault.org sender. Without EMAIL_HOST, they select a file backend under /tmp/email-fallback. This proves a deployment-dependent backend branch; it does not prove which branch or credential is active in production.

A maintainer reported in the earlier password-reset issue that package-authentication conflicts and broken or changed SMTP credentials and settings had both required repair. That history makes SMTP readiness a sensible check after the current exception stage is captured, but it is not proof of today's root cause.

Trace one request without exposing the account

1. Choose one maintainer-controlled active account with a usable password. Do not use an unknown address as the control.
2. Issue one reset for the control and one for the affected account, each with a different opaque request reference and UTC time.
3. Record only deployed revision, bounded stage, duration, exception class, backend class, and secret-presence booleans in protected telemetry.
4. If both registered accounts fail, inspect shared site context, templates, and SMTP. If only the affected account fails, compare safe account predicates and template-accessed fields.
5. After the backend returns successfully, follow one private message reference through provider events, receiver acceptance, mailbox visibility, and newest-link completion.

Inspect effective email settings by presence, not value

python manage.py shell -c '
from django.conf import settings
print({
  "backend": settings.EMAIL_BACKEND,
  "host_present": bool(getattr(settings, "EMAIL_HOST", None)),
  "username_present": bool(getattr(settings, "EMAIL_HOST_USER", None)),
  "password_present": bool(getattr(settings, "EMAIL_HOST_PASSWORD", None)),
  "tls": bool(getattr(settings, "EMAIL_USE_TLS", False)),
  "from_present": bool(getattr(settings, "DEFAULT_FROM_EMAIL", None)),
})
'

Run this only in the intended deployment. Booleans help identify missing configuration without printing credentials, but they do not prove endpoint syntax, network access, authentication, sender authorization, or delivery.

Use the exception to name the boundary

TemplateDoesNotExist or rendering error

The application found a user but failed before SMTP. Verify the deployed subject, text body, optional HTML template, and fields referenced by them.

Site or token context error

Verify the effective Site or request domain, user primary key, password state, and token generator without logging the resulting URL or token.

DNS, connect, timeout, TLS, or authentication error

The message reached the email backend. Preserve the exact stage and bounded reply class, then repair only the evidenced endpoint or credential boundary.

Backend returned successfully

Move downstream. Check the actual provider account and event before inspecting mailbox folders or public DNS.

Keep anti-enumeration and outage visibility together

A production recovery endpoint should not return one response for unknown addresses and a distinguishable 500 for registered accounts. Return the same bounded public result, but do not silently discard the operational failure. Record the protected stage, alert on failures, and provide a rate-limited recovery or retry path that creates a fresh token only after the cause is corrected.

Do not place raw recipient addresses or reset URLs in analytics. Use an opaque request reference that links the web response, protected exception, email-backend result, and provider event while remaining useless as a recovery credential.

Failure tests before release

1. Submit an unknown address. Prove the public response is generic and the mail backend call count is zero.
2. Submit a controlled active account. Prove exactly one token context is built, the subject and body render, and the backend is called once.
3. Remove the deployed reset template. Prove the public response remains non-enumerating while protected telemetry records a template-stage failure.
4. Force SMTP authentication and TLS failures separately. Prove each has a bounded private class, no credential value is logged, and retries are rate-limited.
5. Return a successful backend handoff but no provider event. Prove the deployment identity is checked before claiming delivery.
6. Record receiver acceptance and test only the newest link. Prove mailbox visibility and password change remain separate outcomes.