Hi all, I'm looking for brainstorming and updated industry "standards" from people handling outgoing SMTP services or ESP exporting APIs to "request subscriptions" (confirmed opt-in).
Not every website uses CAPTCHA and also webforms using CAPTCHA are being abused as even reCAPTCHA have been cracked by some botnet. So, we implemented per-recipient "antiflood" measures and sender throttling, we implemented a distributed near-real-time "recipients black list" in order to identify victims across our infrastructure ASAP and stop the flow. We also implemented some smart solution on the webforms we directly manage with different CAPTCHAs optionally proposed depending on internal and public blacklists of abusive IP/networks and webform filling behaviours: this works fine, but this is only a part of the outgoing flow and we can't do the same on transactional requests submitted via API or sent via authenticated SMTP. We require transactional email to provide us the IP of the user that triggered the email, so we can use our blacklists for them, too, but in this case we can't provide a CAPTCHA in an API or the SMTP conversation, so balancing false positives and false negatives is harder. The bigger the infrastructure the bigger the dataset of abuses adn the more efficient this kind of blacklists works, that's why IP blacklists have been made public and "shared", but I guess a "current subscription bombing victims DNSBL" does not exists and is not even easy to think how it could work at a global scale. Of course one option is to get in touch with every single sender, as soon as we recognize a single request as subscription bombing and explain them how to change their website in order to protect it but this is a big PITA considering most time they use CMS they don't even understand, and because the user is multiple steps away from us (whitelabel services and resellers), but before taking this path I preferred to ask here. One of our transactional IPs have been recently blacklisted by one provider because of a *single* "subscription confirmation request" transactional email received by one of their recipients targeted by a subscription bombing issue. The protections on our side didn't trigger as it was a single request from a clean IP for a recipient we never seen before and there was nothing suspicious in the request to decide to block it. I don't care of that specific blacklisting, but I'd like to be responsible and understand what most of us (postmasters) expect from each other in the real world (where a system with 0 false-negatives does not exists). How do you deal with this issue? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
