1380434 - Mozilla Sync access is disabled and appears to be related to a bug assigned to my email address "[e-mail]"

Status: RESOLVED INACTIVE

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[D BERGERON]

Attachment: 1358121 - I recently began having problems with Firefox sync associated with email address [e-mail]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

1.attempted to sign into sync on local sync tab.  result was your email was just returned.
tried again and got the same result.
2. attempted to login to Mozilla Support "https://support.mozilla.org" and results were unsuccessful username/password entered responses
2a. requested a password reset link to email [e-mail].  never received password reset link "email".
3. attempted to login to Firefox Accounts "https://accounts.firefox.com" and was able to logon to my account and confirmed no current device attached.




Expected results:

This situation is similar to a bug entered in April "1358121" Last activity posted on 042317. So the fix implemented then appears to be required at this particular time. My email [e-mail] appears to be functioning properly at this time.

Comment 1

[D BERGERON]

Attachment: Bug List-071217.pdf

Comment 2

[Ryan Kelly [:rfkelly]]

>  So the fix implemented then appears to be required at this particular time.

Sorry to hear you're having trouble with this again :-(

One of the fixes that we implemented in response to your original bug, was that an email bounce only blocklists future sends for 24 hours (it used to blocklist that address indefinitely).  So it's possible that things could be working again if you try again today - could you please confirm whether or not this is the case?

If you're still unable to login after 24 hours has passed from the original error, we'll have to debug further.  Adding :jbuck for context; if you get a chance can you please check the bounce state on the above email address?

Comment 3

[D BERGERON]

Just picked up latest update. Welcome back to my nightmare Ryan. I will let you know if the 24 Hr respite works. I may have been inadvertently "resetting" the 24 Hr auto-restore with various retries to logon to Sync. I am not sure if this directly relates to my login to "https://support.mozilla.org/en-US/users/login"; which is now in an inadvertent password reset debacle. I will wait a 24Hr respite before attempting to resolve that login. Therefore I will try both after noon on 7/18.

Comment 4

[Jon Buckley [:jbuck]]

MySQL [fxa]> select * from emailBounces where email = '[e-mail]';
+--------------------------+------------+---------------+---------------+
| email                    | bounceType | bounceSubType | createdAt     |
+--------------------------+------------+---------------+---------------+
| [e-mail] |          3 |             9 | 1499716832377 |
+--------------------------+------------+---------------+---------------+
1 row in set (0.00 sec)

I deleted the bounce record so that Dan can try again:

MySQL [fxa]> delete from emailBounces where email = '[e-mail]';
Query OK, 1 row affected (0.02 sec)

Comment 5

[Ryan Kelly [:rfkelly]]

> bounceType=3, bounceSubType=9, createdAt=1499716832377 

Interesting - decoding the numbers here, this means that on July 10 we received a notification that you flagged one of our emails as spam.  This would certainly stop us from sending you any more emails.  Do you recall doing so around that time at all, perhaps accidentally?  I know I sometimes accidentally hit the "mark as spam" button in gmail because it's right next to "delete".

Comment 6

[D BERGERON]

Before giving you the requested feedback, please help me resolve the other aspect of my problem which is access to Mozilla Support.  I can not enter the correct username/password combination nor can I receive a password reset link for login problems.  Information requested to be sent to the designated email "[e-mail]"; confirmation is given that the requested information has been sent; but nothing is received at the designated email.  Does this situation need the attention of a new bug with the proper function assignment designated? Please advise ASAP.
Moving on....The SPAM issue may not has been my designating an email as SPAM but I have noticed the aol.com SPAM filter sometimes puts "confirmation" emails automatically in the SPAM folder.  If I scan the folder and see a "confirmation" email that I am looking for. I usually open, use it and delete it from SPAM.  As for marking it as SPAM accidentally because they are next to each other in my message display also; If I accidentally mark a message "SPAM" that message is moved to the SPAM folder. If you discover the message accidentally put in SPAM but you may want to keep it; the message can be "unmarked" as SPAM and moved to your inbox. The point being ....finally... :-) If you receive notification that a message has been designated SPAM are you also notified if that message is subsequently "unmarked".  Phew!  I am really not sure which scenario fits your "decoding the numbers" on what you received on July 10. I am more than willing utter "my bad" for my contribution to the confusion. Thanks very much again for straightening my path.

Comment 7

[Ryan Kelly [:rfkelly]]

> please help me resolve the other aspect of my problem which is access to Mozilla Support.
> I can not enter the correct username/password combination nor can I receive a password reset link for login problems.

Unfortunately I can't help with this issue, the login process for support.mozilla.org is a separate product.  Your best bet is probably to file a separate bug describing the login issue here:

  https://bugzilla.mozilla.org/enter_bug.cgi?product=support.mozilla.org&component=General


> I have noticed the aol.com SPAM filter sometimes puts "confirmation" emails automatically in the SPAM folder

Interesting...I've also wondered whether the mail provider doing this automatically, would result in a "spam" notification sent to our service.

>  are you also notified if that message is subsequently "unmarked".

Unfortunately we are not :-(

Although I wonder if we could do something a little clever here, and if the user actually ends up clicking on the link in the email, then they clearly did want the email after all and we could clear the "marked as spam" flag for that user...

Comment 8

[D BERGERON]

Thanks very much for your feedback on my feedback and "good thinking" on possibly securing the loop of the confirmation email by sweeping clean any email blocks occurring between issuance and usage of the confirmation link/email.  Great working with you again to all involved.