On 12/1/22 16:11, Phil Budne wrote:

It seems like the anonymous_subscribe route is being used to send mail to unwitting targets. I'd rather not be operating a relay being used to DDoS people's mailboxes.

Any suggestions on out of the box solutions?

This is a problem and there are currently no out of the box solutions. One thing you could do is remove the anonymous subscribe form from postorius/templates/postorius/lists/summary.html

I think it would be nice if we had a configuration setting to do that. Filing an issue at https://gitlab.com/mailman/postorius/-/issues/new would add motivation for this.

Phil Budne writes:

Almost every day I find outgoing emails from postorius stuck in my outbound mail queue. It seems like the anonymous_subscribe route is being used to send mail to unwitting targets.

It's almost like that's what it's for, isn't it? The problem, of course, is that for our purposes ability to read mail at an email address is a near-perfect way to identify subscribers. So for a new user, getting that identification involves confirmation via a round- trip email conversation.

The problem here is that anonymous subscription via web has no relation to an email address, and confirmation requires sending an email to the address requested. As Mark points out, removing the anonymous subscription page is a way to prevent this attack. But that's kind of unpleas

Of course it's also trivial to spoof an address in email. So I see three ways to allow an as-yet unknown user to subscribe with relative security:

(1) Authenticate web users through something like OAuth2 or SAML at their email provider.

(a) This could be generalized somewhat to allow trusted idPs to
authenticate any email addresses that have been associated with
that ID, but you'd have to make sure that only trustworthy idPs
that only provide authenticated emails are on the list.

(2) Disable the ability to anonymously subscribe through email, and only allow the "From" address to subscribe, and only if it passes DMARC-like From alignment.

(3) Transitive trust of existing authenticated users, who could sign a request. Surely this would have to be rate-limited both in number of attestations allowed to an existing user, and via a delay in allowing attestations from newly authenticated users (which could be measured in weeks or in posts), but it might work.

I see Mark has already posted a proof-of-concept for disabling anonymous subscription via web. I think I will add these tasks to our Summer of Code list, but if you want to take a crack at any of them, be my guest.

I'm a Python programmer, but not a Djangoist.

If that's a potential offer of code, I love it! (1) would probably be most useful when done via Django socialauth mechanisms (but this isn't really "Django programming"), although there are alternatives like Shibboleth for SAML idPs that I think have Python bindings. But I think (2) is probably within reach of any Python programmer since the toolbox (SPF, DKIM, DMARC) is already available in any complete Mailman 3 installation. I'd be happy to point you at the relevant tools and existing Mailman client code for them. (3) also also pretty generic, but I don't know anything about availability of email signing tools for "web of trust"-based PKI. Pretty sure they're out there, though.

Steve