> > I would love a way to give those addresses (in a hashed form) to ESPs > > saying "Look, if somsone is sending to those, it's a bogus list and does > > not pass muster, and you should reject the customer". > > > > I'd love a way to put those addresses in the DNS as a similar flag. "Do > > not allow this address to be added to any mailing lists, promotional > > marketing, or @##$*&#ing google groups, period. Attempts to do so are > > suspect". > > Objection, assumes a level of interest in due diligence on behalf of > mass senders.
I'd love to have access to such infos actually, to identify risky lists not to accept, or to identify risky customers at all. But yes, as Atro said, exposing such addresses, even hashed, could be used as a cleaning machine by senders, list cleaning providers or some ESPs. Talking about anti-fraud, anti-spam at self-service ESP level, that's basically 90% of my team's job at Sendinblue, 90% of what we call Deliverability Team internally. We are having several people full time thinking and developing anti-fraud and anti-spam engines. To identify and kill real spam/fraud accounts networks, kick professional spammers, and identify and educate customers that can be educated (not an easy balance to define) Having aboard accounts sending large volumes of bad spam or fraud is imo not generating revenues, but slowly killing the business. Not being blocked/filtered by destinations is one definitely important thing for us, ESPs, but that's also about overall reputation, external perception and... ethics. Regarding bounce questions, well, bounce management is complicated, pre-blocking addresses on a global level if we already know them as REALLY non existent is the simplest part (but we need to maintain a pretty large list of regexes to match continuously moving bounce reasons). But there's plenty of non explicit bounces that could be handled as both non existing user or policy rejection, we can't prevent emails from being delivered on a global level, there would be way too many complaints from our clients first receiving complaints from their clients non receiving emails, but also directly from recipients. There's compromises to do, unfortunately yes. Also list analysis/vetting is partly possible, as Laura explained, many ESPs are allowing several ways to send emails. Managing contact lists and sending campaigns from an interface, alright yes we can and we do vet clients lists using multiple proprietary ways SMTP or API sending, the client is shooting one by one emails to a relay server, there is no real way to vet a list, we can only score an email flow, signals flow, contents, we are more reactive than proactive here. And regarding the content analysis then, nope this is not a simple topic. This is not only about blocking sentences or regexes, that is generating way too many false positives. This is again a balance between blocking enough bad contents vs not blocking too much legitimate emails. There's many scoring ways, Bayesian statistics, NLP, machine learning, OCR, pattern analysis, there is no perfect solution, and on our side we are using several layers of those to maximise chances to catch frauds, but zero day contents are always complicated to block without blocking legitimate emails as well. Well, just to say "please block this content" is way easier to say than to put it in place :-) _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
