• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Mailman not working after updating to 9.0

I tried the symbolic link first, before copying the file from an older backup. Here's something from my maillog. I'l trying to figure out why the wrapper is being executed by popuser.

Jan 6 10:38:40 web1 Mailman mail-wrapper: Group mismatch error. Mailman expected the mail wrapper script to be executed as one of the following groups: [mail, postfix, mailman, nobody, daemon], but the system's mail server executed the mail script as group: "popuser". Try tweaking the mail server to run the script as one of these groups: [mail, postfix, mailman, nobody, daemon], or re-run configure providing the command line option: '--with-mail-gid=popuser'.
Jan 6 10:38:40 web1 qmail: 1231256320.256833 delivery 13: deferral: Group_mismatch_error._Mailman_expected_the_mail_wrapper_script_to_be/executed_as_one_of_the_following_groups:/[mail,_postfix,_mailman,_nobody,_daemon],/but_the_system's_mail_server_executed_the_mail_script_as_group:_"popuser"./Try_tweaking_the_mail_server_to_run_the_script_as_one_of_these_groups:/[mail,_postfix,_mailman,_nobody,_daemon],/or_re-run_configure_providing_the_command_line_option:/'--with-mail-gid=popuser'./
Jan 6 10:38:40 web1 qmail: 1231256320.256908 status: local 0/10 remote 0/20
 
I'm able to get new messages to my test list now. The old ones just sit in the queue.

I honestly have to say I don't know what I did that made it work, but here's the history:

1. From /var/qmail/bin/ I moved the mm_wrapper file I had restored from a backup to save it: mv mm_wrapper /root
2. Then I made a symbolic link in /var/qmail/bin to the "new" mm_wrapper: ln -s /usr/lib/plesk-9.0/mm_wrapper mm_wrapper
3. I restarted services qmail and mailman
4. mailman not working yet...
5. Then I did this: chmod 2555 /var/qmail/bin/mm_wrapper
6. Restarted mailman
7. Looked around in /usr/lib/plesk-9.0/ just to see what stuff was in there. Found mailman_conf_init. Thought, "What the heck. might as well see what it does."
8. Did this: /usr/lib/plesk-9.0/mailman_conf_init /usr/lib/mailman/Mailman/mm_cfg.py qmail
9. Restarted mailman and qmail.

Now I can send messages to my test list and they're delivered. Like I said, I'm not at all accustomed to qmail, so my next quest is to learn how to do things like process the mail queue to see if I can get all the queued up list messages delivered.
 
One last remark! I found this on the web and it caused the delivery of the old stuff in the queue to my test list.

kill -ALRM `ps ax | grep qmail-send | grep -v grep | awk '{print $1}'`

I'm having a customer test their lists next.
 
One problem could be that the configuration for MailMan was updated (psa-mailman-configurator), but the actual binaries weren't moved to the new location Plesk 9 uses (/usr/lib/plesk-9.0). If you find that the error is referencing /var/qmail/bin/mm_wrapper, but the filen is in /usr/lib/plesk-9.0, try this

/usr/local/psa/admin/sbin/mchk --with-spam

That should make sure that mail configuration syncs up with file locations.

ls -lah /usr/lib/plesk-9.0/
total 3.7M
drwxr-xr-x 4 root root 4.0K Jan 9 04:05 .
drwxr-xr-x 79 root root 28K Jan 10 01:05 ..
-r-sr-xr-x 1 root root 268K Nov 17 05:49 autoresponder
-rwxr-xr-x 1 root root 4.8K Nov 17 05:48 bouncemessage
-r-xr-x--- 1 root root 1.1K Nov 17 05:50 ch_admin_email_httpd
drwxr-xr-x 2 root root 4.0K Dec 14 11:57 domain_rename
-r-xr-x--- 1 root root 9.8K Nov 17 05:50 key-handler
-r-xr-x--- 1 root root 1.7K Nov 17 05:50 key-upgrade
-r-xr-x--- 1 root root 131K Nov 17 05:48 mail_admin_aliases
-r-xr-x--- 1 root popuser 45K Nov 17 05:46 mail_auth_dump
-rwxr-x--- 1 root popuser 107K Nov 17 05:47 mail_dk_restore
-rwxr-x--- 1 root psaadm 236K Nov 17 05:48 mail_mailbox_restore
-r-xr-x--- 1 root root 3.3K Nov 17 05:48 mailman_conf_init
-r-xr-x--- 1 root root 236K Nov 17 05:48 mailman_lists_dump
-r-xr-x--- 1 root root 441K Nov 17 05:48 mailmng_domain_rename
-r-xr-x--- 1 root root 270K Nov 17 05:48 mailmng_domain_toggle
-rwxr-x--- 1 root root 48K Nov 17 05:57 mail_responder_restore
-r-xr-x--- 1 root psaadm 2.3K Nov 17 05:46 mail_restore
-rwxr-x--- 1 root psaadm 79K Dec 21 23:29 mail_spam_restore
-rwxr-x--- 1 root popuser 47K Nov 17 05:47 mail_spf_restore
-r-xr-xr-x 1 root root 47K Nov 17 05:48 mailsrvanalog
-r-xr-x--- 1 root root 470K Nov 17 05:48 mailsrv_conf_init
-r-xr-x--- 1 root root 675K Nov 17 05:48 mailsrv_entities_dump
-r-xr-x--- 1 root root 276 Nov 17 05:48 mailsrv_set_hostname
-r-xr-sr-x 1 root mail 5.9K Nov 17 05:49 mm_wrapper
drwxr-xr-x 2 root root 4.0K Dec 14 11:56 mysql
-r-xr-x--- 1 root root 152K Nov 17 05:48 postfix_conf_set
-rwxr-xr-x 1 popuser popuser 71K Nov 17 05:48 postfix-local
-rwxr-xr-x 1 root root 15K Nov 17 05:48 postfix-mailman
-r-xr-x--- 1 root root 127K Nov 17 05:48 postfix-poplockdb-clean
-r-xr-x--- 1 mhandlers-user popuser 62K Nov 17 05:46 postfix-queue

My server's config uses Postfix obviously, but if you are using qmail you should see qmail binaries like qmail-send there as well.
 
This is why I love you guys! Sorry I had to duck out but I was
stomping fires left and right from this whole upgraded mess we
were handed... So I came back to find solutions?

Yes! I'm on Qmail/FC 8, I refused to deal with the weird
Postfix junk from them right now and staying with what was
working and not as buggy as the Postfix stuff was out of the
box after the upgrade.

I took a compilation of all your thoughts and tried it in a
certain order - it worked! Kicked out all the mail the Queue
hadn't eaten as over the limit and now purrs like a kitten.
The only hangup was the last suggest of the whole linkup
list with mchk - that just hangs? Says 'looking for spam...'
something and hangs there for at least 5 minutes (longest
time I let it run without backing out of it with no results).
So I'm not sure why that's not working unless I missed
something.

BUT, here's the rundown in the order I did it from all the
fantastic selections here, ripe so Parallels can rip it off and
bilk $75 out of lazy suckers who call in instead of coming
here to the forums:

1) cd \var\qmail\bin
2) ln -s /usr/lib/plesk-9.0/mm_wrapper mm_wrapper
3) mv mm_wrapper mmold_wrapper (Made a simple backup)
4) chmod 2555 /var/qmail/bin/mm_wrapper
5) /usr/lib/plesk-9.0/mailman_conf_init /usr/lib/mailman/Mailman/mm_cfg.py qmail
6) kill -ALRM `ps ax | grep qmail-send | grep -v grep | awk '{print $1}'`
7) service restart qmail
8) service restart mailman

Within seconds - MAILMAN MAIL! Finally, a real solution that works that
should've been out of the box in the upgrade. Big huge thanks to all the
guys who posted their instructions here, this final list worked like a charm
and may only require some small modifications inserting 'postfix' where you
see qmail, but I haven't tested nor am I touching it and anyone with it who
follows this list - tell us what happened to you as well as your MTA and
OS? That's one key - I have Fedora Core 8, 9.0.0.1 (there's a 2?) and
Qmail selected. It's rarely said in posts and can get confusing if you use
something else and the commands, locations or something is different that
bricks your server or confuses you to death!

