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
That definitely can use improvement. I just want to make sure we're clear that putting that kind of improvement on the roadmap isn't going to solve today's issue for you.
It still looks to me like this problem is specific to DO. Other companies manage to avoid it somehow. I said avoid rather than solve because I don't think they're jumping through special hoops. What is DO (meaning the DO/Mandrill combination) doing that's different? If Mandrill's huge scale breaks customary functionality that works perfectly well at smaller scales, then Mandrill isn't properly handling its scaling problems.
I've lost track of the timeline of this. If rm_'s address was blocked after hours of failures and was still blocked 12 hours later, maybe that's not so bad, unblocking after 24h might be reasonable. I'm used to mail delivery failures retrying (maybe at slower intervals) for 5 days. Maybe I'm behind the times about that though.
@willie With all due respect, I don't think you or I know what other companies deal with behind the scenes. Do they have less customers therefore problems of scale are not yet there? Do they have more thoughtful customer base surrounding the issue? Do they have constant delivery problems just not to you or the people you interact with?
My point is everyone wants to be a backseat driver, and feedback is absolutely welcome, but most things don't just happen just because someone was bored and dumb, most things are reactions to real problems. If you're truly interested in knowing the full depth of why everyone does everything they do, you're going to need to expand your career to cover all of those bases. People aren't writing white papers for every situation, you just can't know everything all the time unless you're in the trenches with the people dealing with it. In the case of why transactional email providers commonly do something, the best assumption you or I can make is "something happened that led them to do so." Reinventing the wheel every time usually leads you down the same path everyone else went down, and that can be a really expensive thing to do just to be able to answer every single in depth question reliably on an internet forum.
I'm glad I'm not in the email business but imagining myself as a potential Mandrill user, I see a red flag and have to ask how alternative providers handle the situation. Why can't Mandrill do what it looks like everyone else does? Do they all have the same issue?
Yes I do stuff at that scale, though not email.
For all i know your "everyone else" consists of companies running their own outbound mail servers and/or dealing with bounces at a lower scale so that being more forgiving isn't yet damaging to them.
Questions based on assumptions can't always end in having clear answers. What other companies do is a great reason to ask if you're doing it right, but ultimately every company has to deal with it's own challenges, what other companies do is not always available for instant purchase or replication.
All it takes is a guy on PMS to make a big deal out of nothing. That's how LET drama begins a lot of times.
DO should add let to their block list?
I think that has become rare. We know now what Mandrill does. I'd like to know whether SES etc. do the same thing.
Then a follow-up would be why Mandrill does X if SES doesn't. Has Mandrill been around longer and had more volume/experience and therefore learned a lesson SES hasn't or is it simply a matter of having a better product team? Kind of like how a new host has better performance on nearly empty nodes?
Those are the hard things to answer, which happen to also be the things you generally don't get to know without being there or having insight from the same perspective (which requires equivalent scale).
Fun things to figure out but fairly exhausting for extremely minimal gain. I mean just look at how much time you and I have spent theorizing it because I wasn't given the opportunity to click one button. Even devaluing our time significantly, we've already exhausted the value of clicking that button a few hundred times.
SES isn't that new. I'd expect it's at least as big as Mandrill. I don't think Mandrill is the oldest or biggest of these services. There are others out there too. If they're doing a better job than Mandrill with this issue, that speaks in their favor. Certainly if I were shopping for one right now, this is something I'd try to find out about. It hadn't occurred to me before.
Does Mandrill live up to reasonable customer expectations right now? I'd have to say no. Is that because those expectations are unrealistic and the rest of the transactional email industry unavoidably can't help failing the same way? I hope not, but will admit there is some uncertainty.
What is it that you do at the DO end to unblock someone's email with Mandrill? If it involves contacting humans at Mandrill, that's awful. If it's something that can be automated but isn't because it doesn't come up often enough to be worth it, then ok, it might be something to chuck on a list for whenever.
Button that uses API. Isn't that it can't be automated, just something I think might have unintended consequences so it takes deeper consideration. Unintended consequences at scale can be legendary, and disastrous if caused in response to one off scenarios.
Meh, security is a bitch. Let's just use a master password, 1234. No email required.
Others don't mis-use mass mailing services designed for low-importance bulk mails (with the corresponding retry policies) for important account-related messages.
Internet.bs:
OVH:
Linode:
They might use some third-party solution for sending out mass newsletters or advertising promotions, but when it comes to important stuff, it is handled directly by their servers -- as it should.
I'm sure they have no customers complaining about their important emails not reaching the customer either. Those IP ranges definitely aren't blocked anywhere. Good eye. Will implement those IP ranges at MXroute and drop mailchannels for cheap 100% delivery to all email services.
Complaining to OVH is like barking at a dog that's licking his balls. No reactions whatsoever. I know this because I have a small VPS with them.
Perhaps, you should do the same, @Jarland
You may be on to something.
Quite the colorful analogy, Dean "Red Rocket" K.
SES also stops sending to a email address if it detects a permanent failure. The address is put into a suppression list as its called there. You then need to remove it manually if you want SES to attempt sending again.
Well the question as I see it is not about how to enforce 2FA, or which email service to use. It goes deep down to the morality of your company.
If your email cannot reach a user, it is the user's email provider that is wrongfully blocking your message, and you should ask your customer to tell their email providers to fix it (or simply choose a better provider). Similarly, as long as a user has the correct login credentials, he should have the right to use a service, unless the account is found to be abusing the service. True, the reality is complicated--accounts get hacked, and only IP addresses from the big players have the best deliverability. Making such extra efforts to proactively protect users' account, and to use 3rd-party email services to maximize deliverability IMO is just a move to "protect" and "maximize" your profit.
It's like the trolley problem and people have different choices. Of course as a businessman you can argue from the utilitarian view that it is a necessary measure, but I, for one, am not a big fan of this category of strategies. A similar problem is, should we as a provider simply block all orders from a specific country, heck, in the name to "protect" other customers from those fraudsters, abusers, etc, etc?
And how were those password nabbed? Moreover, No, 2FA is also often used to protect against e.g. mitm.
Sorry, my clumsy error. It should be "... implemented after massive data loss ..."
2FA is in the title, 2FA is how it was called here, and it is at least meant to be 2FA, so let's not split hairs.
This thread is leaving the path of what's healthy here at LET. Way too many facts which, to make it worse, add complexity.
Just provide a box of stones and accuse some target to throw the stones at. With a little luck the guilt question is not crystal clear and after some to and fro a nice drama is created.
One could, for example, accuse myself. I'm an ideal candidate. Have no account at DO or mxroute, didn't suffer any even very subjective damage from them but have a nick starting with 'b' which quite obviously is despicable and typical for an evildoer.
It's not meant to be 2FA. DO have actual 2FA. This is just some additional account security.
... by other sites getting their databases dumped, and by client systems getting compromised, like I already said?
Whoever is using 2FA for that purpose is using it wrong. That's not what it's for.
Well ok, but when is a failure designated as permanent? Say several connection attempts fail over a 5 minute period, then there's no more messages to that address til the next day, but then another one comes. Does SES decide that a 5 minute failure is permanent?
Usually by a database breach at some site foolish enough to store passwords in the clear, or with a hash susceptible to dictionary searches. See haveibeenpwned.com for lookup access to some collections like that.
SSL helps with that. Sure, the crappy PKI system won't stop the KGB or other powerful attackers, but it will slow down the average script kiddie.
See:
Circles.
@jarland Agreed. He’s blowing this WAY out of proportion.
To @rm_: what you need to understand is that 99.99% of people make conscious efforts to keep their personal information accurate with a provider (this includes your email address). It was because of your failure to keep DO updated with your valid details that caused you to get locked out. Plus, it seems like you’re not willing to take any of the blame. Mind you, @jarland already tried to help. You’re just being a stupid nuisance.
I don't know if I'd go that far. People have way too many accounts to keep up to date and it's not surprising if something slips. Rm_'s email address stopped working (apparently on purpose), then he fixed it, and (I think) is complaining that the DO system won't automatically send a new access code to the now-working email address when he clicks the request on a new login attempt.
As a user and system builder I sympathize somewhat with the complaint, but the obvious thing to do when something like that is busted is open a ticket: "hey my email works now, can I get another code?". Rm_ is apparently unwilling to do that, for reasons I don't understand at all (maybe I missed an explanation further up or maybe there wasn't one). Either way, something strange is going on.
@willie Yeah, I made that figure up in the moment. I’d be confident enough to say this though: it’s not DigitalOcean’s fault that rm_ messed up his email.
The biggest question is: who with the right mind sets the billing email to the same company that hosts the email? It just doesn’t make any sense.
I know I can probably do that, but I'm not sure what sort of hoops they will want me to go through, to have the access restored. Sending scans of my documents showing real name? Proof of address? Phone number for SMS verification? Who knows.
For the record I do not use fake details at providers, which doesn't mean I'll be willing to put up with sending documents in a situation that is described here.
In any case, what's more important than my particular account, is to point out a bad practice being conducted by a provider, and hopefully try to influence them to have this fixed. BTW I'm glad that there are people in this thread who understood what the problem is, and agree that it is a bug to be fixed.
I'm not sure how this question came up to you from this thread. My E-Mail was not and is not hosted at DO. But if this is just something unrelated you wanted to ask, then I doubt many people would actually do that.
Didn't you say, or imply that, somewhere at the beginning here? Perhaps I'm confused.