djangoproject.com uses non-existent From address, and no way to resend confirmation email

[Matthew Somerville]

Confirmation emails sent by djangoproject.com (e.g. to register) are sent out From: noreply@… - this address does not exist, and so any server that performs sender verification - ​http://en.wikipedia.org/wiki/Callback_verification - will not accept the mail for delivery. Coupled with the fact it appears to be impossible to have a confirmation email resent, this means the username I originally signed up with (dracos) is now inaccessible (I went through a password reset, and trying to log in at ​http://www.djangoproject.com/accounts/login/ says "Please correct the errors below:" with no errors listed - presumably it is wanting to say "This account has not been confirmed." which is not a field error.) I also only realised this was an issue because I had access to the mail log files of a server en route - others might not know why their email does not arrive if their ISP has implemented sender verification.

Could noreply@ change to be an accepted email address (that either /dev/nulls incoming email or auto-replies saying mail to that address is not read) and/or could there be a way to resend a confirmation email (this might be useful in other circumstances too)?

[Aymeric Augustin]

Issue A: password recovery for unactivated accounts

I could reproduce the registration problem as follows:

• create an account, but ignore the activation email
• request a password reset, click the link, change the password
• attempt to log in on the website => failure, see attached screenshot
• attempt to log in on Trac => failure

I did this twice to reduce the PEBCAK-factor.

Note that using my own username (that works) and a wrong password triggers the same not-so-helpful error screen.

---

Issue B: lack of discoverability of the password reset form

Trac has "Login" and "Register" links.

"Login" goes straight to browser authentication, so we can't add "Password lost" next to the login box, like most websites do.

Adding "Password lost" between "Login" and "Register" would be useful — currently the link to /accounts/password/reset/ in buried in ​https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/

[Aymeric Augustin]

Actually issue B was already reported in #15584. Let this ticket be only about issue A.

[Aymeric Augustin]

#16170 was a duplicate, it suggests a fix (run "cleanupregistration" in a cron).

[Aymeric Augustin]

Change UI/UX from NULL to False.

[anonymous]

Clearly, the problem here is that the account isn't active.

The password reset form, handled by django.contrib.auth.views.password_reset_confirm, works (and indirectly confirms that the email address is valid). But it doesn't activate the account, so it's still impossible to log in.

Solution 1

The register form (provided by django-registration) could be smarter when an account was created but not activated e.g. "the account already exists, I've resent the activation email, please do a password reset if you lost your password".

NB: the ​FAQ also says that django-registration doesn't provide a way for an end user trying to register to re-send an activation email to himself.

Solution 2

We could wrap django.contrib.auth.views.password_reset_confirm in a function that also activates the account when the password reset is successful.

---

Note that both solutions allow someone whose account is disabled to reactivate it. If we implement one of them, we can't use the "active" flag to ban users any longer. I don't know if we've ever used it, or intend to use it, in that way.

[Aymeric Augustin]

This was me, logged out for testing this problem.

[Karen Tracey]

We have used setting a user to not active as a way to ban them, on djangoproject.com.

[Aymeric Augustin]

Dropping email based on sender verification can result in email loss. That's a bug in the email server configuration. At worst mail should be dropped in a "spam" folder where it can be recovered. The Djangoproject.com web server doesn't have the email infrastructure necessary to make the changes you suggested.

Since no-one has found a practical solution that doesn't open security issues in two years, I'm going to close the ticket. Please reopen if you have a concrete suggestion for fixing this. All the code is at ​https://github.com/django/djangoproject.com.