Jered Floyd writes:
I'm not going to defend Google's implementations and policies here,
I'm not asking anybody to do it one way or the other, I'm just generally pissed off that mailing lists have to bear the burden of the abuse of mail protocols by large monopolistic companies, who won't impose sensible restrictions on their users (a domain with p=reject should not be sending to mailing lists).
but the RFC 2369 fields are regularly insufficient.
You're right. I misread the code to say that the List-Unsubscribe field would contain the subscribed address if the distributed post was personalized, but it doesn't. We can fix that (in the case of a personalized list), and we should fix it with RFC 8058.
I'll need to check, but I think we want to add a full configuration section on Postorius for all the List-* fields (RFCs 2369, 2919, and now 8058). Besides the options to include the fields and set their content, there should be options for "Mailman standard" mailto and http(s) URIs, as well as an option to edit the http(s) URI for folks who use something other than Postorius.
I need to go back and read RFC 8058, but I think that the address information in the RFC 8058 URI can be completely opaque. I'm not sure if that's the best approach.
Regardless of that, the little box that says "this message is from a mailing list; would you like to unsubscribe?" that appears on my iDevice is extremely useful and a great user affordance.
RFC 2369 is a standard. Every serious MUA should provide that button for every list that provides a List-Unsubscribe field, along with help for the case where the address to unsubscribe is not provided.
RFC 8058 is a standard; there's no reason for us to be needlessly hostile to implementing it. (That's independent from prioritizing it or finding someone with the time, of course.)
I haven't noticed needless hostility. It's a LOT of work to do properly, though. Among other things, RFC 8058 requires "The List-Unsubscribe header field MUST contain one HTTPS URI." We don't necessarily control the implementation of that -- Postorius is an optional component, and Mailman core does not expose an HTTP port to the Internet by design. It's going to require changing several schemas in Mailman configuration, data models, and databases.
Are you suggesting just adding bogus RFC 8058 headers to appease GMail?
No, as explained above, I thought that Mailman was already adding subscription information to the "leave" field. The risk in what I was thinking was entirely DOS attacks on the list's subscribers via an insecure 1-click implementation.
The leave address is not sufficient for this, and as per up-thread cannot be applied in rfc_2369.py because it is pre-personalization.
That doesn't matter, since it's an easy-to-implement personalization. Just go to the end of the field, backspace past the ">", and insert a query providing the address and/or RFC 8058 token.
I see in your later message that you haven't enabled personalization in Mailman. [...]
Again, this was from misreading the code. My bad, I apologize.
don't think there's really any case in which personalization should be disabled in the modern internet mail world, and would argue (but not very strongly) that the options to turn this off probably ought be removed from Mailman.
I would oppose that. There are use cases where broadcast of generic messages make sense and unsubscribe does not, such as addresses and lists provided as a condition of organization membership.
(At the very least, personalization ought be the default.)
That's plausible.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan