That is a balance every cloud hosting provider will have to strike internally.
--srs ________________________________ From: mailop <[email protected]> on behalf of Jarland Donnell via mailop <[email protected]> Sent: Saturday, April 8, 2023 10:38:07 AM To: [email protected] <[email protected]> Subject: Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm so done with you I mean if the goal is to try not to appear hostile to customers, rate limiting a port is as bad or worse than blocking it. At least with blocking you know right away, but rate limiting it could create much more time in troubleshooting for an admin that missed the announcement/notification/policy about it. And there are obviously plenty of perfectly fine reasons to burst a port that doesn't even bother anyone but yourself. On 2023-04-07 23:29, Suresh Ramasubramanian via mailop wrote: > Why would you need to blanket block port 25 outbound when you could > rate limit and/or dynamically block it? > > Yes - abusers would then go and get a few hundred thousand accounts > and send maybe 10 emails per vps or droplet or whatever the abused > provider calls it. > > And this is just smtp based abuse - doesn’t count for example : > > Farmed account signup bots > > Bots that will spam through other webmail, social media etc providers > from your IP space > > Assorted other nastiness > > Controlling bad signups becomes essential - and deciding if you want > to keep and retain the sort of customers that trigger blocks. > > The last several types might end up with a nullroute being applied in > extreme cases, as you can appreciate > > --srs > ------------------------- > > From: mailop <[email protected]> on behalf of Jarland Donnell > via mailop <[email protected]> > Sent: Saturday, April 8, 2023 9:47:23 AM > To: [email protected] <[email protected]> > Subject: Re: [mailop] linodeusercontent.com/googleusercontent.com, I'm > so done with you > > To be clear they have an amazing abuse team, easily the first people I > > would hit up if I were hiring in that area. Just top notch admins. > > Blocking SMTP by default makes sense, but settling on the best way to > handle opening it (automated? manual review?) is a discussion that is > very easy to get stuck in. I don't know where they're at on that > discussion by now, but when I left it was something I would have > referred to as "on the table." That to say most of the stakeholders > would entertain the discussion. > > There's likely an attached fear that appearing even remotely hostile > to > customers could quickly drive them to a competitor in a pretty > competitive market. You have to think that as much as people like you > and I would appreciate them doing it, their customers would likely > only > be speaking up about it to say the opposite. You might decrease abuse > complaints but you might also decrease NPS scores, and the people > sending abuse complaints are usually not your customers (so pleasing > them doesn't = $). You might think that reducing IP blacklisting could > > reduce customer complaints and bad NPS scores. I don't think reality > actually plays out that way because Gmail doesn't use external > blacklists (that I'm aware of), and Microsoft will unblock individual > IPs upon request (sometimes after some back and forth), and that > accounts for almost all of what people want anyway. And even that > would > only matter to customers that run mail servers anyway. > > On 2023-04-07 22:02, Neil Anuskiewicz via mailop wrote: >>> On Apr 4, 2023, at 12:42 PM, Jarland Donnell via mailop >>> <[email protected]> wrote: >>> >>> I feel like I've told this story before on the list, but I can't > >>> recall. It always feels worth telling. >>> >>> When I worked at DigitalOcean I took what felt like a year (may > have >>> been less) and I focused more energy than any one person probably > ever >>> has at any cloud provider on tackling spammers based on abuse >>> complaints and recognition of patterns recognized from > investigating >>> abuse complaints. I had Python scripts running through the customer > >>> database at one point looking for key indicators and would mass > shut >>> down accounts either before they started to spam, or not very long >>> after. No false positives. I would shut down a ton of accounts > every >>> day to zero complaints, because they were all exactly what I knew > they >>> were and they knew what they were doing. I had video meetings with >>> several frequent complainers who would come at us from social media > >>> angles to inform them of how their complaints were informing my > work, >>> and what I was doing to try to reduce their complaints. >>> >>> Despite all of that, I don't think I ever succeeded in even > reducing >>> the complaints. The only way to tackle this successfully at a cloud > >>> provider, in my opinion, is to block SMTP traffic and only unblock > it >>> under certain conditions. There will never be enough humans as >>> dedicated and capable as I was, without raising prices to the point > >>> that it drives customers and spammers to the clouds that aren't >>> spending that kind of money on abuse handling, to make a > difference. >>> >>> Just my 2c. >> >> Jarland, I see your point. And with that much abuse it doesn’t > seem >> unreasonable to block SMTP traffic by default. Perhaps there’d be > a >> process of getting it turned on but with some vetting. Anyway, now I > >> kind of understand why so much is coming out of DO. They are trying > to >> bail out a class 5 rapids with a bucket. I wonder why they don’t > look >> at SMTP? This massive, expensive yet inadequate system doesn’t > seem >> likely to be in DO’s interest. Where’s the benefit to DO to do > things >> this way? Just curious. >> >> Neil >> _______________________________________________ >> mailop mailing list >> [email protected] >> https://list.mailop.org/listinfo/mailop > _______________________________________________ > mailop mailing list > [email protected] > https://list.mailop.org/listinfo/mailop > _______________________________________________ > mailop mailing list > [email protected] > https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
