Subscription Request asking for Confirmation instead of Moderation
We have a list where the Subscription Policy (Settings -> Member Policy -> Subscription Policy) is set to "Moderate" and when I send a message to LISTNAME-join@example.com<mailto:LISTNAME-join@example.com> (not the real domain, obviously) everything works as expected and the user shows up in the Pending Approval list.
We have a Drupal website that allows users to submit a form that, among other things, sends a subscription request to our Mailman3 'join' address. When that happens, however, instead of going to the Pending Approval list, the name is shows on the Pending Confirmation page. We don't send a Welcome message so as far as I can tell, they do not get an email asking them to confirm their email address. Two questions:
- 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?
- 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)?
Here are the headers sent with the subscriber's email address changed to FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> and our BCC mailbox domain changed to COMPANY.com.
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8Bit X-Mailer: Drupal Return-Path: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> Sender: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> From: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> Bcc: mailman-noreply@COMPANY.com<mailto:mailman-noreply@COMPANY.com>
-- Henry Hartley Westat RB 2151
On 8/27/25 09:22, Henry Hartley via Mailman-users wrote:
- 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?
- 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)?
Here are the headers sent with the subscriber's email address changed to FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> and our BCC mailbox domain changed to COMPANY.com.
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8Bit X-Mailer: Drupal Return-Path: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> Sender: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> From: FirstLast@SCHOOL.edu<mailto:FirstLast@SCHOOL.edu> Bcc: mailman-noreply@COMPANY.com<mailto:mailman-noreply@COMPANY.com>
Are these all the headers? If so, you need a To: header. sending the
envelope to the list-join address is not sufficient. The message must
either have a To: to the list-join address or a To: to the list-request
address with a Subject: or body of join
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Wednesday, August 27, 2025 21:10
On 8/27/25 09:22, Henry Hartley via Mailman-users wrote:
- 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?
- 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)?
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.
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8Bit X-Mailer: Drupal Return-Path: FirstLast@SCHOOL.edu Sender: FirstLast@SCHOOL.edu From: FirstLast@SCHOOL.edu Bcc: mailman-noreply@COMPANY.com
Are these all the headers? If so, you need a To: header. sending the envelope to the list-join address is not sufficient. The message must either have a To: to the list-join address or a To: to the list-request address with a Subject: or body of
join
That's what I was given and I didn't look at it carefully enough. My apologies. There was indeed a To: header, so it wasn't that. I got a copy of the actual email and was able to see all the headers, which I've pasted below (with the exception of two X-Microsoft-Antispam-xxx headers, which are fairly long). I've anonymized it similarly to the above as well as changing the IP address to 192.169.0.0, which is not what's really there. 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.
Received: from CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5) by LV8PR05MB10549.namprd05.prod.outlook.com with HTTPS; Fri, 8 Aug 2025 16:57:54 +0000 Received: from DM6PR02CA0123.namprd02.prod.outlook.com (2603:10b6:5:1b4::25) by CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9009.18; Fri, 8 Aug 2025 16:57:52 +0000 Received: from DS3PEPF0000C37A.namprd04.prod.outlook.com (2603:10b6:5:1b4:cafe::9e) by DM6PR02CA0123.outlook.office365.com (2603:10b6:5:1b4::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9009.15 via Frontend Transport; Fri, 8 Aug 2025 16:57:52 +0000 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 Received-SPF: Fail (protection.outlook.com: domain of SCHOOL.edu does not designate 192.168.0.0 as permitted sender) receiver=protection.outlook.com; client-ip=192.168.0.0; helo=esa2.COMPANY.iphmx.com; Received: from esa2.COMPANY.iphmx.com (192.168.0.0) by DS3PEPF0000C37A.mail.protection.outlook.com (10.167.23.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9009.8 via Frontend Transport; Fri, 8 Aug 2025 16:57:52 +0000 X-CSE-ConnectionGUID: 6gzl16giR+OI2R+uEItzYA== X-CSE-MsgGUID: N0dF+IkxQxqpO1VcWOCK3A== X-IronPort-AV: E=Sophos;i="6.17,274,1747713600"; d="scan'208";a="40347776" Received: from ex2019-3.COMPANY.com ([74.119.60.23]) by esa2.COMPANY.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 08 Aug 2025 12:57:50 -0400 Received: from EX2019-1.COMPANY.com (10.1.146.19) by EX2019-3.COMPANY.com (10.1.146.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 8 Aug 2025 12:57:50 -0400 Received: from COmailout.COMPANY.com (10.1.146.69) by EX2019-1.COMPANY.com (10.1.146.19) with Microsoft SMTP Server id 15.2.1748.26 via Frontend Transport; Fri, 8 Aug 2025 12:57:50 -0400 Received: from WEBSERVER.COMPANY.com ([10.115.9.208]) by COmailout.COMPANY.com over TLS secured channel with Microsoft SMTPSVC(10.0.17763.1697); Fri, 8 Aug 2025 12:57:50 -0400 Received: by WEBSERVER.COMPANY.com (Postfix, from userid 33) id 998892A0BDB; Fri, 8 Aug 2025 12:57:48 -0400 (EDT) To: <MAILINGLIST-join@DOMAIN.org> Subject: Subscribe MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: Drupal Sender: <FIRSTLAST@SCHOOL.edu> From: <FIRSTLAST@SCHOOL.edu> Message-ID: <20250808165748.998892A0BDB@WEBSERVER.COMPANY.com> Date: Fri, 8 Aug 2025 12:57:48 -0400 Return-Path: FIRSTLAST@SCHOOL.edu X-OriginalArrivalTime: 08 Aug 2025 16:57:50.0067 (UTC) FILETIME=[92CA3430:01DC0885] X-MS-Exchange-Organization-ExpirationStartTime: 08 Aug 2025 16:57:52.4416 (UTC) X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit X-MS-Exchange-Organization-Network-Message-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: a066de23-9711-4de4-8725-431a39ebcafb:0 X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37A:EE_|CO1PR05MB8586:EE_|LV8PR05MB10549:EE_ X-MS-Exchange-Organization-AuthSource: DS3PEPF0000C37A.namprd04.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Office365-Filtering-Correlation-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-MS-Exchange-Organization-ExpirationInterval: 0:12:30:00.0000000 X-MS-Exchange-Organization-ExpirationIntervalReason: TenantCustomized X-MS-Exchange-AtpMessageProperties: SA|SL X-MS-Exchange-Organization-SCL: -1 X-Microsoft-Antispam: BCL:0;ARA:13230040; X-Forefront-Antispam-Report: CIP:192.168.0.0;CTRY:US;LANG:en;SCL:-1;SRV:;IPV:CAL;SFV:SKN;H:esa2.COMPANY.iphmx.com;PTR:esa2.COMPANY.iphmx.com;CAT:NONE;SFS:(13230040);DIR:INB; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2025 16:57:52.2718 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab X-MS-Exchange-CrossTenant-Id: a066de23-9711-4de4-8725-431a39ebcafb X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C37A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB8586 X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.2435910 X-MS-Exchange-Processed-By-BccFoldering: 15.20.8989.011
-- Henry Hartley Westat RB 2151
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
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> Sent: Thursday, August 28, 2025 12:27
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.
I have 50 lists and they all have the "Subscription Policy" set to Moderate. If I send an email (e.g. from my gmail account) to the LIST-join address, it goes into the Subscriptions Pending Approval list, as it should. But, when sent from Drupal it goes to the Subscriptions Pending User Confirmation list. That's the weirdness that I'm trying to untangle. Nevertheless, I will have one of our testers subscribe through Drupal to a list and confirm that the issue happens every time.
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.
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.'
- 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.
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.
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. We definitely could rewrite our code to use the REST API, and in the long run, that would be good. But we brought this code over from government servers that were using Mailman2 and since it basically worked (except for this odd issue) we put that at a lower priority. But maybe we need to do that sooner rather than later.
-- Henry Hartley
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
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> Sent: Friday, August 29, 2025 03:36
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.
Our moderators are also owners so that's not a problem.
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.
The reason for the Microsoft server being involved is that's the way our Systems folks insisted we set it up. So, main to our particular domain goes through that and is routed to our server. In other words, "yes".
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).
The reason we didn't use the REST API is that we had code that worked (or at least that we thought worked). I've recommended to the site maintainers that they update their code to use the API and we'll deal with these things manually until that's done.
Thank you and Mark Sapiro for your responses.
-- Henry Hartley Westat RB 2151
On 8/28/25 07:06, Henry Hartley via Mailman-users wrote:
That's what I was given and I didn't look at it carefully enough. My apologies. There was indeed a To: header, so it wasn't that. I got a copy of the actual email and was able to see all the headers, which I've pasted below (with the exception of two X-Microsoft-Antispam-xxx headers, which are fairly long). I've anonymized it similarly to the above as well as changing the IP address to 192.169.0.0, which is not what's really there. 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.
...> To: <MAILINGLIST-join@DOMAIN.org>
Subject: Subscribe MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: Drupal Sender: <FIRSTLAST@SCHOOL.edu> From: <FIRSTLAST@SCHOOL.edu> Message-ID: <20250808165748.998892A0BDB@WEBSERVER.COMPANY.com> Date: Fri, 8 Aug 2025 12:57:48 -0400 Return-Path: FIRSTLAST@SCHOOL.edu ...
These are all good and should result in the subscription held for moderation as log as the lists Subscription Policy is Moderate (not Confirm, then Moderate).
What does the mail to the user, FIRSTLAST@SCHOOL.edu, say? I.e., if the subscription is waiting confirmation there should be a mail to the user with Subject: Your confirmation is needed to join the MAILINGLIST mailing list and body that begins with
Email Address Registration Confirmation
Hello, this is the GNU Mailman server at DOMAIN.org.
Does the user get that email, a different email (if so, what) or no email.
Is there anything systematically different about the addresses you are subscribing this way and the ones who subscribe with their own email?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----Original Message----- From: Mark Sapiro <mark@msapiro.net> Sent: Thursday, August 28, 2025 18:57
What does the mail to the user, FIRSTLAST@SCHOOL.edu, say? I.e., if the subscription is waiting confirmation there should be a mail to the user with Subject: Your confirmation is needed to join the MAILINGLIST mailing list
I've having the users do some testing to see if a) they can reproduce the problem and b) if so whether or not the confirmation email is sent.
-- Henry Hartley Westat RB 2151
participants (3)
-
Henry Hartley -
Mark Sapiro -
Stephen J. Turnbull