Jered Floyd writes:
> Ugh, I had not considered that RFC 8058 breaks the separation of
> concerns here.
Not your job, but it is ours. :-)
> we can at least make this work for Postorius users.
Definitely, that's a reasonable first step. We just need to make sure
to do that while allowing others to opt out until they've implemented
it themselves. I think I have a suggestion how it could just work for
everybody, though.
> Are there many who use just Mailman-Core and not the full suite?
I don't know about absolute numbers, but yeah, it's a FAQ. There's
the EMWD Affinity application which replaces Postorius for many of the
sites they host, and enterprises often ask how to use bespoke scripts
to control lists (although they may be using Postorius as well).
> The URI path/query is defined as opaque. It probably should be
> something like list-name/subscribed-address plus a signed hash to
> avoid unsub-attacks. That means this likely will be a new web
> application endpoint (although it may be possible to overload the
> existing "unsubscribe" endpoint -- I haven't looked at the code
> yet).
RFC 8058 says
The URI SHOULD include an opaque identifier or another
hard-to-forge component in addition to, or instead of, the
plaintext names of the list and the subscriber. The server
handling the unsubscription SHOULD verify that the opaque or
hard-to-forge component is valid.
We don't need to have an explicit reference to the subscription in the
URI. As I discovered (to my chagrin) Mailman's current simple RFC
2369 List-Unsubscribe field doesn't, even for personalized lists where
there might be a personalized link in the footer. So I think we
should go with "instead of". Maybe while experimenting it would be
useful to have the plain text subscription information in the URI,
though.
So ... the existing REST endpoint in core won't change, because the
whole REST API assumes that it's talking to the superuser. The
"obvious" way to do this is through Postorius, which provides a proxy
object backed by a map in Mailman core from tokens in the URL to
subscriptions, and use the existing REST endpoint. This is "obvious"
because Django already provides an authorization framework for
subscription management -- we wouldn't be exposing anything else
protected by that framework to mischief. The token would be the
encrypted (list, address) pair, possibly dated in clear (to allow
expiration of tokens and rotation of encryption keys). Unfortunately
RFC 8058 doesn't discuss that, I guess John assumed that people would
usually be unsubscribing from the most recent post. On the assumption
that unsubscribes would be "rare", you wouldn't have to store the
token in the database. (Have to think about that, you might be able
to DOS attack by sending lots of fake unsubscribes and attack the
encryption with known plaintext attacks. Safety would suggest adding
a random nonce and that would need to be saved in the database.)
Alternatively, you could reverse proxy this directly through the
front-end webserver to Mailman core with a new REST endpoint. That
gives me bad vibes because I can just see naive admins messing up the
configuration of the single endpoint, and "fixing" the problem by
reverse proxying port 8001 to the Internet. We'd have to be careful
that the urlconf not slop over to anything else, maybe something like
"listen" on the Internet at (nginx notation):
location /mailman3/rfc8058/ {
proxy_pass http://localhost:8001/3.2/PROXIED/rfc8058;
}
The "PROXIED" part is just to provide a REST namespace that is
obviously separate from the domains, addresses, users, lists, etc.
Maybe "SELF_AUTHORIZING" would be more accurate. I think that reverse
proxy sepcification would be safe enough.
And you could combine the two strategies which would allow sites that
don't use Postorius to configure the reverse proxy, while sites that
do would get it for "free" since we'd configure Postorius to do it.
Aside: RFC 8058 says
But anti-spam software often fetches all resources in mail header
fields automatically, without any action by the user, and there is
no mechanical way for a sender to tell whether a request was made
automatically by anti-spam software or manually requested by a
user.
Weirdly, the RFC doesn't address this problem at all. :-(
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
_______________________________________________
Mailman-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/[email protected]/message/ZAJY5A65IYASE34W4S73IHF7ZDBGYOZA/
This message sent to [email protected]