Thanks again!

Dave
PSCGi
 
I took a compilation of all your thoughts and tried it in a
certain order - it worked! Kicked out all the mail the Queue
hadn't eaten as over the limit and now purrs like a kitten.
The only hangup was the last suggest of the whole linkup
list with mchk - that just hangs? Says 'looking for spam...'
something and hangs there for at least 5 minutes (longest
time I let it run without backing out of it with no results).
So I'm not sure why that's not working unless I missed
something.


1) cd \var\qmail\bin
2) ln -s /usr/lib/plesk-9.0/mm_wrapper mm_wrapper
3) mv mm_wrapper mmold_wrapper (Made a simple backup)
4) chmod 2555 /var/qmail/bin/mm_wrapper
5) /usr/lib/plesk-9.0/mailman_conf_init /usr/lib/mailman/Mailman/mm_cfg.py qmail
6) kill -ALRM `ps ax | grep qmail-send | grep -v grep | awk '{print $1}'`
7) service restart qmail
8) service restart mailman

For qmail the "/usr/local/psa/admin/sbin/mchk --with-spam" works and will reset the configuration to the correct path for plesk 9 - You do have to wait for it to complete but it does work.... waiting for 5 or more mins is usual and you can always check if it is running by using top in another terminal session.

If you use other methods of correcting the configuration you run the risk of things breaking again in the future and an increase in the time it takes for people to assist you as you have a non standard config. Having said that I'm pleased that you found a way that works. :)
 
