New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Mandrill automatically halts outbound mail to addresses that fail. Mandrill customers have to remove that block at Mandrill to allow their system to continue to send emails to that address. How you arrive at "lose your account" from that is a mental leap that I'm afraid I can't make with you. There is no logical interpretation of my words that lead there.
The reason you'll lose your account is because you don't care if we can reach you, you won't contact support, and you won't give me the email address to look it up and remove the block for you. I know you won't, because of two reasons:
We have a long history Roman, your methods are not new to me. My consistent bluntness with you, however, is a bit new. Here's to hoping it works as a method of reaching you. Insanity is doing the same thing and expecting different results, being overly nice to you has gotten me nowhere over the years.
Way to take this personal and present everything as somehow my fault. I still have my login and correct password, yet I can't login, and you blame me. Should be simple enough in any other case, but not with DO.
Roman, you've been doing this to me for years. You find something to complain about, you blow it out of proportion, and then refuse to accept help. Yes it's personal that you hate me and don't trust me. Why wouldn't it be?
I'm offering you help, but the complaint is of more value to you than the help. This has been your modus operandi for as long as I've known you. You don't actually want the things you say you want, you want things to complain about. You're welcome to, I'm not going to stand in your way, but I want to make myself very clear that I am able to help you and you are refusing.
The moment I'm standing here and offering you assistance and you refuse it, I do gain logical ground for blaming you for your situation. Want to take that away from me? Reach out to me at jdonnell @ digitalocean.com.
I don't talk to other people this way, me and you go way back Roman. There is historical context for it. I've always liked you and wanted to be helpful, and you've always been rude to me for it. Treat people how you want to be treated, you seem to not like it when people treat you the same way you treat them.
Maybe the MX record was not present at the very beginning, so that the negative cache interval in SOA record was used?
Couldn't the verification code be resent later, or does it lock down your account if the first code got lost?
You're not my wife and I have not stopped beating you, I see.
Because the issue is not so much about my particular account, but more globally with the practice that we observe here: locking out legitimate users out of their accounts for ridiculous reasons, and changing policies to introduce arbitrary requirements without user consent. If you want to help, work on improving in those areas -- not solve it as a one-off for "someone you know", and continue doing that to others.
Doesn’t half the internet do this sort of thing these days? It’s a mild inconvenience, but it’s also alerted me to an attempted breach a couple of times.
It had a bogus MX record with TTL of 10 minutes, then I changed it to a set of good MX records also with TTL of 10 minutes. Yet some 12 hours later it still doesn't work. But as Jarland already clarified, their system doesn't give second chances, and on a failure it won't retry anymore.
It now says "we sent you a code", but in reality they don't even send it anymore, as Jarland confirmed. As a third-party unbiased person, would you agree this is even ...normal?
I think we need the fluffy rabbit over here @bsdguy
It is normal. As you said yourself, you’ve been careless and had your details not updated with the provider. Provider tries to help you, you refuse to cooperate. It’s on you.
You're welcome to share that feedback, but this has helped a great number of people and the only reason it's causing a problem for you is because you refuse the path to resolution. You are the roadblock, not the change.
Your consent is not required to make the platform more secure. You can argue whether or not it does, but I know first hand that it did based on actual results, and I don't need to discuss theory.
Why do you think this is a one-off solution because you know me? Contact form, support email, twitter, facebook, message me, same result everywhere. I may be faster because I know you, but those are all valid options to resolve the issue. If you want to resolve issues without contacting support, you should keep your contact information up to date. You've willfully introduced a problem and you're willfully refusing the solution.
I'll rescind the offer to contact me personally via email to resolve it. Today is Amelia's first birthday party and I've got a lot to do. I'll be around on my phone, but I'm not going to sit by my computer and watch my email for someone who doesn't want my assistance.
Love you bro, maybe one day you'll treat me like a human being and let me be one for you as well.
Funnily enough I have never had such situation before, neither with a VPS provider, nor with any other service.
As for if we take a more constructive look to what should be done, it is basically an insanity to send login verification E-Mails via the same channel used for promotional and newsletter E-Mails -- and with the same non-retry policy on failures.
Verifications should be sent independently via their own separate channel and always retried on each user request.
Happy birthday Amelia.
Yes, it seems to be quite common nowadays. However, similar to the Incero non-issue earlier this week, it wouldn't be LET if something trivial were turned into a 10-page "discussion".
Surely you weren't expecting actual content!
Not a complete list, but off the top of my head:
If you are just making a point that DO arbitrarily applied this email re-verification policy w/o consent then I feel that they just followed the trend and are not alone in this. Now a days every other service seems to be doing it and they never ask me before. Depending on the change in parameters which vary from service to service (inactivity, device change, IP, location), they ask for this re-verification.
One the other hand, if you want access to your account restored then you are kinda stuck if you do not supply them your email address. Its out of DO's or Jarland's hands if you do not do that. Not just Mandrill, every other transactional email provider does blacklist failed email addresses which has to be cleared manually then.
Take a stand, never visit DO again.
Repeating so it doesn't get lost:
@jarland would you agree? Can you help getting that implemented? Or is it too complex / too expensive to have a separate sending mechanism for important mailings, and easier to just keep using the non-critical bulk one for that too.
I have to say that the inability of the user to get a retry sounds unusual to me. Usually I see something like "we have just emailed you an access token. If you don't see it within 2 minutes, make sure to check your spam folder. If you still don't see it, click here to have us send another one". Email is unreliable and sometimes has to be retried.
I'm afraid it's not that simple. We'd have to ditch transactional email providers, build our own mail cluster just for this, and then add it to an already growing SPF record. The overhead here for an outlier situation is greater than the overhead of having the support team simply click one button on our internal tooling that clears the block with Mandrill over the API. Especially if you consider how much a popular unnamed provider tends to hate receiving email from our IP space.
It makes sense on the surface but there's a lot more that goes into making changes like that and justifying their overhead. We have a support team because you can't address every outlier scenario with automation.
And keep in mind this is all stated only to address someone who has refused to enable 2FA as well, which is a bit of an odd thing to focus so many resources on workarounds for. It's a hard conversation to have in that respect, and a better one that comes out of it is "How could we instead make 2FA more attractive?"
Can't really say I am unbiased. But I do agree that retry is a must.
Say a customer was careless enough to make a login attempt when his email servers is temporarily out of order (which is usually unbeknownst to him). It is not his fault that he failed to update the details.
Not giving another chance to retry and forcing the customer to contact support is okay (for me), but what a hassle.
That is not possible even if they use their own mailing system. How can they retry infinitely to a 550 address and end up getting their mail server blacklisted by the remote server?
I see that too, and continue seeing that every time on further attempts. But the point is that "under the hood" they don't actually send it anymore after the first time.
At least give feedback to user rather than lying every time that "we have just emailed you..."
I edited above but I'd like to reiterate, I think the direction on this is the wrong one. The right question here, I think, is "What would make 2FA more attractive?"
Spending so much time discussing the workarounds and how to do them systematically is basically acceptance of a lack of adoption of the actual, proper security mechanism. Using 2FA prevents this secondary measure entirely. How do I get you to want to use 2FA?
It should retry at least upon user's request. There must already be pretty tight rate-limiting on systems as "secure" as digital ocean.
Should it? Or should people use 2FA in the first place and not even see this?
If DO is displaying a message saying it re-sent the token but it didn't actually do so, that sounds buggy. My post was about what other sites do. I get the idea that DO did this lockdown in response to an incident and couldn't wait around dealing with quirks of its email confirmation system, but the confirmation system's inability to retry does seem out of step with general industry practice and ought to be treated as a bug in its own right. If it displays a message saying that it retried when it didn't, that's a separate and simpler bug that should be easier to fix.
2FA and privacy don't go hand in hand :P
Who says it doesn't retry? We're talking about someone who intentionally disabled their email. How many retries is that going to take?
No, but "password only" and security also don't fit in the same hand
You did:
^
And now you're trying to muddle things up. I've re-enabled it shortly after realizing why the verification doesn't come. In effect it tried maybe 1 or 2 times over a period of 10 minutes with a bogus MX, then the real one was back in place. Yet almost a day later there's still not a single retry to that one.