Multiple subscription requests and reminders
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Hi!
I have a mailman 2.1.5 installation on a FC1 Plesk-administrated
server. The problem I'm having is that subscription confirmation e-mails arrive in duplicate or quadruplicate (!!!!). Plus, subscription reminders come in even larger quantities. The "subscribe" log shows apparently independent subscription requests, so I'm kinda stumped on what's causing this. The MTA is qmail and seems to be working fine for several domains hosted on this machine. Has anyone had this problem, and what can/should I look for as far as troubleshooting goes?
-- Bruno Ferreira
[This E-mail scanned for viruses by Declude Virus]
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 4:45 PM +0100 2005-06-17, Bruno Ferreira wrote:
I have a mailman 2.1.5 installation on a FC1 Plesk-administrated
server.
Please note the Mailman FAQ Wizard entry at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.015.htp>.
What exactly is in your MTA logs? What is in your Mailman logs?
Can you show us some examples of duplicate messages, with all the headers intact?
For qmail-related items, you'd need to use mailing lists, FAQs,
etc... related to that MTA. The issue right now is that we need to help you figure out where the problem lies.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
I've read that FAQ entry but unfortunately it doesn't really address
this problem. The Mailman version installed is nearly the most (stable) recent one, so the older-version-installed problems don't apply.
Mailman subscribe log (machine/email addresses changes to protect
the customer :): ----
Jun 22 01:33:29 2005 (3305) mailinglist: pending
destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com
Mailman smtp log:
--------
Jun 22 01:33:29 2005 (3308)
<mailman.0.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.277 seconds Jun 22 01:33:29 2005 (3308) <mailman.1.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.085 seconds Jun 22 01:33:29 2005 (3308) <mailman.2.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.074 seconds Jun 22 01:33:29 2005 (3308) <mailman.3.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.092 seconds
SMTP server log (from xinetd) shows 4 independent SMTP spawned
processes: --------
Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3370
from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3373 from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3377 from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3381 from=127.0.0.1
Message headers:
--------------------
All headers match among messages except sender/receiver MTA PID
(obviously), the subject (there are 4 separate confirmation requests with individual hashes), and the message ID. *However*, the message ID only changes the first digit among all 4 messsages, i.e.:
<mailman.0.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.1.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.2.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.3.1119400409.3305.mailingmoderna@modernaeditorial.com>
The destination address, before you ask, is not a list administrator
(I double-checked that). I didn't copy all the message headers for the sake of readability, since they're all the same.
I only mentioned that so that anyone who read this wouldn't think
that an MTA wasn't even properly configured :)
-- Bruno Ferreira
[This E-mail scanned for viruses by Declude Virus]
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:15 AM +0100 2005-06-22, Bruno Ferreira wrote:
In particular, I was primarily referring to the first and third
paragraphs at that URL:
Some people use Mailman through Plesk, and they come to the
Mailman mailing lists for help when they have trouble. There's
usually little we can do to help with these specific problems,
and you should contact your hosting provider or Plesk for
assistance. You can also obtain assistance through the Plesk
Forums at <http://forum.sw-soft.com/>, using the search
keyword "mailman". However, since none of the Mailman
developers use Plesk, we are not likely to be able to help.
And:
This is similar to the problem with Mailman and cPanel, see
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp>.
Then there is the fourth paragraph:
If you're having problems with messages not getting out to
your members, you may not have direct access to the level of
information needed to debug the problem, but you should at
least check out the standard debugging entry in FAQ 3.14 at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.014.htp>.
Looking at the other information you've provided, I don't see
anything that is helpful in terms of trying to debug your problem. At least from the perspective of Mailman, it seems to have done its job in all the appropriate places and handed the messages over to the MTA.
From that point, it's up to the MTA, and that's something we
can't help you with.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
I believe you may have misread my post (or part of it). The problem
is not that e-mails don't get send, it's that a subscription requests (especially reminders) go out in multiple copies to the recipient. In the example given, a single subscription request ended up being quadruplicated by Mailman (for no apparent reason). All of the logs files I've pasted point to this. The hashes in the messages are all different, which seems to indicate Mailman somehow processing the same subscription request 4 times. In particular, subscription reminders usually come out in quantities of 16. Mailman seems to be working fine otherwise.
The problem wasn't the users not getting their mail, it was about
them getting too much of it. I've looked in the Plesk forums anyway, and no-one seemed to have this problem. I've looked at the troubleshooting FAQ as well, and reviewed the following:
* Mailmanctrl is running
* Aliases are OK
* smrsh is not used
* Messages are going out well (too well), so the interfaces are fine
* Only one lock file is present, for the current daemon PID
* Logs: already checked those (and posted the relevant ones), it
seems everything is ok too
* Queues are empty, as they should be
* SMTPHOST is fine as outbund messages work ok
-- Bruno Ferreira
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bruno Ferreira wrote:
This indicates that Mailman processed the subscribe request 4 times. Everything else you provided is consistent with this and thus adds nothing more.
The question is why is Mailman processing the request 4 times. Is it a bug in mailman or does mailman actually receive 4 requests?
Does the request arrive via the web interface (subscribe form on the listinfo page) or via e-mail. If from the web, what do the web servers logs say about how many 'post' transactions were processed? If via mail, what do the incoming MTA logs say about how many messages were piped to the wrapper?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
After a bit more investigation at the MTA side, I managed to find
out that Mailman processes the subscribe requests alone twice. Subscribing through the web interface makes Mailman process the request once. However, sending a mail without proper commands to mailinglist-request@domain throws ONE error e-mail back, as it should be. So there's this situation:
- Subscription through web interface: OK
- Subscription through e-mail: 2 subscriptions processed
- Other mail to mailinglist-request@domain: OK
Where do you suggest I start looking now?
-- Bruno Ferreira
[This E-mail scanned for viruses by Declude Virus]
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bruno Ferreira wrote:
Look at the actual subscription request e-mail (Bcc: yourself to get a copy). Look for anything strange like two From: headers or e-mail address appearing twice in From: header.
Check MTA log to make sure request is only piped once to the wrapper, although it seems that you've probably already done this or at least empirically verified it (- Other mail to mailinglist-request@domain: OK)
Are you mailing mailinglist-request@domain with 'subscribe' both in the subject and in the body of the e-mail?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
I've done some more checking, it seems that there wasn't a problem
at all (or at least, Mailman is not processing requests twice). Your suggestion made sense... Said e-mails had "subscribe" both in the subject line and in the body, causing two subscription requests to be processed :(((( Despite this being much of a case "all this trouble for nothing", having Mailman process the same request twice for the same e-mail doesn't make much sense (I'd count it as a bug, really). Thanks to everyone for their input on the "problem" :)
-- Bruno Ferreira
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 4:45 PM +0100 2005-06-17, Bruno Ferreira wrote:
I have a mailman 2.1.5 installation on a FC1 Plesk-administrated
server.
Please note the Mailman FAQ Wizard entry at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.015.htp>.
What exactly is in your MTA logs? What is in your Mailman logs?
Can you show us some examples of duplicate messages, with all the headers intact?
For qmail-related items, you'd need to use mailing lists, FAQs,
etc... related to that MTA. The issue right now is that we need to help you figure out where the problem lies.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
I've read that FAQ entry but unfortunately it doesn't really address
this problem. The Mailman version installed is nearly the most (stable) recent one, so the older-version-installed problems don't apply.
Mailman subscribe log (machine/email addresses changes to protect
the customer :): ----
Jun 22 01:33:29 2005 (3305) mailinglist: pending
destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com Jun 22 01:33:29 2005 (3305) mailinglist: pending destination@server.com destination@server.com
Mailman smtp log:
--------
Jun 22 01:33:29 2005 (3308)
<mailman.0.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.277 seconds Jun 22 01:33:29 2005 (3308) <mailman.1.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.085 seconds Jun 22 01:33:29 2005 (3308) <mailman.2.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.074 seconds Jun 22 01:33:29 2005 (3308) <mailman.3.1119400409.3305.mailing_list@webserver.com> smtp for 1 recips, completed in 0.092 seconds
SMTP server log (from xinetd) shows 4 independent SMTP spawned
processes: --------
Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3370
from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3373 from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3377 from=127.0.0.1 Jun 22 01:33:29 server xinetd[18538]: START: smtp pid=3381 from=127.0.0.1
Message headers:
--------------------
All headers match among messages except sender/receiver MTA PID
(obviously), the subject (there are 4 separate confirmation requests with individual hashes), and the message ID. *However*, the message ID only changes the first digit among all 4 messsages, i.e.:
<mailman.0.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.1.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.2.1119400409.3305.mailingmoderna@modernaeditorial.com>
<mailman.3.1119400409.3305.mailingmoderna@modernaeditorial.com>
The destination address, before you ask, is not a list administrator
(I double-checked that). I didn't copy all the message headers for the sake of readability, since they're all the same.
I only mentioned that so that anyone who read this wouldn't think
that an MTA wasn't even properly configured :)
-- Bruno Ferreira
[This E-mail scanned for viruses by Declude Virus]
![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 2:15 AM +0100 2005-06-22, Bruno Ferreira wrote:
In particular, I was primarily referring to the first and third
paragraphs at that URL:
Some people use Mailman through Plesk, and they come to the
Mailman mailing lists for help when they have trouble. There's
usually little we can do to help with these specific problems,
and you should contact your hosting provider or Plesk for
assistance. You can also obtain assistance through the Plesk
Forums at <http://forum.sw-soft.com/>, using the search
keyword "mailman". However, since none of the Mailman
developers use Plesk, we are not likely to be able to help.
And:
This is similar to the problem with Mailman and cPanel, see
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp>.
Then there is the fourth paragraph:
If you're having problems with messages not getting out to
your members, you may not have direct access to the level of
information needed to debug the problem, but you should at
least check out the standard debugging entry in FAQ 3.14 at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.014.htp>.
Looking at the other information you've provided, I don't see
anything that is helpful in terms of trying to debug your problem. At least from the perspective of Mailman, it seems to have done its job in all the appropriate places and handed the messages over to the MTA.
From that point, it's up to the MTA, and that's something we
can't help you with.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Brad Knowles wrote:
I believe you may have misread my post (or part of it). The problem
is not that e-mails don't get send, it's that a subscription requests (especially reminders) go out in multiple copies to the recipient. In the example given, a single subscription request ended up being quadruplicated by Mailman (for no apparent reason). All of the logs files I've pasted point to this. The hashes in the messages are all different, which seems to indicate Mailman somehow processing the same subscription request 4 times. In particular, subscription reminders usually come out in quantities of 16. Mailman seems to be working fine otherwise.
The problem wasn't the users not getting their mail, it was about
them getting too much of it. I've looked in the Plesk forums anyway, and no-one seemed to have this problem. I've looked at the troubleshooting FAQ as well, and reviewed the following:
* Mailmanctrl is running
* Aliases are OK
* smrsh is not used
* Messages are going out well (too well), so the interfaces are fine
* Only one lock file is present, for the current daemon PID
* Logs: already checked those (and posted the relevant ones), it
seems everything is ok too
* Queues are empty, as they should be
* SMTPHOST is fine as outbund messages work ok
-- Bruno Ferreira
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bruno Ferreira wrote:
This indicates that Mailman processed the subscribe request 4 times. Everything else you provided is consistent with this and thus adds nothing more.
The question is why is Mailman processing the request 4 times. Is it a bug in mailman or does mailman actually receive 4 requests?
Does the request arrive via the web interface (subscribe form on the listinfo page) or via e-mail. If from the web, what do the web servers logs say about how many 'post' transactions were processed? If via mail, what do the incoming MTA logs say about how many messages were piped to the wrapper?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
After a bit more investigation at the MTA side, I managed to find
out that Mailman processes the subscribe requests alone twice. Subscribing through the web interface makes Mailman process the request once. However, sending a mail without proper commands to mailinglist-request@domain throws ONE error e-mail back, as it should be. So there's this situation:
- Subscription through web interface: OK
- Subscription through e-mail: 2 subscriptions processed
- Other mail to mailinglist-request@domain: OK
Where do you suggest I start looking now?
-- Bruno Ferreira
[This E-mail scanned for viruses by Declude Virus]
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Bruno Ferreira wrote:
Look at the actual subscription request e-mail (Bcc: yourself to get a copy). Look for anything strange like two From: headers or e-mail address appearing twice in From: header.
Check MTA log to make sure request is only piped once to the wrapper, although it seems that you've probably already done this or at least empirically verified it (- Other mail to mailinglist-request@domain: OK)
Are you mailing mailinglist-request@domain with 'subscribe' both in the subject and in the body of the e-mail?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/07a25fb593721c834e6db6f799941526.jpg?s=120&d=mm&r=g)
Mark Sapiro wrote:
I've done some more checking, it seems that there wasn't a problem
at all (or at least, Mailman is not processing requests twice). Your suggestion made sense... Said e-mails had "subscribe" both in the subject line and in the body, causing two subscription requests to be processed :(((( Despite this being much of a case "all this trouble for nothing", having Mailman process the same request twice for the same e-mail doesn't make much sense (I'd count it as a bug, really). Thanks to everyone for their input on the "problem" :)
-- Bruno Ferreira
participants (3)
-
Brad Knowles
-
Bruno Ferreira
-
Mark Sapiro