Henry Hartley via Mailman-users writes:
- Are there particular headers that are causing the email to go to the Confirmation page instead of the Approval page? Or are there particular headers we can add that will help with this?
No. That's entirely determined by the list's configuration. You cannot change that behavior via a user's subscription request whether by email or web. IIRC, the only overrides are either through the REST API, "mailman shell", or the "mass subscribe" page on the web. (I guess it's possible that the moderator can "pre confirm" at approval time, do you see such an option when you approve? I've never managed a "moderate" list so I don't know without groveling through the code.)
Do you really only have one list? Is it possible that the misbehaving list is not configured as you expect (ie, the list subscription policy is "confirm" or "confirm then moderate")? Unlikely, but if you haven't checked since the problem started, please confirm.
Are you sure that the members have not been approved by some moderator? I forget exactly how this works, but unless you use mass subscribe with the "pre confirm" option set, the user will have to confirm before they can receive mail.
I believe that all outgoing messages from Mailman should be logged. So you should check for outgoing confirmation notices. Posts are given a summary log like "smtp to somelist@example.org for 225 recips". IIRC notices (such as confirmations) are logged as "smtp to FirstLast@SCHOOL.org" for each individual notice. (My own production lists were all "mass subscribe" lists so I don't have any notice examples.) Notice logs are usually in $log_dir/smtp.log, but some sites configure them to a separate log. After the Mailman logs, they should show up in the MTA logs. Posts are always logged with the Message-ID, I think notices are as well.
- 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 :-).
Here are the headers sent with the subscriber's email address changed to FirstLast@SCHOOL.edu and our BCC mailbox domain changed to COMPANY.com.
Is FirstLast@SCHOOL.edu in the Confirmation Pending page?
[...]
X-Mailer: Drupal
Good, this is the Drupal script. Saves me from asking for confirmation.
Return-Path: FirstLast@SCHOOL.edu Sender: FirstLast@SCHOOL.edu From: FirstLast@SCHOOL.edu
Pretty sure that only From is consulted by the subscription machinery. Since they're all the same this shouldn't matter. Since this is an on-behalf-of message, most likely Return-Path and Sender should *not* be the user -- if something goes wrong, they can't do anything to fix it.
Note also that the mailto: links above (and below, if applicable) are not in the text I'm pasting but have been added somewhere along the line.
Presumably you did a screen copy from the presentation version rather than the raw text of the message.
Authentication-Results: spf=fail (sender IP is 192.168.0.0) smtp.mailfrom=SCHOOL.edu; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=SCHOOL.edu;compauth=fail reason=000
This requires some care. DMARC is failing, and necessarily will fail. If SCHOOL.edu has a p=reject policy, this mail should not get to Mailman at all.
Also, your Drupal host is not signing its mail. This doesn't necessarily matter for this script, since it can't pass DMARC, so you need to have an alternative way to trust mail from it. But it is really important that your Mailman host sign its mail, especially mail it originates, because many hosts will discard, reject, or quarantine unauthenticated email that looks like it was generated by a robot and contains links. This could explain some cases of subscribers apparently not receiving confirmation notices.
You could check the "shunt", "bad", and "virgin" queues to see if confirmation messages are hung up in one of those.
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.)
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan