Henry Hartley via Mailman-users writes:
I have 50 lists and they all have the "Subscription Policy" set to Moderate.
Good for you, too bad for the troubleshooting -- that would have been an easy fix.
The issue was reported by the moderator, who saw the email address in the wrong place. If the Subscription Policy is set to 'Confirm then Moderate' then ;First subscribers have to confirm, then a moderator needs to authorize.' Since it's set to 'Moderate' (only), then 'Moderators will have to authorize each subscription manually.'
Yes, I understand how the configuration is supposed to work. Do you understand that there are two reasons for confirmation? The first is that since *anyone* can send email to LIST-join, Mailman will send a confirmation message to the address to ensure that the owner of the address actually wants to subscribe. (This is also done for an anonymous subscription from the web interface. It is not done for a logged in user who has previously confirmed the address.) Second, Mailman will not accept posts from (for members-only lists) or deliver list posts to an address that has not been confirmed. So if the address has not yet been confirmed, Mailman will also send a verification message to the address, even if the moderator has approved. The pending verification is added to the *confirmation* page because it's waiting for a user action. The *approval* page is for pending moderator actions. (As I mentioned, I'm not sure if the moderation screen has an option for the moderator to confirm the address as well as approve the subscription. If not, or it is not checked, then a confirmation message will be sent.)
- Is there any way for us to move an address from the Confirmation Pending page to confirmed on the backend (preferably through the web interface, but on the server itself, if necessary)?
Not that I know of, but what you can do is mass subscribe those addresses. I think that you'll still end up with them waiting for confirmation as described above. You can confirm them by accessing the database directly, but that's more fraught than I want to deal with at bedtime :-).
Until we figure this out, I've instructed the moderator to copy the address from the User Confirmation list and Mass Subscribe them and then remove them from the Confirmation List. It works but the moderators don't like it.
Last I looked, *moderators* don't have access to Mass Subscribe, only *owners* do. Has that changed? I don't think this would have any effect on the misqueueing issue, however.
I'm pretty sure the outgoing mail from mailman is getting the right headers for DMARC but it definitely bears testing.
If the Drupal host is the Mailman host, then you could use the PHP script to talk to the REST API instead of using email. Cutting out the long list of middlemen, so to speak. (It would also be possible if they're different hosts, but the security precautions I would recommend are quite a bit more severe.)
Yes, Drupal and Mailman are on the same host.
Hm. Do you have a reason for sending email from Drupal to Mailman through Microsoft servers? Note: "yes" is a sufficient answer, I have no need to know more. If it's just an accident, you can ensure that Drupal's mail will reach Mailman by configuring it for local delivery, which you can make safe from spam filters and DMARC processing.
I don't think this would resolve the misqueueing issue, though.
It's quite a puzzler unless somehow the Drupal join request got approved, and the pending confirmation(s) you see are actually verifications that the person who initiated the request owns the address.
We definitely could rewrite our code to use the REST API[...]. But maybe we need to do that sooner rather than later.
This should resolve the misqueueing issue. It's not that hard. In fact, it might be easier that doing it by email (except that of course you already have the code for doing it by email).
I can't help you with the PHP (Drupal is PHP, right?) side, but the REST API only cares about URLs and JSON. I expect you (or somebody on staff) can translate the Pythonisms in the docs here:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/m...
The dump_json function will HTTP POST the JSON in the second
argument to the URL in the first argument. The response content will
be a JSON object, which dump_json parses and displays nicely. The
HTTP request must be authenticated with the admin_user and admin_pass
credentials from the mailman.cfg file.
As you can see in the first example, you can set pre_verified (= we know this user owns the address), pre_confirmed (= user wants the subscription), and pre_approved (= moderator approves) in the JSON. If the Drupal user is logged in, and you get the email address from the Drupal user database, then it makes sense for both convenience and security to set pre_confirmed and pre_verified. Otherwise you should think carefully about the implications of setting either of those. Of course setting pre_approved would bypass the moderator so you presumably don't want to do that.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan