Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#16041 closed Bug (wontfix) uses non-existent From address, and no way to resend confirmation email

Reported by: dracos2 Owned by: nobody
Component: * 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


Confirmation emails sent by (e.g. to register) are sent out From: noreply@… - this address does not exist, and so any server that performs sender 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 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 aaugustin 4 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 4 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 4 years ago by aaugustin

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

Changed 4 years ago by aaugustin

comment:3 Changed 4 years ago by aaugustin

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

comment:4 Changed 4 years ago by aaugustin

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

comment:5 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:6 Changed 3 years ago by anonymous

  • Triage Stage changed from Accepted to 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:7 Changed 3 years ago by aaugustin

This was me, logged out for testing this problem.

comment:8 Changed 3 years ago by kmtracey

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

comment:9 Changed 3 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to 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 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

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