Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#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)

Screen shot 2011-05-27 at 17.34.37.png (72.2 KB ) - added by Aymeric Augustin 13 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by Aymeric Augustin, 13 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Aymeric Augustin, 13 years ago

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/

by Aymeric Augustin, 13 years ago

comment:3 by Aymeric Augustin, 13 years ago

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

comment:4 by Aymeric Augustin, 13 years ago

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

comment:5 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:6 by anonymous, 13 years ago

Triage Stage: AcceptedDesign 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:7 by Aymeric Augustin, 13 years ago

This was me, logged out for testing this problem.

comment:8 by Karen Tracey, 13 years ago

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

comment:9 by Aymeric Augustin, 12 years ago

Resolution: wontfix
Status: newclosed

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.

Last edited 12 years ago by Aymeric Augustin (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top