Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At work we had a Sendgrid account that got compromised, after which all of our comms were (predictably) being marked as spam. After back and forth with support, we were told to continue sending as normal and that "eventually" our genuine emails would stop getting sent to spam.

That lacklustre support response was enough to put me off the service. And then, funnily enough, a few days ago I received a reply from Sendgrid support about another account I had opened for a side project. This reply came in ~2 months late, where I was asking if I could be moved to a different IP range as all my emails were getting blocked by Outlook services due to the shared IP I was assigned being (seemingly) misused by spammers. Again, the response was "just keep trying as normal" and eventually my emails would work... Apparently. That's obviously not a viable business communications strategy.

The funniest part about both these support responses was that despite one of them taking several weeks to get a response, I'm being pinged every few days asking me if my issue was solved. It's all well and good for me to wait months when I need a response as to why all my emails are getting sent to spam, but as soon as the ball is in their court, they don't mind pestering me for a response.

I don't have enough bandwidth for a dedicated IP, so I signed up for a service that requires a credit card even for its free plan, which I believe is a decent enough barrier against spamming.



> That lacklustre support response

Frankly, this makes my blood boil. Full disclosure: I used to work at Sendgrid's competitor (Mailgun) and I'm quite familiar with what's happening under the hood. You allowed spam to be sent from your account. You poisoned the IP space (not just one address you were sending from, but the IP block, affecting others) with spammy reputation. These blocks are expensive and hard to acquire (due to IPv4 shortage) and at this point you have caused more damage to Sendgrid and their customers, than your account value can probably compensate for. What kind of "support" do you expect at this point? You rented a hotel room, gave the key to someone who erected a meth lab there, and you're unhappy with the hotel's reaction?

Sending email on behalf of other people is hard work. The margins are not great, the ratio of spam-to-ham for new accounts is insane, and they're constantly under pressure between their customers who pay very little but want to spam the entire universe (I am sorry but most of you do!) and ESPs not wanting that traffic.


I don't think I did a great job of making clear that my main gripe with their support (taking months) was from a separate, personal account which — from day one — was unable to send non-spam, transactional email to anyone with an Outlook address. In my first example, the account's (for previous employer — not "me") right to support I guess is more debatable...

But I don't think your analogy of the hotel room is totally representative here. Without knowing how someone has had their credentials hacked, it's much more prudent to assume that in your analogy that the room key was pickpocketed / stolen. And then it becomes more of a grey-area as to how much support one can expect.

That being said, I do appreciate your insight on account value, as compromised accounts clearly do constitute a burden that don't end up paying for themselves (even if they aren't "to blame").


> And then it becomes more of a grey-area as to how much support one can expect.

Lol no it doesn't. The comment you replies to uses an excellent example, this isn't someone snuck into your room with the stolen key and messed it up, they burned the room down.

Their support isn't coming after you for the value of the room, but they're also politely telling you they aren't about to replace your belongings or give you a new one


But notice how that doesn't happen very often. Because hotel keys almost never have the room numbers on them. This is basic security the hotel provides to handle the inevitable fact someone is going to lose their credentials. The Sendgrid equivalent would be some mechanism to prevent lost credentials leading to abuses - such as 2FA.


I'm actually intrigued now that I think about this.

What do you think typical hotel keys actually are? They could be arbitrary one shot token random tokens authorised for your stay. When you check out your token, even if you've cloned it, is now useless. This would superficially match the UX you see used, in which each mag stripe card is rewritten before it's handed to you when you check in.

But from what I can tell actually the typical practice is that the card doesn't have a random token, it encodes the room number and period of stay. If you write a new card with a different room number and period it would work, although of course that doesn't make such a thing legal to do.

I think the lack of a human readable number on your typical hotel keycard is because it was easier/ cheaper not because of some security insight. I would be happy to be proved wrong.

Certainly when I've stayed at very small hotels with actual keys, the keys were marked with a room number. These hotels also really wanted the keys back when you check out of course, not because they think you'll come back later and enter a room that's now empty or has a different guest (at such a small hotel that would not be subtle) but because they need it for the next guest.

Anyway. Sendgrid's 2FA doesn't actually block lost credentials. If you have Sendgrid 2FA and use it to get a token for their API, and then the new guy puts it on Pastebin your token will now be abused to send spam.

The main benefit is that the random tokens aren't guessable whereas your brilliant choice of Sendgrid password, "sendgrid" is very guessable. Yes this is some very weak sauce.


Lol what?

Maybe the analogy is getting a little long in the tooth here, but it's been 4 years since you needed basic auth on Sendgrid, so hopefully your username and password can't be found together without a targeted attack (kind of like how your room key getting stolen should only lead to your room with a targeted attack).

On the other hand, many hotels will give you a room number on the sleeve of the card. It's up to you to do the right thing and get rid of it properly

Kind of like Sendgrid has 2FA and it's up to you to set it up.

I mean, I get it, default behaviors don't rely on users doing the right thing, phone 2FA doesn't count even though it would have probably saved OP just fine, etc. If Sendgrid was trying to come after OP for losing their credentials those would all be big factors in me wanting to boycott Sendgrid...

But they're not. They're pretty much just telling OP "it is what it is after you let your account get stolen, eventually you might recover from this but you don't get a free second chance"


I really don’t understand this - I’ve read the parent comment 3 times and can’t see how you you come to the “gave someone the key to someone else” analogy.

Are we interpreting OP differently? From all I can read of available information, they seem to have been reasonable. Sounds more like their neighbor or the previous tenant had a meth lab.


> At work we had a Sendgrid account that got compromised

Parent commenter's account was compromised.

Are you assuming its SendGrid's fault the account was compromised? I'd assume the opposite.


Especially given that they haven't had working 2FA for the longest time, it's not fair to say that OP allowed it or gave someone the keys.

Stretching the analogy, it's more like OP had the room keys lying on a table at a cafe, someone managed to copy the key after sniping a photo and then abused the room while OP was out for the night, and then OP notified the hotel staff once they got back and realized what was going on.

In both cases, OP was unaware of anyone having unauthorized access and it wouldn't have happened (as easily( if the business had better security.


I was sure this was satire of the kind of response you'd get from any run of the mill mail provider. I can't believe you're being serious...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: