Re: [mailop] subscription bombing prevention best practices
On Sun, October 17, 2021 11:56, Simon Arlott via mailop wrote: > > ...sign-up can be by email > only and they should stop accepting sign-up on a website. That sounds indeed like a great idea and if I was maintaining a mailing list - I would definitely do this. However, I'm afraid that in reality many mailing lists are ran by marketing departments as a way to convince people to buy their product, and for them switching from sign-up on a website to sign-up by email will inevitably show drop in sign-up rates, thus leading to potential loss of revenue. After all, for many people it's easier to paste their email address on a website they already have open, then to switch to mail client, compose new message, copypaste email address... And mailto: links require properly configured system, which might not always be the case. Alexey. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On 17/10/2021 11:15, C A via mailop wrote: > On Sun, Oct 17, 2021, Simon Arlott via mailop wrote: > >> confirmation process only if your email passes SPF/DKIM (or DMARC). If > > And if the sender doesn't use either? If there are no SPF or DMARC records published then you can let them continue to subscribe on the website and be vulnerable to subscription bombing? There has be some form of authentication of the address being subscribed otherwise there's no way for each individual mailing list service to know if it should reject a subscription request that's part of an attack. -- Simon Arlott ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On Sun, Oct 17, 2021, Simon Arlott via mailop wrote: > confirmation process only if your email passes SPF/DKIM (or DMARC). If And if the sender doesn't use either? -- Please don't Cc: me, use only the list for replies. [let's see what happens to the addresses...] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On 20/01/2021 10:50, Stefano Bagnara via mailop wrote: > 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). For mailing lists, it occurs to me that we should now be at the point where SPF and DKIM are ubiquitous enough that sign-up can be by email only and they should stop accepting sign-up on a website. To subscribe to a mailing list you should need to send an email (to the "sign-up address") and then your request would result in the usual confirmation process only if your email passes SPF/DKIM (or DMARC). If the sender fails to be authenticated then just discard the request. If that was implemented everywhere, wouldn't that stop subscription bombing? It would at least stop small Mailman deployments from being abused, and they already have to handle incoming spam so there's no difference there. The UX is different because you'd have to use mailto: addresses instead of a form on a website but you could decide to trigger that from JavaScript based on the domain they enter (to redirect to alternative special-case flows for different providers). mailto:list-subscr...@example.com?subject=Your%20ideas%20are%20intriguing%20to%20me,%20and%20I%20wish%20to%20subscribe%20to%20your%20newsletter. -- Simon Arlott ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On 2021-01-21 at 12:47 +0200, Mary via mailop wrote: > The victim of a subscription bombing attack can't do much, they > should be careful to shift through the garbage and find the real > threat (password changes, bank transfers, etc). > > Email admins can only do manual work, because I haven't seen anything > automated that can help in these situations. > > My limited understanding, is that all forms must be protected. The > biggest threat: headless browsers that by-pass protections like > hidden input fields and javascript code. A realistic solution is a > captcha, my personal preference is to avoid google's reCaptcha and > use either a custom solution or cloudflare's hCaptcha. The victims should create a filter rule (server-side, preferably) which moves to a "junk subscription requests" folder (or directly deletes, even) the subscription they receive. They are not that hard to tell apart (generally). rfc2369 doesn't provide a way to say "This is a subscription request for list foo", though. This is something in which Mailing list software could help by using a common way to signal that. Mail systems could then react to a mailbox receiving a large number of them in a sort time by processing them differently. Or, directly, always move them out of the main interface and e.g. put them on a "Mailing list subscription requests" folder, or a separate interface about "1585 pending mailing list subscriptions". It would also let them register which lists the user subscribed to (with a proper interface) and based on that skip DMARC checks for emails coming from that list. Best regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
The victim of a subscription bombing attack can't do much, they should be careful to shift through the garbage and find the real threat (password changes, bank transfers, etc). Email admins can only do manual work, because I haven't seen anything automated that can help in these situations. My limited understanding, is that all forms must be protected. The biggest threat: headless browsers that by-pass protections like hidden input fields and javascript code. A realistic solution is a captcha, my personal preference is to avoid google's reCaptcha and use either a custom solution or cloudflare's hCaptcha. On Thu, 21 Jan 2021 10:15:03 +0100 Stefano Bagnara via mailop wrote: > So I like your proposal, but I was looking for best practices to deal with > what happens now: forms being abused to fill email inboxes of innocent > victims. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On 21/01/2021 09:15, Stefano Bagnara via mailop wrote: > Of course a DNS method to let domains opt-in to such a generic system would > be cool, but unless we think 100% of domains will adopt openid we'll still > have the subscription bombing issue around, for every form not using this > "new method" and every recient on a domain not using this method. If you had enough adoption (e.g. from the big mailbox providers) then it would be viable to require support for from operators of mailing lists (note: support for the process, not necessarily requiring recipient domains to use it) and anyone who receives a flood of subscription requests will then be persuaded to implement it. > So I like your proposal, but I was looking for best practices to deal with > what happens now: forms being abused to fill email inboxes of innocent > victims. I don't think there is any other option. You have no way of knowing who else is subscribing the same user, through wildcard addresses or otherwise. Even if you had collaboration between major email senders to share this information there would still be many more independent mailing list installations. The next step in the denial of service process would be to ensure that you can't subscribe to anything because your address is permanently on the "receiving a flood of subscription requests" database. -- Simon Arlott ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On Wed, 20 Jan 2021 at 20:05, Simon Arlott via mailop wrote: > On 20/01/2021 10:50, Stefano Bagnara via mailop wrote: > > 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). > > How about a web-based process to confirm opt-in? > > Domains could opt into it by a DNS TXT record providing the URL of a > confirmation service. This would function something like OpenID and the > result would be a confirmation or rejection of the subscription. > OpenID itself would already work, I guess: in fact some of our users already skip the confirmation email using the "register with google" function for @gmail.com users. Of course a DNS method to let domains opt-in to such a generic system would be cool, but unless we think 100% of domains will adopt openid we'll still have the subscription bombing issue around, for every form not using this "new method" and every recient on a domain not using this method. So I like your proposal, but I was looking for best practices to deal with what happens now: forms being abused to fill email inboxes of innocent victims. It would take time to be adopted but it would put an end to "enter your > email address" forms accepting anything that is entered. > I think we'll be able to see something similar only if browsers directly implement some kind of openid support to deal with user/profile management more easily. Considering this is not happening for website authentication I doubt the confirmed opt-in world will push this ;-) Stefano ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
On 20/01/2021 10:50, Stefano Bagnara via mailop wrote: > 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). How about a web-based process to confirm opt-in? Domains could opt into it by a DNS TXT record providing the URL of a confirmation service. This would function something like OpenID and the result would be a confirmation or rejection of the subscription. Some kind of time-limited attestation URL could be used to allow the result to be relayed elsewhere for further processing. Potential issues with this include widespread phishing (because the user won't check they're on their provider's website) and providers gaining detailed insight into mailing list subscriptions (but they can imply those already by the email received). Optimisations could include the provider approving some subscriptions without user interaction if the intent is solely to prevent subscription bombing (but it would be nice to have true confirmed opt-in processes). It would take time to be adopted but it would put an end to "enter your email address" forms accepting anything that is entered. -- Simon Arlott ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
Dnia 20.01.2021 o godz. 14:00:47 Jaroslaw Rafa via mailop pisze: > > I'm not sure about what actual level of protection it provides. What do you > think? Sorry, I just realized that you were looking for a way of protection against mail-bombing caused by subscription confirmation emails, and not protection against fake subscriptions themselves. So my mail is off-topic, sorry, please disregard it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] subscription bombing prevention best practices
Dnia 20.01.2021 o godz. 11:50:30 Stefano Bagnara via mailop pisze: > > How do you deal with this issue? I'm not an ESP and actually don't face this issue, but some time ago I created my own version of CAPTCHA that I use in registration form on my server. There is no CAPTCHA on the form per se, but when you fill in the form, you get two things: 1) a number that is displayed *only in the web browser* after filling in the form. The user is instructed to remember (or write down) that number. 2) a regular confirmation link, that comes via email. That email (or link) does not contain the number from point 1). When the user clicks on the confirmation link, he/she is additionally asked to enter the number that was shown to him/her after filling up the form. Only then the registration succeeds. You may consider it some form of "two factor authentication" while registering :). I'm not sure about what actual level of protection it provides. What do you think? -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
