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
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
