Resolved PHP Mail not working

[Futureweb OG]

Username: Futureweb OG

TITLE

PHP Mail not working

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian v18.0.32_build1800201221.13 os_CentOS 8, CentOS Linux 8.2.2004 (Core)

PROBLEM DESCRIPTION

If you create a customer with a service plan where mail services are disabled, you can't send mails via php. So "php mail" doesn't work. If you activate and deactivate mail services for this customer afterwards, php mail will work as expected.

STEPS TO REPRODUCE

1. Create a customer and assign a service plan with mail services disabled
2. Try to send mails via php (won't work)
3. Activate mail services for this customer via customer e-mail settings
4. PHP mail will work now.
5. Deactivate mail services again for this customer
6. PHP mail will still work.

ACTUAL RESULT

PHP mail doesn't work for newly created customers without mail services.

EXPECTED RESULT

PHP mail has to work for newly created customers, even if mail services are disabled. Switching mail services on and off after creating the customer is not a good solution.

ANY ADDITIONAL INFORMATION



YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[IgorG]

Thank you for the report. This is known as PPPM-12408 issue.

 

[Ladylinux]

Hi,

Spent a maddening morning because of this bug. When will this actually be resolved ??

Thanks!!

Fran

 

[Peter Debik]

Spent a maddening morning because of this bug. When will this actually be resolved ??

This situation conflicts with Plesk's recommendations to keep disabled Mail service if mail with this domain name is located externally. For example:
https://support.plesk.com/hc/en-us/...to-external-mail-service-is-delivered-locally
The report is being monitored as a potential issue, but since it was reported it seems that for the vast majority of users the behavior is exactly what the users expect. So at the moment there is not ETA for a change in that behavior.

 

[futureweb]

This situation conflicts with Plesk's recommendations to keep disabled Mail service if mail with this domain name is located externally. For example:
https://support.plesk.com/hc/en-us/...to-external-mail-service-is-delivered-locally
The report is being monitored as a potential issue, but since it was reported it seems that for the vast majority of users the behavior is exactly what the users expect. So at the moment there is not ETA for a change in that behavior.

Hi Peter,

"behavior is exactly what the users expect", not serious, are you?
We have dozens if not hundreds of customers whose mail services are on Office 365 - but their websites are on our shared hosting Plesk servers.
And here it is now "user expected behavior" that none of these customers can send emails via their PHP web forms because the mail services (php mail send to be more specific) is disabled ... ?!?
So here please should be urgently thought about what is the correct "user expected behaviour" and what are Plesk recommendations for this scenario ...

YES - it is very important that Plesk email services are DISABLED for externally hosted mail services - otherwise "local delivery" will take place ...
However, the issue here is that e.g. PHP forms on the website do not work because PHP is not allowed to send mails ...
... these are technically in itself 2 completely different things ...

Thanks a lot, have a nice weekend
Andreas

 

[Ladylinux]

Hello,

Actually I can see both sides of this issue and thank you Peter for that information. Maybe what is needed in the interim is better documentation. As Andreas points out this is a rather common thing that users do expect. Do I think its secure no. I actually don't like local mail relaying for forms etc. But it is what it is and in these cases it would be nice to have a easier way around this than enabling and disabling mail service for clients who don't have mail services.

Thanks!!

Fran

 

[Peter Debik]

Hi Peter,

"behavior is exactly what the users expect", not serious, are you?
We have dozens if not hundreds of customers whose mail services are on Office 365 - but their websites are on our shared hosting Plesk servers.
And here it is now "user expected behavior" that none of these customers can send emails via their PHP web forms because the mail services (php mail send to be more specific) is disabled ... ?!?
So here please should be urgently thought about what is the correct "user expected behaviour" and what are Plesk recommendations for this scenario ...

YES - it is very important that Plesk email services are DISABLED for externally hosted mail services - otherwise "local delivery" will take place ...
However, the issue here is that e.g. PHP forms on the website do not work because PHP is not allowed to send mails ...
... these are technically in itself 2 completely different things ...

Thanks a lot, have a nice weekend
Andreas

I absolutely agree that for providers it is frequently seen that users host their mails elsewhere. Maybe we can work out a good argument for developers together what you as a user would expect instead of the current solution?

I think the issue is that either way there is a user group that opposes the setting. Because when the system offers "disable mail service" and the user then experiences that the mail service was not really disabled when he chooses "disabled", but only part of the mail service, that will probably not be right either, some users will complain. The option is "disabled", so very likely most users understand that mail service will be disabled and not only partially disabled.

On the other hand you wish for a default setting where local mail delivery is disabled, but scripts should still be able to send mail, right? The topic is about the 3rd party email service that users want to use, so the product will probably need a separate setting for that, right?

The suggested work around by developers is to toggle the setting once so that the script mail service works although the mail service is officially disabled. So how could this be wrapped right into the subscription setting for you as a provider to get the most comfortable and best solution?

Would some radio selection like this meet your requirements?
"Disable all mail services"
"Disable mail for incoming mail only" (choose this setting if email for a domain is hosted elsewhere)
"Disable mail for outgoing mail only"

 

[futureweb]

I absolutely agree that for providers it is frequently seen that users host their mails elsewhere. Maybe we can work out a good argument for developers together what you as a user would expect instead of the current solution?

I think the issue is that either way there is a user group that opposes the setting. Because when the system offers "disable mail service" and the user then experiences that the mail service was not really disabled when he chooses "disabled", but only part of the mail service, that will probably not be right either, some users will complain. The option is "disabled", so very likely most users understand that mail service will be disabled and not only partially disabled.

On the other hand you wish for a default setting where local mail delivery is disabled, but scripts should still be able to send mail, right? The topic is about the 3rd party email service that users want to use, so the product will probably need a separate setting for that, right?

The suggested work around by developers is to toggle the setting once so that the script mail service works although the mail service is officially disabled. So how could this be wrapped right into the subscription setting for you as a provider to get the most comfortable and best solution?

Would some radio selection like this meet your requirements?
"Disable all mail services"
"Disable mail for incoming mail only" (choose this setting if email for a domain is hosted elsewhere)
"Disable mail for outgoing mail only"

Hi Peter,
thank you for your feedback.

As a web hosting provider, we understand "mail services" to be all services that provide SMTP, POP3, IMAP. That means the complete mail stack.
The enable/disable of sending mails via Linux sockets (PHP mail()) would be, at least for us, correct to look for in the settings of PHP. Since a basic function on the part of the web hosting is deactivated. Any CMS (Wordpress, Joomla, ...) that you install relies (if not manually reconfigured to SMTP) on the functionality of mail() to send any outbound mails. Be it admin notifications or any client side form.
The current behavior of Plesk - that the script or PHP mail() services are activated by activating the mail service once and then deactivating it again is in any case the most confusing for everyone. So script mail services are ACTIVE although all mail services are disabled according to Plesk GUI ... no way to tell if Script / PHP mail() Services are active / working ...

Especially nowadays when almost every day customers switch from our Plesk mail services to Office 365 this should not be ignored.

Maybe it can be worded better, as you already suggested ... ?! Maybe a simple additional checkbox ... which default can be set within the service packages?

- [Checkbox] Activate email service on this domain
- [Checkbox] Enable PHP mail() / Scripts outbound emails on this domain

So it would be clear for everyone what is/will be disabled ... ?

Greetings from snowy Tyrol
Andreas

 

[Ladylinux]

Would some radio selection like this meet your requirements?
"Disable all mail services"
"Disable mail for incoming mail only" (choose this setting if email for a domain is hosted elsewhere)
"Disable mail for outgoing mail only"

Peter,

This would do for me.

Honestly I planned out my move to Plesk back when you had Multi Server still. Odin while awesome is too much for my needs.

I wanted a "Web Only" server myself to do acls to prevent script abuse.

And mail only etc etc. And I wanted it managed centrally.

Ok I digressed there. Sorry.

Postfix makes this a lot simpler and with my legacy servers it allows me to stop this abuse.

But with a mixed environment (Users with or without mail) having some control over what a user can and can't do with the MTA would be a good compromise.

Otherwise its a lot of local command line postfix customization that I only do. I don't want my support staff doing command line anything. A simple radio selection they can toggle or not would be a great improvement.

Obviously this request of mine is a "Nice To Have" but honestly if easy to do I am sure others would love it.

Thanks Fran

 

[Peter Debik]

Both of you thanks a lot for taking the time to discuss this. This is truly helpful. It became clear why this case distinction is needed. I'll take the information and present it to someone responsible this upcoming week. Please allow some while for further steps or feedback.

 

[Peter Debik]

I'd like to update you on what's going on in this case. Developers had actually been working on a fix a long time ago, but it contradicted other settings and functions so it never got to a point where a fully functional, acceptable solution was reached. It was related to the above mentioned different expectations of different user groups. However, we are now trying again with new specifications to find a solution that fulfills all requirements. This issue is again on the table and we'll see whether there is a smart way to get the best possible result.

 

[Peter Debik]

Plesk Obsidian 18.0.51:
Reworked the mail service options for individual domains. The available options are now “the domain can both send and receive email”, “the domain can send, but not receive email”, and “the domain can neither send nor receive email”. Selecting the latter option also removes all existing mailboxes for the domain together with all incoming and outgoing mail.

 

[futureweb]

Hi Peter,

I am pleased to hear the news, and I have a technical question regarding the change. In your message, you stated that selecting the third option removes all existing mailboxes for the domain, so the second Option won't delete them, right? I would like to clarify what happens to local mail delivery if we choose the option "the domain can send, but not receive email."

Let me give you an example: Suppose I have a domain called "testdom.tld" on my Plesk server, and I have enabled the second option, which allows the domain to send but not receive emails. If I send an email from another domain on the same Plesk server to "[email protected]," will the email be sent to the MX that is set on "testdom.tld" without local delivery occurring, right? Even the local Mailboxes for testdom.tld still exist?

Based on my understanding, I assume that this is how the feature works, as it would not make sense otherwise.
However, the wording of the options / existance of the local Mailboxes has confused me a bit. (local Mailboxes still exist, but no local delivery ... ^^)

Thank you for your assistance in clarifying this matter.
thx, best regards,
Andy

 

[Peter Debik]

Think of mailboxes as user accounts. When you want to send mail through SMTP you need to login. For that a user account is needed, so a mailbox must exist, even if that mailbox won't receive mail. From my understanding the new option caters for the business case where emails are hosted on an external server. I know that this was what was asked from developers, and product managers responsible for the feature made that clear. So I think that this is what has been delivered, but I have not tested it yet myself.

 

[Ladylinux]

Hi,

This is fantastic Peter.

Looking forward to trying this out

Thanks!!

Fran

 

[futureweb]

Hi Peter,
the feature description in Plesk and your statement contradict each other 180 degrees. ^^
In Plesk, it explicitly states that "only sendmail can be used to send emails from this domain." Therefore, it is explicitly stated that it is purely about SENDMAIL delivery, which does not require local mailboxes. You are referring to SMTP delivery, which would require mailboxes.
Anyway, we will perform a few test cases and share the results here afterwards.
Wish you a great start into the new week, bye from Austria
Andy

 

[N8 Solutions]

Hi Peter,
I'm a bit late to this conversation. I've been dealing with this for quite some time now and thankfully found this post. I want to ask specifically about PHP mail. The scenario I'm dealing with now is that I have a Joomla client that wants to use a specific email address for their contact form. The email address is from their local internet provider like comcast, verizon, att, sbcglobal, etc..., so they won't have a mailbox for that account on the server as it's not associated with the domain. They are also using Google Workspace for the rest of their domain emails, so like the others, it is an external mail service so mail needs to be disabled. The current options though still require that mail be enabled then disabled in order for mail to be sent using the PHP mail function as the OP mentioned in his opening post. While a new option was added, directly addressing the OP's concern about having an option to enable mail to be sent using PHP was not. If PHP mail works after enabling then disabling the mail service for the domain, why can't we have a toggle to allow mail to be sent using PHP?

kind regards,

Michael

 

[Kaspar]

[...] The scenario I'm dealing with now is that I have a Joomla client that wants to use a specific email address for their contact form. The email address is from their local internet provider like comcast, verizon, att, sbcglobal, etc..., so they won't have a mailbox for that account on the server as it's not associated with the domain. They are also using Google Workspace for the rest of their domain emails, so like the others, it is an external mail service so mail needs to be disabled. The current options though still require that mail be enabled then disabled in order for mail to be sent using the PHP mail function as the OP mentioned in his opening post.

In the scenario you are describing (email for the gets received externally, like with Google Workspace) you'd use the "Disabled for incoming mail" option. Which allows for sending of email, but routes emails send to the domain via the mail server configured in the domains MX record. (Rather then routing email internally).

While a new option was added, directly addressing the OP's concern about having an option to enable mail to be sent using PHP was not. If PHP mail works after enabling then disabling the mail service for the domain, why can't we have a toggle to allow mail to be sent using PHP?

The new option addresses exactly that (it's just not limited to PHP).