Wait a sec, so you're saying the one line is supposed to be the ultimate
cure, that it takes quite a bit of time on average and the other method
compiled is just risky because it does the same thing but in an allegedly
unsupported manner? (not like there's support now, even if you pay)

Want to make it totally clear for others reading, that these are the
same things but the single-line command shown is the proper solution by
Parallel's standards for continued support AND run it and go take a nap
because even 10-15 minutes later it may not yet be done, but it will and
it should resolve it?

And if the answer is yes to all that, are you supposed to restart those
two services afterwards otherwise it may not appear to have worked when
in reality it has?

So like:

/usr/local/psa/admin/sbin/mchk --with-spam
service restart qmail
service restart mailman

That's the proper and best way to resolve this?
 
And I spoke a moment too soon...

I'm trying a solution listed above again, but for some reason the lists
are fully functional - but not sending outside beyond the server? I mean
as an intentional test I have 2 accounts on one list - one inside the box,
one at Gmail. I send and receive posts there, one I view far more often
anyways. But, if a post doesn't show at both - I know I have issues.

Here, I got issues! LOL It's working like a charm, but only internally
which makes me wonder about the relay error listed above and a potential
workaround that these other 2 methods didn't fix.

I will state that I ran the one-liner and it DID finish! Took forever,
but it also ran. Not sure if that refouled something I'd done above
or what, thought that was a check and not a check/fix.
 
Wait a sec, so you're saying the one line is supposed to be the ultimate
cure, that it takes quite a bit of time on average and the other method
compiled is just risky because it does the same thing but in an allegedly
unsupported manner? (not like there's support now, even if you pay)
Both solutions work, the one liner changes the config to point to the correct location for the mm_wrapper i.e. /usr/lib64/plesk-9.0/mm_wrapper or /usr/lib/plesk-9.0/mm_wrapper depending on your system.


Want to make it totally clear for others reading, that these are the
same things but the single-line command shown is the proper solution by
Parallel's standards for continued support AND run it and go take a nap
because even 10-15 minutes later it may not yet be done, but it will and
it should resolve it?
To be clear, these achieve the same end result, but they are not exactly the same.

The one liner fixes the .qmail-{mailinglist_name} file. That is, inside the

/var/qmail/mailnames/{domain} directory is a file called .qmail-{mailnglist_name}.

It contains the line "|/var/qmail/bin/preline /usr/lib64/plesk-9.0/mm_wrapper /usr/lib/mailman/mail/mailman post {mailinglist_name}"

This is the command that qmail uses to deliver mail to the mailing list. This is the file that is updated by the command:

/usr/local/psa/admin/sbin/mchk --with-spam

The other method works by leaving the old configuration in the .qmail files and creating a symlink to the new location of the mm_wrapper. This is a little untidy in my mind (you may disagree which is good and fine :) ) and that during a future update, Parallels may look for the old file /var/qmail/bin/mm_wrapper and delete it (like now). This may break your fix and you'll be left in the situation of having some sites working and some sites not working which will very difficult to diagnose.


And if the answer is yes to all that, are you supposed to restart those
two services afterwards otherwise it may not appear to have worked when
in reality it has?

So like:

/usr/local/psa/admin/sbin/mchk --with-spam
service restart qmail
service restart mailman

That's the proper and best way to resolve this?

There is no harm in restarting those services and to be honest I don't remember if I did or not, so I agree restart the services.

So to reiterate:

/usr/local/psa/admin/sbin/mchk --with-spam
service restart qmail
service restart mailman

will update the relevent files and will restart those services which use the updated config files.
 
Gotcha, no problems as I'm just trying to confirm what's what as I
hate going through piles of posts to find clues but not real answers
and I learn the hard way what was 'best' and what kinda worked. I
did end up with the short fix last, so I'm not messing with that! LOL

Now, the final problem... as I mentioned, the stupid thing's working
perfectly BUT - nothing's getting outbound beyond the box? Any post
can come from anyone registered, anywhere, but when it sends out
mail only the internal ones get it! My outer Gmail account isn't getting
the posts nor the post-acknowledgment I have it set for either. I do
get that using the internal mail account.

So I think I'm over in the mail relay area, but I have all my internal
IP's whitelisted on the Firewall, everything else handled that I've ever
found... What would allow mail to flow out but not outside the box
itself to the rest of the world beyond my internally hosted domains?
 
Things to check:
Can you send mail using telnet on port 25 to a remote mail server?
Can you send mail to a remote server using Mutt or Pine or Mail?
Can you send mail to a remote server using your email client from a PC via your server?
Or is it just lists that are not delivering email to off server addresses?
 
Can you send mail using telnet on port 25 to a remote mail server?

Here I'm going to say not because we've long since dumped Telnet as a serious security
risk? So between Port 25 and Telnet, I'd automatically say 'nope', though it's been awhile
and I'm blanking on how to do so.

Can you send mail to a remote server using Mutt or Pine or Mail?

Eh, Exqueeze me? Forgive my brain, but it's been a long time (thankfully) since I've
ever had to do that so I'm blanking on the commands. I mean it took me until this
mess to determine that Plesk uses Nano instead of Pine/Pico? Totally threw me off and
had me scrounging for the new versions until a hint of Nano was found here online
at the forums and saved the day since that's my most preferred interface.

I'll dive back in there until you reply, but I think Pine's gone too as mentioned? And
I never recall way back to the RaQs that I ever had to send out mail that way even
as a test so I may never have learned those commands. Linux is not a primary with
me, more operations than coding so I'm just going to play stupid on some of this and
ask for your cooperation vs. anything else on lack of Linux saavy.

Can you send mail to a remote server using your email client from a PC via your server?

Milliseconds! As fast as I hit SEND in Horde - it's at Gmail in the Inbox. Simultaneously
is the best word I could find, LOL! So that's been fine for awhile now. I believe I did a
hack on that previous to any updates from Plesk to restore that capability because my
clients were all over me when Horde went south.

Or is it just lists that are not delivering email to off server addresses?

That seems to be the major situation? It delivers them internally, but nothing at all to
off-server addresses. Watchdog - works. Joomla installs with SMTP features - work. All
of that seems OK without a hitch - just failure in Mailman, but only in outbounds destined
beyond the server? That I've never seen before and I'm stumped.
 
Is the mail sitting in the mail queue waiting to be delevered? You can read the mail queue by using:

/var/qmail/bin/qmail-qread

Also if you were to set-up a new list does it send mail to remote servers?

Finally check the logs in:

/var/log/mailman
 
Mail not in queue, will check the other two you mentioned for
some clues, thanks! The logs so far weren't showing any
rejections, but more like the outbound beyond the internal
domains was simply blackholing...

This is only going on with Mailman, haven't made a new one
yet but doing it right now and will report back, thanks!
 
Back
Top