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
It's because of those smart medlesome hackers that we can't just make do with long passwords.
This is why we can't have nice things.
Depending on which interface DO is using for offloading mail to Mandrill (API/SMTP), a feedback can be provided to the user (optionally removing the address from blacklist for first few retry attempts). Something you can consider @Jarland to avoid these issues. 2FA is an alternative but like you know, not everyone wants to use it.
How this trivial matter turned into "I am gonna murder you" debate..., only on LET.
Just one, after the delivery problem is fixed. There is no reason to retry unless there was a problem the first time. And retrying before the problem is fixed also won't work. So if the problem is at the user's end (like this time), there has to be a way for the user to fix the problem, then request a retry and get one, in that order.
Also, if the UI is showing messages saying "ok we just did another retry" when it didn't actually do one, it is telling falsehoods to the user, which should also be fixed.
Ah so it's not just me who thinks that everyone is angry? This is why we need a human emotions font. We need to agree upon a standered.
Well, the guy was hell bent on a witch hunt from the start, so it was going to be a long debate no matter what.
With that outta way, this security feature is pretty useful in preventing an account from getting hacked. I once had my Steam account on verge of getting hacked but since the hacker did not have access to my e-mail (2FA), he never got the code to access my account.
I didn't say there's not a retry threshold or anything like that. If you'd like to ask me how many were sent that failed, I could tell you that too, but you know what that requires. It's largely irrelevant because you actually had disabled your email. We're not talking about everyone else, everyone else can bring me their unique scenarios, we're talking about you.
You don't know if those 1 or 2 times were retried or not. Point being, you disabled your email, there cannot be a retry threshold that is going to resolve your specific situation. If you want to discuss someone else's situation, we might have a different conversation. A smart person running an email server that sends to hundreds of thousands of people has a threshold where they stop sending to failed addresses, and yours is a clear case of an email that should have reached any reasonable threshold.
I definitely get that, it's just that you've gotta understand these things are not implemented on a whim based on isolated one-off feedback. At best they're turned into conversations with all of the stakeholders, and everyone has their opinion there just like everyone here does. An organization that doesn't have a bunch of bored developers just sitting around has to prioritize, and I just don't see "people who intentionally disable their email after refusing to use 2FA" as a huge driver of priority myself. This one-off scenario is solved by a one-off button click that takes no time at all.
@deank
Couldn't companies limmit the number of times somebody could try to log in to 3-5 per ip (and then banned for like an hour or something)?
Sure people who have lodes of ip's could make many attempts but that would take a lot of effort in my oppinion.
I think a lot of places do have that feature also in place now. And that's also what fail2ban does. But that feature also works against me sometimes since I don't use password-remember feature thingy/programs. 3 attempts may be too little... sometimes.
There is, it takes a few seconds to complete. Kind of hard to do when the one-off event is managed by a customer that doesn't want you to do it.
Yes, everyone is very, very, angry.
Someone needs a new hobby.
I'm not angry at all. I was genuinely trying to help someone and I tried a new technique for reaching out to them after failing to get results from doing so for years, it didn't work. You never know until you try.
Me thinks I need to change my avatar back... I am getting confused when @jarland posts.
@jarland
That's good I don't like it when everybody is angry even though most of you are random strangers who I will most likely never meet.
Also I discovered this password manager thing and I love it. Now I can have 20+ character passwords with out forgetting them.
I used to be so bad at remembering passwords and would have to reset accounts alot. I'm using keypass with private and public keys and stuff.
I think you are saying the customer should open a ticket. Rm_ is saying the customer should be able to initiate the retry through the web UI without getting support involved. Most systems I've seen do automate this process (let the user initiate retries) so empirically this issue appears to come up often enough that other companies' software take it into account. At minimum, it lightens their support burden. It's also usual enough that customers like rm_ have come to expect it. DO has made a workaround available and I don't know why rm_ doesn't want to use it, but it's still a workaround instead of doing what the customer expected.
Separately, rm_ claims he can click something to initiate a retry, and the UI says "ok we just sent you another email" when in fact it didn't (or rather, the email gets stuck in DO's delivery system, which from the customer's POV is the same thing as it not being sent). If that is true, I don't see how to call it anything but a bug.
I'm reading "understandably frustrated" rather than "murderously enraged" all around ... but I do tend to misread some of these ever-so-subtle cues in social interactions. (I've had it explained to me that many people of the British persuasion may even become more formally polite as they teeter toward the tipping point of wanton bloodshed, bless their hearts - "U wot mate ...?!")
Maybe one of those threads where injection of humor does not help so much as just remembering to take a deep breath ...
Looking at the discussion as educational to explore intersection of security concerns, systems management, user experience, and customer service - have to appreciate the effort people have been making to articulate their thoughts here.
@Jarland, party, more important.
I told the wife there's plenty of time to cleanup and she started chewing me out, so I'm not doing anything until she lets me help without chewing me out
LET is a party! every day!
Happybirthday to the little one by the way.
http://linuxiso.party
and yes happy birthday
Yeah, wifes...
Me: Let me do that.
Her: Leave it, I will do it.
Her friend comes in and the first thing she says is. He never does anything around the house.
What about Wingdings? Nevermind, it would just look like this...
Is it because there are only 76 genders?
Customer shouldn't be able to impact reputation with transactional providers without limit, human interaction should be required at some point. Someone who had disabled their email intentionally is going to need to reach out at some point here, I don't think that's avoidable in a way that can or should be implemented at scale. I think other companies have other struggles that we may not be aware of.
Remember that while yes that messaging could use some stronger logic, that isn't solving this person's problem. I prefer not to ignore the problem at hand and start talking about the whole. The whole is the sum of the individual experiences. Let each individual tell their story and they can be compiled to notice trend. Trend can drive priority.
There’s 76 now? I knew I should have attended this morning’s conference call.
It was going to be 77, but the dude admitted he just wanted attention, quit Tumblr, and was immediately masticated upon by demonkin.
How many times did rm_ press the retry button? If rm_ pressed the button once and DO retried until Mandrill blocked the address, that problem is at DO's end. Like suppose I email my friend Bob through mxroute and the delivery fails multiple retries and eventually bounces because something is wrong at Bob's end. If he then fixes the problem and I email him again, that second email should work without my having to get mxroute support involved. If mailchannels blocks Bob's address after the first failure, that's an mxroute issue that mxroute should straighten out.
There's a similar thing with fail2ban. If there are too many unsuccessful login attempts from an IP address, the IP gets blocked for 1/2 hour but after that it's unblocked. After too many 1/2 hour blocks it gets blocked for a week (recidive filter). It doesn't get permanently blocked the first time someone mis-remembers their password. Here rm_ says email retry still fails 12 hours after the initial failure. That doesn't sound great. That he had turned off the address on purpose is irrelevant since the behavior was the same as if something was broken at his end. Well-designed systems should be able to deal with stuff breaking.
Good question. Would be happy to get him an answer. Retry time is also an MTA function, not always a button, btw.
This isn't how transactional providers work. They do these things for reasons, you might reach out to them and ask them what things they've seen at their huge scale. You and I both know that what we can do is often not justified or acceptable at scale, things do change, they don't just scale up in a linear fashion and never gain new struggles. They might at MXroute and Mailchannels as well, what works for us today might not tomorrow.
Fail2ban on your individual server is not equivalent to a mail server that needs to communicate with millions of recipient servers. You don't honestly know what well designed means in terms of managing transactional email at scale. Frankly, on some level, neither do I. You can't always guess or assume how issues arise at various scale points. If scaling up these operations was so easy there'd be more people doing it and less people paying the experts to do it for them.
Now, if you'd like the job of learning how to handle these things at scale, I'd vouch for you.
There is no retry button per se, there's just your regular login window. You log-in -- it accepts your username and password as valid (!) -- then tells they sent you a code. And it's the same every time you try, be it 1st or 10th. There is no indication you're retrying something that has previously failed, or that there will be consequences for repeatedly doing so.