[Mailman-Users] "Bounce action notification" emails for subscribes/unsubscribes

[Terry .]

Hi again Mark, etc.

Sorry for the delay in responding.

I passed this back to my webhost, and they passed it on to cPanel for me:
==========================================
I’ve been thinking about the solution that cPanel have provided for the previously mentioned 3 subscribe/unsubscribe notification issues, and to me it just sounds like a not-so-good work-around for a problem which has started occurring to my lists (which I've had for years) this year, and according to the mailman users mailing list, WHB is not the only webhost which has been affected. It’s a relatively minor issue though, so cPanel may not have received many complaints...yet.
The reason I say it’s a not-so-good work-around are:
a) Creating a Default Address for a domain has side affects which may not be wanted. (I discovered that I can avoid those side affects by creating a forwarder (i.e. alias) which points from mailman-bounces at mydomain.com<mailto:mailman-bounces at mydomain.com> to any mailbox, but that is still just a work-around.)
b) Requiring list creators to always work around these cPanel problems by creating a default address or forwarder is not a proper fix.
c) How are list creators supposed to discover that they need to perform this work-around to avoid these problems? Is cPanel going to have something pop up on their Mailing Lists page to say this? Better to fix the problem!
d) How are owners of existing lists expected to discover it? A pop up may not be possible there. Do cPanel expect every customer to have the time, energy and skills to prove the problems to their webhost, and hope their webhost passes them on to cPanel, so they can be given the work-around? This is a waste of time for everyone including webhost and cPanel staff.
e) These Mailman problems seem to be happening in cPanel environments only, so cPanel should fix them properly, and save their Mailman users from wasting huge amounts of time and energy to discover a work-around which should not even be necessary.

The server I’m on (server103) is currently running Mailman 2.1.23 and cPanel 11.66.0.25, and today I confirmed the problem still occurs, unless I work-around it.

What is cPanel going to do about this?
==========================================


cPanel responded with the following 2 emails:


Response #1:

====================================

Hello,

Unfortunately though, as I mentioned previously this is a result of an upstream design choice from Mailman not from cPanel, we had an open inquiry for our development team as I mentioned previously as well which addressed this. This isn't a modification we made in the behavior.

In response to point a) A default address is created for every account on the server automatically, I did suggest in my previous response that it is a bad idea to utilize this as a resolution.

In regard to the rest of the points I think it is useful to stress the following:

This isn't an issue that cPanel created, this is an issue that is present due to the utilization of two incompatible configurations in conjunction with each other, sender-verify cannot verify a sender that does not exist, mailman does not create an alias for mailman-bounces, so essentially unless one of the two is changed (which sender verify cannot) the solution is either to disable sender verify or create an alias/forwarder/account so the user does exist. My suggestion to prevent this from occurring would be to disable sender-verify in this instance since the way that mailman works is incompatible with the configuration.

The sole purpose of providing the workarounds was to provide a way for this to work with sender-verify enabled, if these are not suitable you can disable sender-verify and the mailman mailing list would work as intended.

Thank you,

--

Lauren N
Linux Technical Analyst II
cPanel, Inc.
====================================


Response #2:
====================================
Hello,

I just wanted to follow up on this and let you know that I did open another internal case CPANEL-16468 to inform our development of the specific behavior that's occurring. Should our developers choose to address this issue updates to this case will be added to our changelogs when they're available. You can check them here: https://documentation.cpanel.net/display/CL/Change+Logs

I'll do my best to respond here if any response is made by the development team to the internal case as well.

Thank you,

--

Lauren N
Linux Technical Analyst II
cPanel, Inc.
====================================

So response #1 makes it look as if it's Mailman's fault, not cPanel's, so cPanel don't need to fix it, which begs the question: how was all this working fine until earlier this year, and what's changed that broke it?
I don't know if a new version of Mailman was installed on the server in that time, but even if it were, it doesn't sound to me as if it would have changed in this department.
And I think the webhost probably has had sender_verify turned on for years now, but I'm checking that with them.
Then response #2 makes it look as if cPanel *may* be willing to deal with the issue, despite the above.

Any comments on any of this, Mark or anyone else, especially re this claim:
"...this is a result of an upstream design choice from Mailman not from cPanel, we had an open inquiry for our development team as I mentioned previously as well which addressed this. This isn't a modification we made in the behavior."

Thanks.
Terry