Not able to log in using google/launchpad account - confirmation email is not received

Bug #1721803 reported by Abby Murali on 2017-10-06
This bug affects 22 people
Affects Status Importance Assigned to Milestone
OpenStack Community Project
Jeremy Stanley

Bug Description

I'm not able to log in using google/launchpad account.
After entering the email address in the specified textbox, it says a verification mail is send to the email entered but I never received any such mail (even I tried multiple times)

Please help to solve this issue.

Abby Murali.

Changed in openstack-community:
status: New → Confirmed
importance: Undecided → Critical
Changed in openstack-community:
assignee: nobody → Márton Kiss (marton-kiss)
Miguel Antonio Conde (macg9106) wrote :

I have the same error, right now

salehalshaikh (saleh1988) wrote :

Me too, the whole login/signup is broken!!

Nathan (nbutcher78) wrote :

This is probably similar to or related to:

Nathan (nbutcher78) wrote :

Also possibly related, and could well be the cause:

summary: - Not able to log in using google/launchpad account
+ Not able to log in using google/launchpad account - confirmation email
+ is not received
Stefano Maffulli (smaffulli) wrote :

The IP is not listed in Spamhaus anymore. Can you please check if now the confirmation email is sent?

Michael (baaoo) wrote :

I just tried it with a gmail address, as well as with a address that is running on my own mailserver. I didn't receive the mail to the gmail account, but now I did receive the one to my own server. So it seems like something has changed since both didn't work when I posted this bug - however gmail still declines the mail (it's also not in the spam folder there).

Anyways, I've managed using openId for login before - I tried to ask two questions on ask.openstack since and both are declined because the spam filter thinks they are spam. (They certainly aren't though....)

Stefano Maffulli (smaffulli) wrote :

@fungi I need your help to debug this because I have no access to the machine's logs

@baaoo I have approved a post held in moderation by user 'flusel' (mis-classification of spam is a different issue: open a separate issue please if you're not flusel)

Changed in openstack-community:
assignee: Márton Kiss (marton-kiss) → nobody
assignee: nobody → Jeremy Stanley (fungi)
Jeremy Stanley (fungi) wrote :

The MTA logs indicate that Gmail is deferring/rejecting some messages, but Google is notoriously vague about why. Rejections from some other non-Google MTAs note that the server has become listed in the Mailspike blacklist, and per separate bug 1745512 I've put in a delisting request there. Some rejections also claim the server is covered by a Spamhaus PBL entry but their lookup form disagrees as of today at least (perhaps some MTAs are relying on very stale/cached results?).

Stefano Maffulli (smaffulli) wrote :

Google and others require SPF/DKIM and all the modern shebang before they even start looking at incoming mail. Does the domain have all that? Also, there is IP reputation to keep in mind and since this server has come on and off RBLs, the reputation may be low.

The easiest solution is to hook this up to a mail delivering service like Mailgun and similar. Otherwise, maybe consider using which has higher reputation? The drawback is that people may start marking mail from as spam (instead of changing their preferences) and take mail.o.o's reputation down. Tradeoffs :(

Jeremy Stanley (fungi) wrote :

Per the discussion in bug 1745512 this service is also not listed in the SPF record for even though it is sending messages as <email address hidden> so could consider either using a valid address (for which we could set up a corresponding MX record and mailbox somewhere), or get added to the SPF record. That SPF record ends in "?all" though, which per the specification should mean it just gets treated as if there were no SPF record when a sender doesn't match. Nonetheless, some receiving MTAs incorrectly treat ? (neutral) like ~ (softfail) or even - (fail) so it _may_ help.

Google however does not *require* SPF/DKIM before they start looking at incoming mail. We successfully send non-DKIM-signed messages from addresses whose domain part has no corresponding SPF record to addresses on a regular basis, so the answer is certainly somewhat more nuanced than that.

Jeremy Stanley (fungi) wrote :

Since the Mailspike BL removal yesterday I'm seeing basically no rejections in the MTA log (other than for addresses). People who were previously having trouble with new account creation should try again and update here if the confirmation E-mails still don't make it through so we can dig deeper.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers