#16041 closed Bug (wontfix)
djangoproject.com uses non-existent From address, and no way to resend confirmation email
Reported by: | Matthew Somerville | Owned by: | nobody |
---|---|---|---|
Component: | *.djangoproject.com | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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)?
Attachments (1)
Change History (10)
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 13 years ago
by , 13 years ago
Attachment: | Screen shot 2011-05-27 at 17.34.37.png added |
---|
comment:3 by , 13 years ago
Actually issue B was already reported in #15584. Let this ticket be only about issue A.
comment:4 by , 13 years ago
#16170 was a duplicate, it suggests a fix (run "cleanupregistration" in a cron).
comment:6 by , 13 years ago
Triage Stage: | Accepted → Design decision needed |
---|
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.
comment:8 by , 13 years ago
We have used setting a user to not active as a way to ban them, on djangoproject.com.
comment:9 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
Issue A: password recovery for unactivated accounts
I could reproduce the registration problem as follows:
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/